The core function of the Authentication Service is to validate the required credentials of end users, administrators or applications requesting access to information or protected resources in the OpenSSO Enterprise single sign-on environment. When creating the end-to-end authentication process by which a user (for example) will be authenticated, there are things to consider such as where the authentication process will be initiated, which authentication module(s) will be used in the process, and what, if any, post authentication steps will be implemented. The authentication type (where the authentication process will be initiated) is specified by appending an appropriate parameter to the login URL, or through the authentication API. The authentication process is configured (simply) by instantiating the desired authentication module(s) or (with more complexity) by creating an authentication chain. Post authentication processing steps are developed programmatically through implementation of a provided interface. The following sections contain information on these considerations.
A detailed technical explanation of the authentication process through session validation and policy evaluation is in Chapter 6, Models of the User Session and Single Sign-On Processes, in Sun OpenSSO Enterprise 8.0 Technical Overview.
The Authentication Service user interface provides a means for gathering the credentials needed by the Authentication Service to validate a user. In most cases, the Authentication Service user interface is accessed by entering a login URL into the Location Bar of a web browser. A URL parameter may be appended to the end of the URL to define, for example, specific authentication types or redirection URLs. The format of this URL is:
http://OpenSSO-server..domain_name:port/service_deploy_uri/UI/Login?parameter1=value1¶meter2=value2¶meterN=valueN |
During installation, the service_deploy_uri is configured as opensso.
After entering this URL, login screens are dynamically displayed based on the invoked authentication module, and a user is able to communicate an identifier and password, for example, back to the Authentication Service to receive (or not receive) validation. For more information on accessing the Authentication Service, see Accessing the Authentication Service User Interface with a Login URL.
An authentication module is a plug-in that collects information from a principal requesting access to a protected resource and checks the information against entries in a data store. If the information provided meets the authentication criteria, the user is validated. If the information provided does not meet the authentication criteria, the user is denied validation. OpenSSO Enterprise provides a number of authentication modules. You instantiate an authentication module before accessing it for a simple authentication process (see Authentication Types), or adding it to an authentication chain. (In an authentication chain, you can configure, for example, two instances of the LDAP authentication module — each pointing to a different LDAP data store configured within the same realm; or you can configure different authentication modules so a user must pass authentication credentials to all of them for validation.)
The following sections contain information about the individual authentication modules provided by OpenSSO Enterprise. Some of them require configuration before they can be instantiated. Where applicable, the configuration steps are listed in the module type descriptions.
The Active Directory authentication module performs authentication in a manner similar to that of the LDAP module, but uses Microsoft’s Active Directory™ server. Although the LDAP authentication module can be configured for Active Directory, using this module allows you to have both LDAP and Active Directory authentication exist under the same realm. For information on the Active Directory authentication module attributes, see Active Directory in Sun OpenSSO Enterprise 8.0 Administration Reference.
For this release, the Active Directory authentication module only supports user authentication and password policy is only supported in the LDAP authentication module.
The Anonymous authentication module allows a user to log in to OpenSSO Enterprise without specifying validating credentials. Anonymous connections are usually customized by the OpenSSO Enterprise administrator so that Anonymous users have limited access to the server (for example, access for read or access for search), or to specific trees or entries within the identity data store. A list of anonymous users can be defined by adding the applicable user identifier(s) to the module's Valid Anonymous Users attribute. Granting anonymous access means that it can be accessed without providing a password. A default anonymous user is created during OpenSSO Enterprise installation. For information on the Anonymous authentication module attributes, see Anonymous in Sun OpenSSO Enterprise 8.0 Administration Reference.
The Certificate authentication module requires a personal digital certificate (PDC) to identify and authenticate a user. The module can be configured to require a match between the user's PDC and a PDC stored in the configuration data store, as well as verification against a Certificate Revocation List. It can also require the use of the Online Certificate Status Protocol (OCSP) to determine the state of a certificate. Successful or failed authentication is dependent on whether or not the certificate is valid. The following information should be considered before using the Certificate authentication module.
The web container that is installed with the OpenSSO Enterprise needs to be secured and configured for Certificate-based Authentication.
To add this module, log in to OpenSSO Enterprise as the realm Administrator and have OpenSSO Enterprise and the web container configured for SSL and with client authentication enabled.
To check the certificates presented by a client against those found in a directory server, import the root CA certificate for the client certificate into the trust store of the JVM on the OpenSSO Enterprise host machine (by default JDK_HOME/jre/lib/security/cacerts). You can use the keytool command line interface.
If you are configuring OpenSSO Enterprise Certificate authentication with an SSL-enabled Sun Java System Web Server 6.1 instance, and wish to have the Web Server defined to accept both certificate based and non certificate based authentication requests, you must set the following value in the Web Server's obj.conf file:
PathCheck fn="get-client-cert" dorequest="1" require="0 |
This is due to a limitation in the Web Server console when setting the optional attribute for this behavior. Is this the web container on which OSSO is deployed?
Before enabling the Certificate-based module, see Using Certificates and Keys in the Sun ONE Web Server 6.1 Administration Guide at http://docs.sun.com/db/prod/s1websrv#hic or the Sun ONE Application Server Administrator’s Guide to Security at http://docs.sun.com/db/prod/s1appsrv#hic for initial configuration steps.
Each user that will authenticate using the Certificate authentication module must request a PDC for the browser. Instructions depend upon the browser being used. See the specific documentation for more information.
For information on the Certificate authentication module attributes, see Certificate in Sun OpenSSO Enterprise 8.0 Administration Reference.
The Data Store authentication module allows a user to authenticate against one or more of a realm's identity data stores (depending on the authentication process configuration). This authentication module is enabled after installation to authenticate to the identity data store configured for the top level realm during installation. Depending on the deployment, this might be the embedded configuration data store (for user storage in sample deployments) or a defined external data store (for user storage in real world deployments). If you change the identity data store definition for the top level realm, the Data Store authentication module adapts to the modified data store definition. After installation, additional identity data stores can be added to the top level or sub realms and configured for Data Store authentication. The Data Store authentication module extends the com.sun.identity.idm.IdRepo interface. You can include or remove a configured data store from identity authentication by unchecking User in the Identity Types That Can Be Authenticated attribute in the Data Store profile. For more information on the Data Store authentication module attributes, see Data Store in Sun OpenSSO Enterprise 8.0 Administration Reference.
The Federation authentication module is used by all federation protocols implemented by OpenSSO Enterprise (including SAML v1.x and SAML v2, Liberty ID-FF, and WS-Federation). This module can not be invoked as other authentication modules. (If you do this, you have to provide the necessary authentication callbacks as it will not initiate single sign-on and provide them itself.) The Federation authentication module requires a federation setup and will be invoked internally on the service provider side to create an SSOToken after validating the federation protocol messages. For information on the Federation authentication module attributes, see Federation in Sun OpenSSO Enterprise 8.0 Administration Reference.
The HTTP Basic authentication module uses basic authentication in the context of HTTP communication. A web browser issues a request for a username and password, and sends the credentials to the web server as part of the authentication request. OpenSSO Enterprise retrieves the username and password and authenticates the user using the LDAP authentication module. In order for HTTP Basic to function correctly, both the LDAP authentication module and the HTTP Basic authentication module must be added to the appropriate realm. Once the user successfully authenticates, the user will be able to authenticate again without being prompted for username and password. For information on the HTTP Basic authentication module attributes, see HTTP Basic in Sun OpenSSO Enterprise 8.0 Administration Reference.
The Java Database Connectivity (JDBC) authentication module provides a mechanism to allow OpenSSO Enterprise to authenticate users through any SQL database that provides JDBC technology-enabled drivers. The connection to the SQL database can be either directly through a JDBC driver, or through a JNDI connection pool. For information on the HTTP Basic authentication module attributes, see JDBC in Sun OpenSSO Enterprise 8.0 Administration Reference.
This module has been tested on MySQL4.0 and Oracle 8i.
The LDAP authentication module uses a Distinguished Name (DN) and password to authenticate to an LDAP data store. If the submitted credentials are found in the directory, the user is authenticated and an SSOToken created. This module is enabled during OpenSSO Enterprise installation for the top level realm. For information on the LDAP authentication module attributes, see LDAP in Sun OpenSSO Enterprise 8.0 Administration Reference.
The Membership authentication module is implemented for personalized sites where a user is able to create an account and define preferences without the aid of an administrator. Once created, the user can access the resource as an added user. After the account is created, the user can authenticate to the appropriate OpenSSO Enterprise realm as configured. For information on the Membership authentication module attributes, see Membership in Sun OpenSSO Enterprise 8.0 Administration Reference.
The Mobile Station Integrated Services Digital Network (MSISDN) authentication module enables authentication using a mobile subscriber ISDN associated with a device such as a cellular telephone. It is a non-interactive module. The module retrieves the subscriber ISDN and compares it against the data store to find a user that matches the number. If found, the user is validated. For information on the MSISDN authentication module attributes, see MSISDN in Sun OpenSSO Enterprise 8.0 Administration Reference.
The RADIUS authentication module enables authentication to an installed and configured RADIUS server currently being used for authentication. For information on the RADIUS authentication module attributes, see RADIUS in Sun OpenSSO Enterprise 8.0 Administration Reference. See Before You Begin for special pre-configuration instructions when using the RADIUS authentication module.
The Secure Attribute Exchange (also known as Virtual Federation) authentication module is used when an external entity (such as an existing application) has already authenticated the user and wishes to securely inform a local instance of OpenSSO Enterprise to trigger the creation of an SSOToken for the user. This module is also used when the existing entity instructs the local instance of OpenSSO Enterprise to use federation protocols to transfer authentication and attribute information to a partner application. This module can not be invoked as other authentication modules. It requires setting up parties for Secure Attribute Exchange and will be invoked internally. For information on the Secure Attribute Exchange authentication module attributes, see SAE in Sun OpenSSO Enterprise 8.0 Administration Reference.
The SafeWord authentication module handles authentication requests to Secure Computing’s SafeWord™ or SafeWord PremierAccess™ authentication servers. The SafeWord server may exist on the system on which OpenSSO Enterprise is installed, or on a separate system. For information on the SafeWord authentication module attributes, see SafeWord in Sun OpenSSO Enterprise 8.0 Administration Reference. See Before You Begin for special pre-configuration instructions when using the SafeWord authentication module.
The SecurID authentication module handles authentication requests to RSA’s ACE/Server authentication servers. OpenSSO Enterprise provides the client portion of SecurID authentication. The ACE/Server may exist on the system on which OpenSSO Enterprise is installed, or on a separate system. For information on the SecurID authentication module attributes, see SecurID in Sun OpenSSO Enterprise 8.0 Administration Reference.
The SecurID Authentication module is available for the Solaris/SPARC, Solaris/x86, Linux, and Windows platforms.
The Unix authentication module is a Pluggable Authentication Module (PAM) that authenticates user identifiers known to the Solaris or Linux system (local or NIS) on which OpenSSO Enterprise is installed. This module makes use of an authentication helper daemon called amunixd which opens a socket on a specified port in order to listen for Unix authentication requests. This daemon process is separate from the authentication process. The PAM Service Name attribute defaults to other for Solaris, and password for Linux. For information on the Unix authentication module attributes, see Unix in Sun OpenSSO Enterprise 8.0 Administration Reference. For instructions on setting up and running amunixd, see Running the Unix Authentication Helper (amunixd Daemon) in Sun OpenSSO Enterprise 8.0 Installation and Configuration Guide.
The Windows Desktop SSO authentication module is a Kerberos-based authentication plug-in module targeted for Windows™ desktop users. It allows a user who has already authenticated to a Kerberos Distribution Center (KDC) to authenticate to OpenSSO Enterprise without re-submitting login credentials (in effect, single sign-on). In order to perform Kerberos-based single sign-on to OpenSSO Enterprise, the user on the client side must support the Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) protocol. (In general, any user that supports this protocol should be able to use this module.) The user presents the Kerberos token to OpenSSO Enterprise using SPNEGO and the client sends back a SPNEGO token embedded with a Kerberos token. The module retrieves the Kerberos token, authenticates the user using the Java GSS API and, if successful, returns an SSOToken to the client.
You must use JDK 1.4 or above to utilize the new features of Kerberos V5 authentication module and Java GSS API to perform Kerberos based SSO in this SPNEGO module.
For information on the Windows Desktop SSO authentication module attributes, see Windows Desktop SSO in Sun OpenSSO Enterprise 8.0 Administration Reference. See Before You Begin for special pre-configuration instructions when using the Windows Desktop SSO authentication module.
The Windows NT authentication module handles authentication against an installed Windows NT or Windows 2000 server. For information on the Windows NT authentication module attributes, see Windows NT in Sun OpenSSO Enterprise 8.0 Administration Reference. See Before You Begin for special pre-configuration instructions when using the Windows NT authentication module.
The WSSAuth authentication module is used for authenticating the WS-Security Username Token profile when using the digest option. When configured as part of the authentication chain in the web services provider (wsp) agent profile, the user is authenticated using the user name and password (or password equivalent) presented via the Username Token profile. The communicating WSC and WSP must agree upon a common password policy in their back end.
The authentication type specifies from where the authentication process will be initiated. The authentication type is specified by appending the appropriate parameter to a login URL, or through the authentication API. OpenSSO Enterprise supports the following authentication types:
Authentication level allows authentication based on a security level defined for each authentication module by an administrator.
Module allows authentication by specifying an authentication module instance.
Realm allows authentication using the authentication process defined for a specific realm.
Service allows authentication using the authentication process defined for a specific service or application.
User allows a user to authenticate using the authentication process defined in the user's profile.
For each of these authentication types, the user can either pass or fail the defined authentication process (either a module or a chain). For more information, see Initiating the Authentication Type. For more information on specifying an authentication type, see Accessing the Authentication Service User Interface with a Login URL.
Post processing functionality can be added to the authentication process. This would define actions taken after a successful or failed authentication. For more information see Adding Authentication Post Processing Features in Sun OpenSSO Enterprise 8.0 Developer’s Guide.