OpenSolaris Project: Reno: Login Process Enhancements for Interop
View the leaders for this project
Project Observers
Endorsing communities
OS/Net (ON)
Security
From the ARC materials:
This project is related to the SPARKS project, falls under the SPARKS
umbrella case to be presented at PSARC on 04/19/2006, and has a soft
defpendency on SPARKS.
Some directories require that lookups be "self-credentialled,"
meaning that clients use user credentials, as opposed to host or
"proxy" credentials.
The Solaris login process, however, works in such a way that
directory lookups must be performed prior to the point at which user
network authentication credentials are available. A chicken and egg
problem ensues.
Further, network authentication (single sign-on) is not well
integrated with PAM, which is related to the chicken-egg problem in
that delegated credentials and/or authorization-data could be used in
certain contexts in addressing the chicken-egg problem, but not
easily without a closer tie between PAM and network authentication.
This project revamps the Solaris login process to allow for
directories that require self-credentialled lookups for information
needed during the Solaris login process and to better integrate
network authentication with PAM.
We borrow from JAAS the notion of a "Subject" object that represents
information about users needed during the login process, and we tie
this notion to PAM, allowing PAM modules to provide subject
information, which in turn breaks the chicken-egg problem by
eschewing name service lookups in PAM applications. Additionally we
move certain tasks from GSS-API applications to PAM, such as
authorization of remote principals to Unix user accounts and handling
of credential delegation.
These changes will also enable us to better cope with future Solaris
process credentials extensions and with infrastructures and
authentication mechanisms that deliver user process credential
information through network authentication.
Reno extends PAM as follows:
- Adds a
PAM_USER_TYPE item to identify the type of user account named by PAM_USER. Solaris PAM modules will, of course, only support "Unix" user accounts.
- Adds a
PAM_USER_INFO item by which PAM applications can pass a userinfo_t object to PAM modules, which can then fill in information about the PAM_USER that is relevant to the login process (see below).
- Related to this, there is a new API, the User Info API. A User Info object is a template that represents everything about an authenticated user that must be known at logon-time, such as:
- UID
- Primary GID
- Supplementary GIDs
- Home directory
- Shell
- Default and limit privilege sets
- Project
- User account type (i.e., user vs. role)
as well as how to apply such templates to processes.
- Adds new items,
PAM_GSS_MECH, PAM_GSS_NAME and PAM_GSS_CRED by which PAM applications can communicate to PAM modules informations about client principals authenticated with the GSS-API by passing gss_OID, gss_name_t and gss_cred_id_t objects, respectively.
PAM modules and applications will be modified accordingly.
Among other interesting changes: sshd(1M), in.telnetd(1M), and friends will no longer be responsible for handling authorization of client principals to Unix accounts, nor for handling of delegated credentials. Additionally, pam_ldap(5) and pam_krb5(5) will, when self-credentialled LDAP is configured, perform self-credentialled lookups in the directory and fill in applications' userinfo_t objects.
Backwards compatibility is addressed as follows:
- Existing module behave as usual when
PAM_USER_INFO is not set;
- Modules will have a
nouserinfo argument to disable new behaviour even when PAM_USER_INFO is not set;
- Applications will fallback on using name services to discover users' UIDs, GIDs, etc.. when PAM modules fail to fill in the applications'
userinfo_t object.
A project related to Reno, PSARC 2005/275, extends the PAM framework by adding a new PAM function, pam_eval(3PAM), that loads the PAM configuration in a file named by its argument, and evaluates the current service module for the current PAM service, returning the result to the caller. This function is intended to be called by PAM modules, specifically a new Solaris PAM module: pam_user_policy(5), which determines a configuration file to evaluate by first looking for the PAM_USER's pam_policy user_attr(5) key, falling back on the pam_policy of the first RBAC profile granted in policy.conf(5) that has such a key.
Reno depends on this functionality.
A slightly updated version of the brief in the ARC commitment materials directory. (Some of the man page links therein are broken; they will be fixed shortly.)
For now here are the man pages for the User Info API:
|