With Access Manager, enterprises can ensure secure access to applications, both on the intranet and the extranet. In addition, enterprises can implement Single Sign-on (SSO), a cost-effective security solution that streamlines user experience. In a federated identity framework, linking various user accounts to the authoritative account with open standards makes SSO integration between applications simple and straightforward.
This article offers best-practice tips on how to efficiently integrate applications with Access Manager and implement SSO in three environments:
- Non-federated
- Cross-domain
- Federated with the Liberty implementation of Access Manager
To better understand this article, you should be familiar with Access Manager and its components. For details, see the product documentation.
Contents
Single Sign-On
Single Sign-On (SSO) is the means of passing users' credentials between applications without users having to authenticate each time they access another application--in essence a mechanism to seamlessly identify users across various identity domains. This section describes the aspects you must consider in enabling SSO with Access Manager and discusses a number of best practices.
Robust applications usually provide mechanisms for integration with external authentication and authoritative sources. With Access Manager, you can achieve SSO in many ways; deciding which one to pick depends on how to best integrate your applications.
You can obtain user credentials with or without policy agents, as follows:
- Install a policy agent to protect the application and then pass the
HTTP_HEADER and REMOTE_USER variables to the application so as to capture the user credentials. You may or may not need a custom authentication module.
- Customize the application's authentication module to create an SSO token (
SSOToken) either from the request object or from the SSO cookie. Afterwards, retrieve the user credentials via SSO APIs and then create a session using the application's APIs.
Authentication
Authentication is the process of validating user credentials, usually user IDs accompanied by their associated passwords. Observe the following practices:
- Use the Access Manager policy agents to protect the application URL. These agents support numerous Web servers and application servers that are available in the market today.
- Let Access Manager--along with Directory Server--be the authoritative source for authentication and adopt the provisioning solution from Sun Java System Identity Manager. The protected application would simply redirect user requests to Access Manager for authentication.
You can authenticate users with Access Manager in either of these two ways:
- Use the policy agent to insert HTTP header variables into the request object--a means that functions for Web applications only. The benefit: Applications can authenticate through Access Manager with minimal (if any) changes to the code.
- Use authentication APIs bundled as part of the Software Development Kit (SDK) to validate and retrieve user identities--a means that can be employed by both Web and non-Web applications. The benefit: Security is then ensured.
Authorization
Authorization is the process of deciding whether to allow or deny an action, for example, a user request or a service request.
Implement a shared or internationalized authorization model. The best practice is to centralize authorization in Access Manager. If that's not possible, employ a shared mode, by which you can pass the principal to the application to retrieve policies and perform other related tasks.
You can implement authorization by means of policy agents or APIs, as follows:
- Use policy agents to protect an application URL (declarative or configuration security); the application assumes that another entity is controlling the access. This mechanism works best for URL-based resources or simple applications.
- Embed the Access Manager API within an application (programmatic security) to evaluate and determine access policies. This mechanism accords more granular control to the application.
User Management
Follow these suggestions for administering the user database:
- Externalize the user administration process by making Access Manager the central repository for the user database: that is, have all applications use either the Access Manager repositories or synchronize the data stores.
- Extend the schema to add application-specific attributes to the user data.
- Access identity objects in Directory Server through the Access Manager APIs. Do not use the Lightweight Directory Access Protocol (LDAP), Java Developer's Kit (JDK), the LDAP Software Development Kit (SDK), or the Java Naming and Directory Interface (JNDI) APIs. Access Manager provides a wrapper to those underlying APIs, hence rendering applications vendor-agnostic and less complex.
Session Management
Become familiar with SSO API and the many alternatives for creating SSO tokens.
 |
Note - Use the createSSOToken(user, password) method from the SSOTokenManager class in the com.iplanet.sso package for command-line applications only. Tokens created with this method are valid only within the context of the calling application. Once the process exits, the tokens are destroyed.
|
|
Bear in mind the following tips when managing sessions in Access Manager:
- Ensure that when a user logs out of an application, the associated Access Manager
createSSOToken(user, password) session also ends simultaneously. Transparently to the user, you can redirect the session to a page that reaffirms the logout. Alternatively, you can destroy the token with SSO APIs and call them in the logout method of the application.
- Be sure that your solution also addresses the possibility of an Access Manager session being terminated for other reasons. For those other cases, terminate the application session and redirect the user to Access Manager for another login.
To terminate an application session, do either of the following:
- Register the application for the
SSOTokenListener interface so that the application receives notification of the termination and cleans up as necessary.
- Apply the logout capability as described in Appendix A, "
AMAgent Properties" in the Web Policy Agents Guide to terminate the session on Access Manager.
To implement this capability, manually edit the AMAgent.properties file after installing Access Manager and set the following properties for the logout URL feature (in addition to the other properties for your application):
com.sun.am.policy.agents.logout.url = list of logout URLs, separated by spaces
com.sun.am.policy.agents.logout.cookie_reset_list = list of cookies to be reset upon logout, separated by spaces
For example, the line below resets the iPlanetDirectoryPro cookie in the default domain (the first one), the host (the second one), and the red.iplanet.com domain (the last one):
iPlanetDirectoryPro, iPlanetDirectoryPro;
Domain=, iPlanetDirectoryPro;red.iplanet.com
Agent Configurations
Here are more tips on how to configure URL Policy Agents:
- First configure the agent as
SSO_ONLY to ensure that users are authenticated against Access Manager's authentication service before being granted access to protected applications. Afterwards, reconfigure the agent according to your access-control requirements.
- When you install a policy agent in Sun Java System Application Server (called Application Server for short) to protect an application that is bundled with an XML parser, then as soon as you redeploy that application, the agent settings disappear. To recover those settings, you must restart Application Server.
To avoid a restart, verify that the application uses the same parsers loaded by the agent, unbundle the application and delete the parser libraries, and then redeploy the application.
Cross-Domain SSO
You can implement cross-domain SSO in Access Manager in one of three ways:
- Set up policy agents. Yet another benefit for implementing SSO with policy agents is that you can extend the implementation across domains later on if necessary.
- Apply the Security Assertions Markup Language (SAML) SSO profile.
- The best practice is to adopt the federation and SSO extensions to SAML offered by the Liberty Alliance.
Liberty Alliance is a standards body with participation by many industrial leaders to define the standards for federating and managing identities. Adhering to standards makes applications more interoperable.
Federated SSO
An identity interacts with two types of entities:
- Service-provider applications that conduct business and deliver information online
- Identity providers that maintain and manage identity data
Identity federation is a way of binding or associating an identity across service providers and identity providers.
To set up federated SSO, you must first establish SSO integrations as described in the preceding sections. Afterwards, configure the SSO integrations and enable the application to take part in a federation with Access Manager in a service-provider role that forms the infrastructure for Liberty protocols.
See the following sections for tips and tricks.
Synchronized Clock
In a federation setup, all service providers and identity providers must share a synchronized clock. You can implement the synchronization by pointing to an external clock source or by ensuring that, in case of delays in receiving responses, the responses are captured without fail through adjustments of the timeouts.
Prelogin Configurations
Consider this case: In a federation setup, Access Manager acts as a service provider and manages an application that runs on a different instance of Sun Java System Web Server. You must configure the agent that is protecting this application as follows:
- Point the
com.sun.am.policy.loginURL entry in the AMAgent.properties file to the prelogin service URL that is running with Access Manager.
For example:
com.sun.am.policy.loginURL = http://www.sp1.com:58080/amserver/preLogin?metaAlias=www.sp1.com
- Point the
com.sun.am.policy.am.library.loginURL in the AMAgent.properties file to the login URL of Access Manager in the service-provider role.
For example:
com.sun.am.policy.am.library.loginURL = http://www.sp1.com:58080/amserver/UI/Login
Global Logout on Service-Provider Application
For all service-provider applications, implement the logout process with the Liberty Logout method. Do the following:
- Copy the
AMClient.properties file to the service provider's application container.
- Revise the
Logout method, as follows:
ResourceBundle rsbu =ResourceBundle.getBundle("AMClient");
String logouturl = rsbu.getString
("com.sun.identity.federation.client.samples.logoutURL");
response.sendRedirect(logouturl);
|
This revision is equivalent to a redirection to http://www.sp1.com:58080/amserver/liberty-logout?metaAlias=www.sp1.com.
References
Acknowledgment
We are indebted to Rajeev Angal, architect for Sun Java System Access Manager, for his valuable input.
About the Authors
The Sun Java System Access Manager Adoption Team at Market Development Engineering at Sun collaborates with independent software vendors in developing and integrating applications with Directory Server Enterprise Edition, Access Manager, and Sun Java System Portal Server.
Marina Sum is a staff writer for Sun Developer Network. She has been writing for Sun for 15 years, mostly in the technical arena.
| 
Print-friendly Version
