Сравнивайте с английским: нажмите на абзац — оригинал откроется в окне. Кнопка EN под абзацем показывает его прямо в тексте.
Введение
Гибкий механизм аутентификации пользователей
Flexible mechanism for authenticating users
Подключаемый модуль аутентификации (PAM) — это механизм интеграции множества схем аутентификации низкого уровня в высокоуровневый интерфейс программирования приложений (API). PAM позволяет разрабатывать программы, использующие аутентификацию, независимо от лежащей в основе схемы аутентификации. Впервые он был предложен компанией Sun Microsystems в запросе комментариев (RFC) 86.0 от Open Software Foundation, датированном октябрем 1995 года. Он был принят в качестве фреймворка аутентификации для Common Desktop Environment. Как самостоятельная инфраструктура с открытым исходным кодом, PAM впервые появился в Red Hat Linux 3.0.4 в августе 1996 года в рамках проекта Linux PAM. В настоящее время PAM поддерживается в операционных системах AIX, DragonFly BSD, FreeBSD, HP-UX, Linux, macOS, NetBSD и Solaris. Поскольку единого централизованного стандарта поведения PAM не существует, позднее была предпринята попытка стандартизировать PAM в рамках процесса стандартизации X/Open UNIX, что привело к созданию стандарта X/Open Single Sign-On (XSSO). Этот стандарт не был ратифицирован, однако проект стандарта послужил ориентиром для последующих реализаций PAM (например, OpenPAM).
A pluggable authentication module (PAM) is a mechanism to integrate multiple low level authentication schemes into a high level application programming interface (API). PAM allows programs that rely on authentication to be written independently of the underlying authentication scheme. It was first proposed by Sun Microsystems in an Open Software Foundation Request for Comments (RFC) 86.0 dated October 1995. It was adopted as the authentication framework of the Common Desktop Environment. As a stand alone open source infrastructure, PAM first appeared in Red Hat Linux 3.0.4 in August 1996 in the Linux PAM project. PAM is currently supported in the AIX operating system, DragonFly BSD, FreeBSD, HP UX, Linux, macOS, NetBSD and Solaris. Since no central standard of PAM behavior exists, there was a later attempt to standardize PAM as part of the X/Open UNIX standardization process, resulting in the X/Open Single Sign on (XSSO) standard. This standard was not ratified, but the standard draft has served as a reference point for later PAM implementations (for example, OpenPAM).
Критика
Поскольку большинство реализаций PAM не взаимодействуют напрямую с удаленными клиентами, PAM сама по себе не может реализовать Kerberos – наиболее распространенный тип единого входа (SSO), используемый в Unix-средах. Это привело к включению SSO в качестве компонента "первичной аутентификации" разрабатываемого стандарта XSSO и появлению технологий, таких как SPNEGO и SASL. Отсутствие этой функциональности также является причиной того, что SSH самостоятельно выполняет согласование механизма аутентификации. В большинстве реализаций PAM модуль pam_krb5 лишь запрашивает билеты предоставления услуг (Ticket Granting Tickets), что включает запрос у пользователя учетных данных, и это используется только при первоначальном входе в систему в среде SSO. Чтобы получить сервисный билет для конкретного приложения, не запрашивая у пользователя повторный ввод учетных данных, это приложение должно быть специально разработано с поддержкой Kerberos. Это связано с тем, что сам модуль pam_krb5 не может получать сервисные билеты, хотя существуют версии PAM KRB5, которые пытаются решить эту проблему.
Since most PAM implementations do not interface with remote clients themselves, PAM, on its own, cannot implement Kerberos, the most common type of SSO used in Unix environments. This led to SSO's incorporation as the "primary authentication" portion of the would be XSSO standard and the advent of technologies such as SPNEGO and SASL. This lack of functionality is also the reason SSH does its own authentication mechanism negotiation. In most PAM implementations, pam krb5 only fetches Ticket Granting Tickets, which involves prompting the user for credentials, and this is only used for the initial login in an SSO environment. To fetch a service ticket for a particular application, and not prompt the user to enter credentials again, that application must be specifically coded to support Kerberos. This is because pam krb5 cannot itself get service tickets, although there are versions of PAM KRB5 that are attempting to work around the issue.