You might have noticed that OpenSSO requires authentication to perform any kind of activity, whether to read the audit records or to access a particular user identity, irrespective of the access point (GUI or CLI). So authentication is a must in order to interact with the server. What is authentication anyway? Well, authentication is the process of identifying and proving the identity of an entity; for example, a user, a computer, or an application. Typically authentication is established by verifying a username and password or a digital certificate in a Public Key Infrastructure (PKI) deployment. Authentication service is a key function of the OpenSSO server; all the unauthenticated requests to the server pass through this service first. It is highly likely that a malicious user could employ a brute force attack on this service to guess a password of another user, and this kind of attack could lead to a DOS (Denial of Service). The server does provide a slew of measures (such as account lockout on invalid credentials) to prevent these kind of attacks.
OpenSSO comes with extensive authentication modules that support most of the commercial authentication protocols. If you do not find the one that you are looking for, then it is easy to plugin your authentication module using the Java Authentication and Authorization Service (JAAS) Service Provider Interface (SPI). At the end of the chapter there is an example of how to add a custom authentication module to the server.
On the other hand the session service, which is also a core part of the server, works in association with the authentication and logging service to complete the authentication process. Once the identity of the user or application is verified, a valid session will be created in the server instance memory (and in the session repository if configured). A session is a time period between the successful authentication (a login event) and revocation of authentication (a logout event). You can learn more about the session life cycle in the later part of this chapter. A successful authentication results in a valid session of course and which is subjected to the session quota limitations. I am planning to leverage the ssoadm command line tool for creating the examples for this chapter. Using the console for this purpose is a trivial task.
In this chapter we are going to learn about the following concepts of OpenSSO:
- What is authentication service?
- Various cookies and their roles
- Types of authentication modes
- Out of the box support for authentication protocols
- Adding a custom authentication module
- Session service and its features
The authentication service of the OpenSSO system can be accessed via a web browser. It also provides an XML and Java interface, which enable non-web based applications to authenticate to OpenSSO. Any Java application uses the Java APIs either locally or remotely. Non-Java applications can use the XML messages sent over HTTP(S) to authenticate to the server. The authentication user web interface is based on the Model-View-Controller (MVC) architecture design framework, in order to facilitate the most dynamic and customizable user interface by clearly separating the presentation layer from business logic. This interface provides dynamic and customizable means for gathering authentication credentials requirements of all plugged in authentication modules at runtime via a single phase or multi-phase user interaction. A single phase authentication, such as a username and password authentication, is in many cases no longer considered as secure in the enterprise world, as users tend to use "easy-to-remember" and hence "easy-to-guess" passwords, such as their family name and/or date of birth. This prompts security product vendors to provide a more secure way of performing authentication using the multi-phase authentication process. In the multi-phase (or multi-factor) authentication, a user is authenticated by means of verifying at least two credentials, one what they know (such as PIN) and what they own (such as Securid Fob). For this reason it is sometimes known as strong authentication. A session or a token or SSO token all refer to a valid authenticated identity's session and these terms are interchangeably used throughout this book.
Invariably the authentication framework is responsible for creating the session for the authenticated identity. It does provide an extensive feature set to address various deployment use cases including running behind a firewall, proxy, or a load balancer (LB). There is a special web application called distributed authentication (DA) that grants access to the authentication interface in the demilitarized zones (DMZs). Without these the clients such as the OpenSSO policy agents need to penetrate two levels of firewalls in secure deployments in the DMZs. There is one caveat though. In the federation SSO you are still required to penetrate the DMZ.
The authentication process begins when the client identifies the type of authentication and module instance. Then it looks up to the specific module configuration for the callback information. Once all the callback requirements (this callback depends on the module) are completed successfully then the identity principal is determined to set in the session token—this principal is referenced across the OpenSSO. An appropriate exception LoginException is thrown when any of the required callbacks fail or any other error occurs in the authentication process. Final session issuance is subject to the user profile requirement settings of the realm as mentioned in section the User Profile Requirement section.
The Single Sign-On (SSO) session is based on a browser cookie. A cookie is a small collection of information that can be transmitted to a calling browser, which retrieves it on each subsequent call from the browser so that the server can recognize calls from the same client. A cookie is returned with each call to the site that created it, unless it expires.
Sessions are maintained automatically by a session cookie that is sent to the client when the session is first created. The session cookie contains the session ID, which identifies the client to the server on each successive interaction.
In OpenSSO there are multiple cookies involved, and not all the cookies are set every time. Let us look at these cookies, their values, and the time when they will be set during the authentication process as shown in the following table. It is also possible that custom cookies are set in a cross domain single sign-(CD-SSO) in the scenario with cookie hijack prevention mode enabled, but in a simple deployment configuration only the cookies described in the first table are relevant.
Authentication service provides numerous options to access its services from clients which we will discuss shortly. The browser-based user interface is predominantly used in the OpenSSO deployments, nevertheless, there are applications that require zero page or zero interaction login. In this case there can be no interaction during the authentication as all the credentials and associated data will be presented to the authentication service in one single pass. The server will use the provided information to issue the SSO token, provided the credentials submitted are verifiable. To achieve this in the OpenSSO there are parameters that can be supplied along with the authentication URL. These parameters are frequently used in the deployment to invoke a specific realm configuration or to redirect the browser to a different location such as the protected resource (Chapter 6 deals with the protected resources) after authentication.
A parameter is a name/value pair appended to the end of the login URL. The parameter starts with a question mark (?) which is followed by the form name=value. Multiple parameters are appended using an ampersand (&) symbol.
|
Cookie name |
Is customizable |
Default value |
Description |
|---|---|---|---|
|
Login Context Cookie |
Yes, using the property
|
AMAuthCookie |
It is the authentication cookie set at the beginning of the authentication process, discarded after successful authentication. |
|
SSO Token Cookie |
Yes, using |
iPlanetDirectoryPro |
It is set after successful authentication, it is the actual session cookie forwarded to the client applications. |
|
Load Balancer Cookie |
Yes, using the properties
|
amlbcookie 01 |
It is the load balancer cookie that enables to set the server affinity based on this cookie. Use this cookie in your LB to configure the session persistence, though the session persistence is not mandatory to set but it is recommended that customers use session persistence to improve the performance. |
|
Persistent Session Cookie |
Yes, using the property
|
DProPCookie |
It is set only when the persistent cookie feature is enabled and the URL parameter |
These parameters play the vital role in determining what kind of authentication is being requested by the client. Broadly there are seven different kinds of authentication types supported by the OpenSSO:
- Module
- Level
- Service
- Role
- User
- Realm (domain and organization)
- Resource
To perform any of these authentication types, the primary requirement is to have each configuration created. Authentication instances are the minimum requirement for this. An authentication instance is a copy of a generic type of a particular authentication protocol service; for instance, the RADIUS authentication service. Each instance of a particular type has identical template structure but unique values for the instance properties. All the authentication protocols are defined as a service with specific XML schema when the server is configured. Custom authentication modules can be created at any point of time.
A module-based authentication can be invoked using the module parameter along with the authentication URL. The value for the module could be any valid authentication instance name that has already been created in the server. A URL of this form http://opensso.packt-services.net:8080/opensso/UI/Login?module=packt-radius invokes the RADIUS authentication service to authenticate the user. packt-radius is the instance created from the RADIUS generic service provided by the OpenSSO. On successful authentication the session properties AuthType with value packt-radius (representing the instance name of the module) and IndexType with a value module_instance (identifying the session is created with module-based authentication) will be set. There are other properties in the session along with these two properties. Please refer to the section titled 'Session Properties found later in this chapter.
While creating the authentication module instances there is a configuration property that takes a numeric value as the authentication level. This can be considered as the authentication strength for each module and can be set to a higher value for strong authentication modules such as RSA SecurID. Classified data can be protected with higher authentication levels. For example, an employee and a financial manager can have access to the corporate documents with a minimum-strength authentication level. When the financial manager wants to access the company's confidential financial data, he will be forced to authenticate to a higher authentication level. In such scenarios, level-based authentication would be appropriate. It uses the parameter authlevel to invoke the level-based authentication using the URL of the form: http://opensso.packt-services.net:8080/opensso/UI/Login?authelevel=22. When the current session is already on the higher strength then any attempt to authenticate to a lower strength will not be honored using the same session. When there are multiple modules configured with the same strength, then the client will be presented with the list of options to choose from.
A service-based authentication relies on the authentication chain configuration. An authentication chain can be created with one or more authentication module instances. Authenticating using the authentication chain requires all the module instances in the chain to be satisfied unless the OPTIONAL keyword is specified. If any one of them fails, then the whole authentication process will be halted. A service-based authentication can be performed by appending the service parameter along with the login URL and a valid authentication chain name. A URL of http://opensso.packt-services.net:8080/opensso/UI/Login?service=mychain form will invoke the service-based authentication using the authentication chain named mychain. In this type of authentication, the session property IndexType will be set to service to denote the type of authentication.
It is yet another flexibility provided by the authentication service to fine tune the authentication types to the user identity level. A realm administrator can configure specific module instances for each of the users by leveraging the user-based authentication feature of the server. A user-based authentication can be invoked by supplying the user parameter along with a valid OpenSSO user identity's name. Assuming the user jsmith configured to access the LDAP authentication module instance, this user will invoke the http://opensso.packt-services.net:8080/opensso/UI/Login?user=jsmith to get in to the system. In this type of authentication the session property IndexType will be set to user to denote the type of authentication. This property can be leveraged by the remote applications to determine what kind of authentication mechanism is used by the client to obtain the session.
A role based authentication is pretty much the same as of the user-based authentication except that instead of user parameter, role will be used in the URL. In lieu of a username, a role identity name will be used at the time of invoking the authentication service. This type of authentication is supported only in the legacy mode of the OpenSSO server, that is you should configure the Access Manager Repository to perform a role based authentication. If you have configured a proper authentication chain for the role manager, a role-based authentication for the manager role can be performed using http://opensso.packt-services.net:8080/opensso/UI/Login?role=manager. In this type of authentication the session property IndexType will be set to role to denote the type of authentication.
If you have noticed in the URLs that we have used so far, it does not mention in which realm the users need to be authenticated. However, the server knows what needs to be done if no realm parameter is present in the URL. It will assume the root realm on seeing no realm in the URL or it will use realm aliases. The realm parameter is used to tell the server the realm that the client is trying to authenticate to. An invocation of http://opensso.packt-services.net:8080/opensso/UI/Login?realm=/sales&module=sales_ldap will present the LDAP authentication page for the user to authenticate into the sub realm sales, provided a valid sales_ldap instance exists. The domain and org parameters are meant to be used in the legacy Access Manager Repository's co-existence mode in the same manner as the realm parameter.
All the authentication types that we have discussed in the preceding sections are predetermined, in the sense that the invoking client knows what kind of credentials are required for the page being requested. Every time the same kind of authentication modules will be presented. In certain deployments, customers might want to dynamically (at the runtime) choose a particular authentication type based on the clients' environment properties. For example, a banking institution may enforce a strong authentication when the client is accessing the application from a different geographic location than its usual place. To address the dynamic selection of authentication module resource-based authentication can be leveraged. A resource-based authentication works in concurrence with the OpenSSO policy service. It is a policy services that advises the authentication service what kind of authentication module to invoke after evaluating the clients environment parameters.
Resource authentication is based on the client environment variables defined in the HTTP request parameters and/or HTTP request header. After receiving a request for access, the authentication service passes the resource name and appropriate environment parameters to the policy service to determine the authentication type to be used. The policy service returns an advice message to indicate the appropriate authentication type to call. The client is then prompted for the appropriate credentials for the authentication type. The key here is that the policy that protects the resource (typically a URL) should contain the logic to determine what type of authentication is to be used based on the clients' environment parameters such as IP address. [http://developers.sun.com/identity/reference/techart/ipresenvauthopensso2.html#uc2]
A resource-based authentication can be invoked either via supplying resourceURL=<resourceName> or resource=true&goto=<resourceName> parameters. For example, if the resource http://www.google.com is configured with appropriate resource conditions, then any one of the following URLs initiate a resource-based
authentication http://opensso.packt-services.net:8080/opensso/UI/Login?resource=true&goto=http://www.google.com or http://opensso.packt-services.net:8080/opensso/UI/Login?resourceURL=http://www.google.com. Without a goto parameter, resource=true alone will not initiate the resource based authentication.
There are other authentication parameters that can be used to configure certain use cases that could not be covered by the parameters discussed so far. For instance the zero-page login does return a valid session provided the submitted credentials are correct. Not all the authentication protocols can be used with zero-page login. For example, the challenge/response authentication modules may not participate in the zero page authentication. Any username and password-based authentication such as LDAP can be used for zero-page authentication. The username and password information is sent to the server using the URL parameter IDTokenN where N is a numeric value. When you type http://opensso.packt-services.net:8080/opensso/UI/Login?IDToken1=demo&IDToken2=changeit in the browser location bar you would be presented with the profile of the demo user. Note that there is no login page rendered for the zero-page login. By the way, all the URL parameters are case sensitive.
The IDToken parameter is used to map the credentials from the authentication page from the field values that user's enter through the browser. This parameter enables a user or application (an agent identity) to pass authentication credentials using the login URL, allowing authentication without accessing the authentication service user interface. As described above, the zero-page login leverages this parameter to obtain a session. This is very useful to quickly validate whether the agent identity can authenticate to the server using http://opensso.packt-services.net:8080/opensso/UI/Login?module=Application&IDToken1=myagent&IDToken2=myagent. Note that the IDToken0 is used for the username as opposed to IDToken1. This is applicable only for the agent identity authentication (module=Application). For security reasons you should always consider using the HTTP/POST for submitting user credentials over the wire. OpenSSO 8.0 Update 2 release made some security fixes that disabled the GET method for submitting the credentials.
In an enterprise deployment, OpenSSO can be used as a trusted authentication authority to issue the Single Sign-On tokens. Users can use this token to access the other applications such as calendar, e-mail, and so on from a corporate portal. On successful authentication users needs to be sent back to a secure portal, and this can be accomplished by using the goto parameter along with the authentication URL. The OpenSSO policy agents extensively use goto to redirect the client back to the protected resource after authentication.
Note
In this example the user, after authenticating to the realm /sales, will be taken to Google's home page. http://opensso.packt-services.net:8080/opensso/UI/Login?realm=/sales&goto=http://www.google.com.
Akin to the successful login, it is also possible to use goto after a successful logout from the system. Some financial institutions recommend closing the browser after logout and this can be achieved by using the goto parameter to send the user's browser to the post logout page where the message about closing the browser can be displayed.
Unlike the goto parameter, the gotoOnFail parameter can be used to send the client to a page after an authentication attempt has failed. For instance clients can be redirected to a password reset page or a self-registration page in case of authentication failure.
Note
In this case the users will be redirected to the password reset page of the OpenSSO server after the authentication failure. http://opensso.packt-services.net:8080/opensso/UI/Login?realm=/sales&gotoOnFail=http://opensso1.packt-services.net:8080/opensso/password?realm=/sales.
In general these authentication success and failure URLs can be configured at different levels for a user identity. The order of precedence would be the goto to the URL, user, role, realm, and Global. First it will look for the success (or failure) URL in the url goto (gotoOnFailure) parameter, if not available it will check in the authenticated identity's profile for the attribute iplanet-am-auth-login-success-url (iplanet-am-auth-login-failure-url), which if not available will be checked in the service role and so on, and so forth.
OpenSSO has the capability of displaying screens that are translated into languages other than English. These localized screens can be configured for the authentication process as well as for the console itself. The locale=language-locale parameter allows the specified locale to take precedence over any other defined locales for the authentication process.
Note
If you want to invoke the authentication interface in French locale use: http://opensso.packt-services.net:8080/opensso/UI/Login?locale=fr.
The login locale will be determined in this order:
localeparameter in the URL- Locale defined in the user's profile using the attribute
preferredlocale - Locale set by the browser
- Locale defined in the core authentication properties
- Locale defined in the OpenSSO platform service
- JDK locale
- Operating system locale
The locale derived from this logic is stored in the user's session and the server uses it for loading the localized authentication module only. After successful authentication, the locale defined in the preferredlocale attribute of the user's profile is used.
Clients can use this parameter to force the browser to kill any existing sessions for the server and create a new session based on the credentials submitted. This will be useful if you are already logged into a realm but wanting to authenticate to a different realm. Without the arg parameter you will be prompted with a page for confirmation to kill the existing session.
Note
Zero page authentication of this type would destroy any existing sessions and obtain a new session for the user demo.http://
opensso.packt-service.net:8080/opensso/UI/Login?arg=n
ewsession&IDToken1=demo&IDToken2=changeit.
This parameter is used to instruct the server to create a persistent cookie, provided the persistent cookie is enabled (Persistent Cookie Mode) in the core authentication properties. If the persistence cookie is not enabled at the server side, then sending this parameter does not make any difference. A persistent cookie is one that continues to exist even after the browser window is closed. If the user is successfully authenticated and the browser is closed, the user can login with a new browser session and will be directed to the console without having to authenticate again. By default this cookie is valid for 25 days, but it can be configured for a lesser value too. This stays valid until it expires or the user explicitly logs out from the server by clicking on the logout link. Just closing the browser does not remove this persistent cookie. To view the cookie you have to look into your browser cookie database with name, DProPCookie. Note that it is different from the session (SSO token) cookie, iPlanetDirectoryPro. A persistent cookie will create a session cookie every time the browser is reopened with the login URL with iPSPCookie=yes as a parameter.
The ForceAuth=true query parameter forces the user to authenticate even if the user currently has a valid session. This parameter is useful in the following case.
When the user is performing the session upgrade with this parameter then the existing session ID and the session property values such as the max user session are retained with the existing session's value. Only the moduleAuthTime and AuthType properties are updated. This is useful if the admin wants to control the max session time of a user by allowing to upgrade the session without extending the current session. Without the ForceAuth=true parameter, whenever a user does a session upgrade after a successful upgrade, the user's max session time (for that matter all the session-related properties) will be reset to the original value configured in the session service of the realm to which the user authenticated.
In an authenticated session, the cookie is lost if the browser is restarted. There have been OpenSSO deployment requests to make it persistent so that the cookie would be saved on disk and survive browser restart. This is different from the persistent cookie DProPCookie. With persistent cookie a new session is created because of DProPCookie, not the original one that we lost due to browser restart.
The PeristentAMCookie parameter is about retrieving the same session instead of creating a new one. It is just a handle to the current and active session. The expiry time for this persistent cookie would be much shorter and should be set less than idle session time that is configured for the current session.
The PersistAMCookie parameter will save the OpenSSO Enterprise session cookie to the memory disk, thereby allowing an application (other than the browser) on the same machine to read it and create an SSO token. You need to set a valid numeric value (N) in minutes for the com.iplanet.am.cookie.timeToLive property in the OpenSSO server to enable the cookie to be stored in the disk for N minutes.