Учетные данные безопасности

Q: Я пишу программу, использующую Authorization Services. Когда я вызываю AuthorizationCopyRights, иногда я получаю диалоговое окно пароля, и иногда я не делаю. Что продолжается?.

A: Это касается плохо понятого аспекта Authorization Services и Сервера безопасности. Для понимания, что продолжается необходимо понять, как Сервер безопасности реализует авторизацию.

Учетные данные - что-то, что Сервер безопасности знает об определенном пользователе. Стандартным примером учетных данных является знание, что определенный пользователь ввел имя и пароль действительного пользователя.

Сервер безопасности поддерживает глобальную переменную (сеанс на вход в систему) кэш учетных данных и кэш учетных данных на экземпляр авторизации [1]. Когда Вы запрашиваете авторизацию на определенное право, правильная спецификация (найденный в базе данных политики авторизации в /etc/authorization) указывает список учетных данных, которые должны быть получены для предоставления права. Это может также включать a shared ключ, определяющий, совместно используются ли учетные данные. Для каждых учетных данных в правильной спецификации Сервер безопасности пытается получить учетные данные из кэша учетных данных. Это сначала смотрит в кэше учетных данных, связанном с экземпляром авторизации. Если учетные данные не там, и учетные данные совместно используются, это тогда смотрит в глобальном кэше учетных данных. Если Сервер безопасности не может найти учетные данные в кэше, это пытается получить учетные данные. Обычно это включает подъем диалога аутентификации, где пользователь должен ввести имя пользователя и пароль. Однако на некоторых конфигурациях Mac OS X, это может получить учетные данные от других мест (таких как смарт-карта).

Если Сервер безопасности успешно получает учетные данные, он помнит его в кэше учетных данных, связанном с экземпляром авторизации и, если право указывает, что учетные данные совместно используются в глобальном кэше учетных данных.

Если правильная спецификация имеет a timeout ключ, его значение указывает, сколько времени (в секундах) кэшируемые учетные данные применимы для этого права. Значение 0 средних значений, что учетные данные могут только использоваться один раз (т.е. это сразу испытывает таймаут). Если ключ тайм-аута отсутствует, учетные данные могут всегда использоваться для предоставления права (если учетные данные не уничтожаются, посмотрите ниже).

Вышеупомянутое походит на мелочи фаната безопасности, пока Вы не понимаете некоторых важных последствий:

• Когда Вы входите в систему, loginwindow получает право system.login.console. Как побочный эффект, это получает учетные данные, указывающие знание имени пользователя и пароля, и хранит те учетные данные в глобальном кэше учетных данных.

• Большинство других правильных спецификаций (например, system.preferences, который управляет, можно ли изменить настройки в Установках системы), требуют, чтобы Вы доказали знание имени пользователя и пароля администратора. Если Вы находитесь в admin группа, действие входа в систему получает эти учетные данные и хранит его в глобальном кэше учетных данных. Таким образом, если Вы находитесь в admin группа, Вы не должны вводить свой пароль для внесения изменений в Установках системы.

• Если приложения запрашивают право, и правильная спецификация в базе данных правил управления указывает, что любые недавно полученные учетные данные должны быть совместно использованы, и Вы вводите свое имя пользователя и пароль, что учетные данные входят в глобальный кэш учетных данных. Если другое приложение (т.е. другой экземпляр авторизации) запросит право, и правильная спецификация диктует, что Ваши учетные данные имени пользователя и пароля требуются, то Сервер безопасности будет использовать учетные данные от глобального учетного кэша. Таким образом ввод Вашего имени пользователя и пароля в одном приложении позволит другим приложениям использовать учетные данные.

Конечный результат то, что во многих случаях вызов к AuthorizationCopyRights не требует, чтобы Вы ввели имя пользователя и пароль, потому что Сервер безопасности уже кэшировал требуемые учетные данные.

Единственный способ гарантировать, что учетные данные, полученные, когда Вы запрашиваете право, не совместно используются с другими экземплярами авторизации, состоит в том, чтобы уничтожить те учетные данные. Вы делаете это путем вызова AuthorizationFree и передача во флаге kAuthorizationFlagDestroyRights.

Примечания:

1. Экземпляр авторизации более или менее эквивалентен AuthorizationRef, если Вы воплощаете, несмотря на то, что у Вас могут быть многократные процессы, совместно использующие тот же экземпляр авторизации AuthorizationRef и передайте его между процессами.

История версии документа