В интервью интервьюер спросил меня, почему вам нужны личные учетные данные в JAAS?
Мы можем получить доступ как к общедоступным учетным данным, так и к приватным учетным данным, например:
Set<Object> privateCredentials = subject.getPrivateCredentials();
Set<Object> publicCredentials = subject.getPublicCredentials();
Оба (privateCredentials и publicCredentials) доступны, и способ доступа одинаковый.
Итак, каково значение для буксировки типов учетных данных?
Из книги "Java и интернет-безопасность" Теодора Шрейдера, Брюса А. Рича, Энтони Дж. Надалина:
С несколько более противоречивыми соображениями дизайнеры JAAS пришли к выводу, что у Принципалов может быть какое-то подтверждение личности, которое они должны иметь в состоянии обеспечить в момент уведомления, и эти доказательства личности могут включать конфиденциальную информацию, поэтому набор публичных учетные данные и набор частных учетных данных были добавлены к теме. Поскольку содержимое учетных данных может широко варьироваться в разных механизмах аутентификации, от простого пароля до фингерпринта (до бесконечности и за его пределами), тип учетных данных просто оставался как java.lang.Obiect. Отношения между принципалами и учетными данными, если таковые имеются, были оставлены в качестве упражнения для исполнителя конкретного класса Principal (или, скорее, конкретного класса LoginModule). С точки зрения JAAS единственная разница между частным и общедоступным учетными данными заключается в том, что для доступа к набору личных учетных данных требуется специальный javax.security.auth.AuthPermission.
В Справочное руководство JAAS:
Чтобы выполнить итерацию с помощью набора личных учетных данных, вам потребуется
javax.security.auth.PrivateCredentialPermissionдля доступа к каждому учетному данным. Дополнительную информацию см. В документации по APIPrivateCredentialPermission.
Ну, они вообще не нужны им вообще. У меня довольно большая система JAAS с примерно 7 LoginModules, и я вообще не использую личные учетные данные. Вы использовали бы их, если бы, например, вы хотели сохранить пароль пользователя или закрытый ключ для извлечения другими частями системы, но нет ничего, что необходимо для этого, оно полностью зависит от того, как вы проектируете свою систему. Мое отношение состоит в том, что пароль находится в LDAP и где он остается, и у меня нет пользователей с закрытыми ключами.
Однако, когда они вам понадобятся, вам нужно, чтобы они были отделены от общедоступных учетных данных, потому что они частные, а не публичные, innit? и действительно, они могут быть дополнительно защищены, требуя PrivateCredentialPermissions для доступа к ним.
Из моего понимания JAAS (и большего понимания общих принципов дизайна SW)
Объект представляет собой объект, представляющий собой источник запроса, например пользователя, и поскольку JAAS предлагает предоставить абстрактный API для различных механизмов авторизации/аутентификации, вы также можете взглянуть на тему как на какую-то абстракцию.
Я использую JAAS с Krb5LoginModule и, например, в нашем случае главный представляет данные пользователя (имя пользователя + realm - i.e - "[email protected]" ).
Пользователь может иметь набор частных и общедоступных учетных данных в зависимости от основного криптографического механизма (я надеюсь, что я использую правильный термин здесь) - например, если используется асимметричная криптография ключа, вы можете использовать getPublicCrendetials для получения информации на открытых ключах.
getPrivateCredentials будет содержать набор закрытых ключей, и вам, вероятно, понадобятся привилегии, чтобы получить этот список.
Хотя я никогда не пробовал это раньше, возможно, вы можете использовать getPrivateCredentials, чтобы получить закрытый ключ и использовать его для цифровой подписи?
Могу сказать, что я использовал эти методы, чтобы получить билет в кеберосе, и получить информацию о его действительности (срок действия).
Надеюсь, что это дало вам еще одну мысль о том, почему было создано это подразделение.
Публичные учетные данные могут свободно раскрываться и передаваться по этому вопросу. Примеры:
Частные учетные данные являются секретами. Поскольку объекты Subject могут иметь широкую аудиторию, они должны быть скрыты от доступа "аутсайдерами". API предоставляет ограничения для доступа к приватным учетным данным объекта, которые подробно описаны в других ответах. Примеры: