Chapter 5
Single Sign-On With DSAME
The iPlanet Directory Server Access Management Edition (DSAME) provides a single sign-on (SSO) solution that enables a user to authenticate once in order to access multiple applications and resources. In other words, successive attempts by a user to access protected resources will not require them to provide authentication credentials for each attempt. This chapter explains the solution, how it works and the SSO APIs. It contains the following sections:
The Single Sign-On Process
DSAME uses access control mechanisms to protect an organization's proprietary data and web resources. A user wanting to access these protected resources must first pass validating credentials through the Authentication service. A successful authentication gives the user authorization to access protected resources, based on their assigned policies or other such mechanism. If a user wants access to several resources protected by DSAME, the SSO (or Session) service provides proof of authentication to those resources so there is no need to re-authenticate. These different domains generally have common users who need to generate access to their services in a single user session.
Contacting A Web Agent
When a user, using a web browser, attempts to access a protected resource, the URL Policy Agent intercepts the request. Web agents police the web or application server on which the protected resource lives. Web agents enforce three types of policy: those URLs that can be accessed by the user, those URLs for which the user is denied access and those that are not subject to policy enforcement.
|
Note
|
URL Policy Agents are bundled for installation separately from the iPlanet DSAME. Additional information can be found in the iPlanet Policy Agent Pack documentation.
|
When the web agent intercepts the user's request, it checks to see if the requested URL is not subject to policy enforcement. If there is a match, the agent allows immediate access. If there is no match, the agent understands that the URL is subject to policy enforcement and inspects the request further to see if a user session identifier, or token, exists. If none exists, the request is passed to the DSAME server where it contacts both, the Session service to create a user token and the Authentication service to verify the user.
Creating A Session
Before a user's credentials can be authenticated, a token is generated using the Session service. Each token contains a randomly-generated DSAME session identifier and ultimately represents an authenticated user. Once created, the Authentication service inserts the token into a cookie and assigns it to the client browser. At the same time the token is assigned, a HTML login page is returned to the user based upon their organization's method of authentication (LDAP, RADIUS, Unix, etc.).
|
Note
|
The session token, at this point, is in an invalid state and will remain in one until the user has completed authentication.
|
Providing User Credentials
The user, having received the correct login page as well as a session token, fills in the appropriate user ID and password based on the login page returned. After the user enters their credentials, the data is sent to the authentication provider (LDAP server, RADIUS server, etc.) for verification. Once the provider has successfully verified the credentials, the user is authenticated. The user's specific session information is retrieved from the token and the session state is set to valid. The user can now be redirected to the URL they were attempting to access.
Cookies and Tokens
A cookie is an information packet generated by a web server and passed to a web browser. It maintains information about the user's habits with regards to the web server it is generated by. It does not imply that the user is authenticated. Cookies are domain-specific; for example, a cookie generated by thisdomain.com cannot be used in another domain such as thatdomain.com. In a DSAME implementation, the cookie is generated by DSAME's Session service and set by the Authentication service.
A token is generated by DSAME's Session service and inserted into a cookie. The token is generated using a secure random number generator and contains DSAME-specific session information. When a protected resource is accessed, the user is validated by the Authentication service and a SSOtoken is created.
Cross-Domain Support For SSO
DSAME supports cross-domain SSO. A user authenticated to DSAME in one domain can access resources protected by that same DSAME server in another domain. For example, the DSAME instance for DomainA is the authentication provider. A user authenticates to DSAME in DomainA and, after authentication, the token is set for DomainA. ServerB is protected by a web agent talking to a DSAME server in DomainB. The DSAME server in DomainB recognizes the DomainA server as the authentication provider.
If UserA accesses a resource on ServerB after authenticating to DSAME in DomainA, the web agent at DomainB checks to see if the request has a SSO token and finds that there is no DomainB token in the request. In a cross-domain SSO scenario, the agent will redirect the user to the URL of the cross-domain component running with the DSAME server in DomainB. This component redirects the request to the cross-domain component on DomainA since the DSAME at DomainA is the authentication provider. This request receives the SSO token set by DSAME in DomainA in the cookie header. The component at DomainA will send a response back to the component in DomainB with a SSO token. The DomainB component validates the SSO token from DomainA and creates the SSO token for the user in DomainB. This process sets a cookie for the user in DomainB. who is given access to the requested resource only if their policy grants authorization to access it.
If a user accesses a resource directly at DomainB without authenticating at DomainA, the user is redirected to authentication at DomainA. If the authentication is successful, the SSO token is sent to DomainB from DomainA. The ServerB validates the SSO token with DomainA, creates it for DomainB and redirects the user to the original requested resource.
Enabling Cross-Domain Single Sign-On
To enable cross-domain SSO, the administrator needs to configure two different SSO components. They are the Cross Domain Controller and the SSO Component. The Cross Domain Controller component comes bundled, and is installed, with DSAME. The SSO Component is a domain agent that needs to be installed separately onto all participating DNS domains.
|
Note
|
The system administrator can choose to not enable the cross-domain feature; in this case the SSO component would function within the context of a single domain.
|
Cross Domain Controller
The Cross Domain Controller (CDC) is associated with the DSAME server that is protecting a specific domain. It redirects a request to either the Authentication service or to the SSO Component. When a HTTP request comes into the CDC and no SSO token information is found, the request is redirected to the Authentication Service. If a SSO token is found for another domain, the request is redirected to the SSO Component with the appropriate session information appended to the query string.
|
Note
|
The CDC is installed when the command line tool aminstall is run to install the DSAME application. For more information, see the iPlanet Directory Server Access Management Edition Installation and Configuration Guide.
|
SSO Component
The SSO Component is deployed in each DSAME-protected domain. When a user attempts to access a resource, the URL is intercepted by the web agent as discussed in "Contacting A Web Agent". If no SSO token is found, the request is redirected to the SSO Component in the domain where the resource exists. The SSO Component searches the query string again for the SSO token. As no token is found, the request is redirected to the Cross Domain Controller associated with the DSAME server that protects this resource. From this point, the authentication process will be followed.
|
Note
|
If a SSO token is found by the web agent when the request is made, the SSO Component would not receive the request as the web agent would take the course of validating the token as described in Chapter 3 "User Authentication With DSAME."
|
Configuring For Cross-Domain SSO
The SSO components need to be enabled in order to allow the cross-domain SSO function to work. Assuming a single DSAME instance:
Run aminstall to install DSAME.
-
This will install the DSAME application as well as the CDC component and other internal services. The default CDC service URL, after installation, is http(s)://DSAME-HOST:PORT/amserver/cdcservlet.
Run aminstall again and choose to install the Cross-Domain Support option.
-
All participating DNS domains need to have an instance of the SSO component installed in their domain. After running this installation option, a cdsso directory is created in Install_Directory/SUNWam/web-apps. The default SSO Component service URL, after installation, is http(s)://DOMAIN-CDSSO-HOST:PORT/uri/cdssoservlet.
|
Note
|
Install the SSO Component on any web server with host services that need to be protected in all participating DNS domains.
|
Edit the com.iplanet.services.cdsso.cookiedomain property in the cdsso.properties file found in the Install_Directory/SUNWam/web-apps/cdsso/WEB-INF/classes directory.
-
Set the com.iplanet.services.cdsso.cookiedomain property to the domain name which hosts the SSO component. For example, com.iplanet.services.cdsso.cookiedomain =.sales.com, if the SSO component is hosted in a sun.com domain. Code Example 5-1 is copied from the file itself.
Code Example 5-1 Portion of cdsso.properties file
* The following keys will be used for Cross Domain SSO support.
|
* The user if needs cross doamin sso support should change
|
*"com.iplanet.services.cdsso.CDCURL" property to point to the
|
* cdcservlet running with the DSAME instance
|
* "com.iplanet.services.cdsso.cookiedomain" property should
|
* specify a comma separated list of domains for which the cdsso
|
* servlet will set a SSOToken.
|
* Ex:com.iplanet.services.cdsso.cookiedomain=.sales.com,
.eng.com,.marketing.com
|
*/
|
|
com.iplanet.services.cdsso.CDCURL=http://rays.india.sun.com:8080
/amserver/cdcservlet
|
com.iplanet.services.cdsso.cookiedomain=.sales.com
|
/*
|
...
|
|
Edit three properties in each web agent's AMagent.properties file.
Change the value of com.iplanet.am.policy.agents.url.authLoginUrl so it points to the component's domain's SSO service URL. For example, com.iplanet.am.policy.agents.url.authLoginUrl=http(s)://DOMAIN-CDSSO-HOST:PORT/uri/cdssoservlet. Code Example 5-2 illustrates where this property can be found.
Code Example 5-2 Second portion of CDSSO AMConfig.properties file
*changed to point to the cdsso servlet
*instead of the login servlet*/
|
/*com.iplanet.am.policy.agents.url.authLoginUrl=PROTO://HOST:POR
T/DEPLOY_URI/cdssoservlet*/
|
|
com.iplanet.am.policy.agents.url.authLoginUrl=SERVER_PROTO://SER
VER_HOST:SERVER_PORTSERVER_DEPLOY_URI/login
|
...
|
|
Add the SSO service URL to both the component's local and remote not enforced list. Code Example 5-3 displays the portion of the file where these properties are defined.
Code Example 5-3 Third portion of CDSSO AMConfig.properties file
*be edited to add cdsso servlet URL in it
|
*com.iplanet.am.policy.agents.url.notenforcedlist.local=
|
*PROTO://HOST:PORT/DEPLOY_URI/cdssoservlet */
|
com.iplanet.am.policy.agents.url.notenforcedlist.local=SERVER_PR
OTO://SERVER_HOST:SERVER_PORTSERVER_DEPLOY_URI/console*,
|
SERVER_PROTO://SERVER_HOST:SERVER_PORTSERVER_DEPLOY_URI/login*,
|
SERVER_PROTO://SERVER_HOST:SERVER_PORTSERVER_DEPLOY_URI/images/*
,
|
SERVER_PROTO://SERVER_HOST:SERVER_PORTSERVER_DEPLOY_URI/logout,
|
SERVER_PROTO://SERVER_HOST:SERVER_PORTSERVER_DEPLOY_URI/namingse
rvice,
|
SERVER_PROTO://SERVER_HOST:SERVER_PORTSERVER_DEPLOY_URI/sessions
ervice,
|
SERVER_PROTO://SERVER_HOST:SERVER_PORTSERVER_DEPLOY_URI/loggings
ervice,
|
SERVER_PROTO://SERVER_HOST:SERVER_PORTSERVER_DEPLOY_URI/profiles
ervice,
|
*AGENT_DEPLOY_URI/html/URLAccessDenied.html,
|
SERVER_PROTO://SERVER_HOST:SERVER_PORTSERVER_DEPLOY_URI/admin/*,
|
SERVER_PROTO://SERVER_HOST:SERVER_PORTSERVER_DEPLOY_URI/docs*,
|
SERVER_PROTO://SERVER_HOST:SERVER_PORTSERVER_DEPLOY_URI/index.ht
ml,
|
SERVER_PROTO://SERVER_HOST:SERVER_PORTCONSOLE_DEPLOY_URI/*,
|
SERVER_PROTO://SERVER_HOST:SERVER_PORTSERVER_DEPLOY_URI/GetHttpS
ession
|
...
|
/*If cross domain sso support is enabled notenfocelist should be
edited to add cdsso servlet URL in it
|
com.iplanet.am.policy.agents.url.notenforcedlist.remote=PROTO://
HOST:PORT/DEPLOY_URI/cdssoservlet*
|
*/
|
com.iplanet.am.policy.agents.url.notenforcedlist.remote=*AGENT_D
EPLOY_URI/html/URLAccessDenied.html
|
|
This instance of DSAME and all its participating DNS domains are now cross-domain SSO enabled.
|
Note
|
The cross-domain SSO solution assumes a single DSAME instance; therefore all user and policy information needs to be centralized in that instance. Multiple DSAME instances are allowed if they are all in the same domain.
|
SSO APIs
The SSO solution provides Java API to allow external applications to participate in the SSO functionality. All DSAME's services (except for Authentication) need a valid SSO token to process a HTTP request. External applications wishing to use the SSO functionality must use the SSO token to validate the user's identity. With the SSO API, an external application can get the token and, in turn, the identity of a user and related authentication information. Once a user is authenticated, this information is used to determine whether or not to provide access to the requested resource based on the validated user's policy. The SSO API can also be used to create or destroy a SSO token, to check the token's validity or to listen for token events. (An event might be a token timing out because the user has reached the token's maximum time limit.)
Non-Web-Based Applications
DSAME provides the SSO component primarily for web-based applications, although it can be extended to any non-web-based applications with limitations. With non-web-based applications, their are two possible ways to use the API.
The application has to obtain the DSAME cookie value and pass it into the SSO client methods to get to the SSO token. The method used for this process is application-specific.
Command line applications, such as amadmin, can be used. In this case, SSO tokens can be created to access the DS directly. There is no session created making the DSAME access is valid only within that process or VM.
API Overview
The primary purpose of the SSO API is to allow any service or application to make use of the SSO functionality. They are provided for the implementation of a SSO solution in external applications. Using these APIs, the identity of the user and related authentication information can be called. The application then uses this information to determine whether to provide user access to a protected resource. The SSO client applications get the information from the SSO token. For example, assume a user authenticates to http://www.DomainA.com/Store successfully and later tries to access http://www.DomainB.com/UpdateInfo. Rather than having the application authenticate the user again, it can use the API to determine if the user is already authenticated. If the methods indicate that the user is valid and has already been authenticated, access to this page can be given without the user authenticating again. Otherwise, the user is prompted to authenticate again.
Each time a user attempts to access a protected application, the application needs to verify their validity. Generally, the SSO component generates a SSO token for a user once the user is authenticated. After generation, the token is carried with the user as the user moves around the web. When the user attempts to access an application or service that is SSO-enabled, this token is used for user validation. Specifically, an instance of the SSOTokenManager class is created to allow access to the createSSOToken, destroyToken and isValidToken methods. An instance of the SSOToken class is then called; it contains the session information. Between the two, an application can determine if the user is authenticated. Another way to use the API is to invoke the SSOTokenListener interface which notifies the application when a token has become invalid in order for the application to terminate its access.
|
Note
|
For more information on the SSO APIs, the public Javadocs can be accessed through Install_Directory/SUNWam/docs/index.html.
|
SSOTokenManager Class
The SSOTokenManager class must be implemented to create one instance per token. It contains the three methods needed to create, get, validate and destroy SSO tokens. The createSSOToken() method is called to create a session token. It contains methods for doing this using the command line or through the internet. The destroyToken() method is called to delete a token when its session has ended. The isValidToken() and validateToken() methods are called in tandem to verify the authenticity of a token.
|
Note
|
SSOTokenManager is a final class and a singleton. SSOToken and SSOTokenID are Java interfaces. Additionally, SSOTokenListener and SSOTokenEvent are provided to support notification when SSO tokens are invalidated.
|
Sample SSOTokenManager Code
The SSOTokenManager class can be used in the following way to determine if a user is authenticated:
Code Example 5-4 Sample SSOTokenManager Code
/* create the sso token from http request */
|
SSOTokenManager manager = SSOTokenManager.getInstance();
|
|
/* The request here is the HttpServletRequest. */
|
SSOToken token = manager.createSSOToken(request);
|
|
/* use isValid to method to check if the token is valid or not
|
* this method returns true for valid token, false otherwise*/
|
if (token.isValid()) {
|
|
/* user is valid, this information may be enough for some
|
* applications to grant access to the requested resource.
|
* A valid user represents a user who is already authenticated,
|
* by some means.If access can be given based on this
|
* further check on user information is not necessary.
|
*/
|
|
/* let us get some user information */
|
String host = token.getHostName();
|
java.security.Principal principal = token.getPrincipal();
|
String authType = token.getAuthType();
|
int level = token.getAuthLevel();
|
|
..........
|
|
} else {
|
/* token is not valid, redirect the user login page */
|
}
|
...
|
|
SSO Implementations
The SSOTokenManager maintains a configuration database of valid implementations for SSOProvider, SSOToken and SSOTokenID. A request to SSOTokenManager gets delegated to the SSOProvider. Hence, the SSOProvider performs the bulk of the function of SSOTokenManager. The SSOToken is the SSO token that contains the crucial information about the token, and SSOTokenID is a string representation of SSO token. Although SSOTokenManager could support multiple and disparate providers, the only valid SSO provider is SSOProvider.
Additional Classes
The following classes can be used to implement customized SSO functionality in an application that does not use the default SSOProvider provided.
SSOToken
The SSOToken class represents a "single sign-on" token and contains information like the user validation, the authentication method, the host name of the client browser that sent the request, and session information (maximum session time, maximum session idle time, session idle time, etc.). Code Example 5-4 also makes use of the SSOToken interface.
SSOTokenEvent
The SSOTokenEvent class represents a token event. An event is, for instance, when a token becomes invalid due to idle time-out or hitting a time limit maximum. A token is granted when a change in the state of the token, like those mentioned, occurs. An application must come to know of events in order to terminate access to the application for a user whose token has become invalid. The SSOTokenListener class would need to be implemented by applications to receive SSO token events.
Sample SSOTokenEvent Code.
The SSOTokenEvent class can be used in the following way to get SSO Token events:
Code Example 5-5 Sample SSOTokenEvent Code
token.addSSOTokenListener(myListener);
|
|
where AppTokenListener is a class defined as follows:
|
|
public class AppTokenListener implements SSOTokenListener {
|
public void ssoTokenChanged(SSOTokenEvent event) {
|
try {
|
SSOToken token = event.getToken();
|
int type = event.getType();
|
long time = event.getTime();
|
|
SSOTokenID id = token.getTokenID();
|
System.out.println("Token id: " + id.toString() + "
is not valid anymore");
|
/* redirect user to login */
|
......
|
} catch (Exception e) {
|
System.out.println(e.getMessage());
|
}
|
}
|
}
|
|
SSOTokenID
The SSOTokenID class is used to identify the SSOToken object. Additionally, the SSOTokenID string contains a random number, the SSO server host, and server port. The random string in the SSOTokenID is unique on a given server. In the case of services written using a servlet container, the SSOTokenID can be communicated from one servlet to another either:
as a cookie in a HTTP header; or
as an implementation of the SSOTokenListener interface by the applications to receive the SSO token events.
SSOTokenListener
The SSOTokenListener interface provides a mechanism for applications that need notification when an SSO token expires. (It could expire if it reached its maximum session time, or idle time, or an administrator might have terminated the session.) Applications wishing to be notified must invoke the addSSOTokenListener method using the SSOToken interface; this method implements the SSOTokenListener interface. A callback object will be invoked when the SSO token expires. Using the SSOTokenEvent (provided through the callback), applications can determine the time, and the cause of the SSO token expiration.
|
Note
|
Once an application registers for SSO Token events using addSSOTokenListener, any SSO token event will invoke the ssoTokenChanged method. The application can take suitable action in this method.
|
Sample API Code
Following are examples of code that illustrate various operations that can be performed by the SSO API.
User Authentication Sample Code
This code can be used to determine if a user is authenticated. (Additionally, the API can be used to perform a query on a token for information such as host name, IP address, or idle time).
Code Example 5-6 Code Sample To Determine If User Is Authenticated
ServletOutputStream out = response.getOutputStream();
|
|
/* create the sso token from http request */
|
SSOTokenManager manager =
SSOTokenManager.getInstance();
|
SSOToken token = manager.createSSOToken(request);
|
|
/* use isValid method to check if the token is valid
|
* this method returns true for valid token, false non
|
*/
|
if (manager.isValidToken(token)) {
|
/* let us get all the values from the token */
|
|
String host = token.getHostName();
|
java.security.Principal principal =
token.getPrincipal();
|
String authType = token.getAuthType();
|
int level = token.getAuthLevel();
|
InetAddress ipAddress = token.getIPAddress();
|
long maxTime = token.getMaxSessionTime();
|
long idleTime = token.getIdleTime();
|
long maxIdleTime = token.getMaxIdleTime();
|
out.println("SSOToken host name: " + host);
|
out.println("SSOToken Principal name: " +
principal.getName());
|
out.println("Authentication type used: " +
authType);
|
out.println("IPAddress of the host: " +
|
ipAddress.getHostAddress());
|
}
|
/* try to validate the token again, with another method
|
* if token is invalid, this method throws exception
|
*/
|
manager.validateToken(token);
|
|
/* get the SSOTokenID associated with the token */
|
SSOTokenID tokenId = token.getTokenID();
|
|
String id = tokenId.toString();
|
|
/* print the string representation of the token */
|
|
out.println("The token id is " + id);
|
|
/* set properties in the token. We can get the values
|
* of set properties later
|
*/
|
token.setProperty("Company", "Sun Microsystems");
|
token.setProperty("Country", "USA");
|
String name = token.getProperty("Company");
|
String country = token.getProperty("Country");
|
|
out.println("Property: Company is - " + name);
|
out.println("Property: Country is - " + country);
|
|
out.println("SSO Token Validation test Succeeded");
|
/* add a listener to the SSOToken. Whenever a token
|
* event arrives, ssoTokenChanged method of the
|
* listener will get called.
|
*/
|
SSOTokenListener myListener = new
SampleTokenListener();
|
|
token.addSSOTokenListener(myListener);
|
out.flush();
|
} catch (Exception e) {
|
System.out.println("Exception Message: " +
e.getMessage());
|
e.printStackTrace();
|
}
|
}
|
}
|
|
In some cases, it might be more efficient and convenient to use SSOTokenManager.validateToken(token) than SSOTokenManager.isValidToken(token). SSOTokenManager.validToken(token) throws an exception when the token is invalid, thus terminating the method execution right away.
Get Token Sample Code
This sample code can be used to get the SSO token if the SSOtokenID string is passed to the application.
Code Example 5-7 Code Sample To Get Token from Token ID
/* create the sso token from SSO Token Id string */
|
SSOTokenManager manager=SSOTokenManager.getInstance();
|
SSOToken token = manager.CreateSSOToken(tokenString);
|
* let us get the SSOTokenID associated with the token
*/
|
SSOTokenID id = token.getTokenID();
|
|
String tokenId = id.toString();
|
|
/* print the string representation of the token */
|
|
System.out.println("The token ID is " + tokenId);
|
|
/* set properties in the token. We can get the values
|
* of set properties later */
|
|
token.setProperty("Company", "Sun Microsystems");
|
token.setProperty("Country", "USA");
|
String name = token.getProperty("Company");
|
String country = token.getProperty("Country");
|
|
System.out.println("Property: Company is - " + name);
|
System.out.println("Property: Country is - " +
country);
|
|
System.out.println("SSO Token Validation test
Succeeded");
|
/* add a listener to the SSOToken. Whenever a token
|
* event arrives, ssoTokenChanged method of the
|
* listener will get called.
|
*/
|
SSOTokenListener myListener = new
SampleTokenListener();
|
|
token.addSSOTokenListener(myListener);
|
} catch (Exception e) {
|
System.out.println(e.getMessage());
|
e.printStackTrace();
|
SSOTokenManager manager=SSOTokenManager.getInstance();
|
SSOToken token = manager.CreateSSOToken(tokenString);
|
}
|
}
|
|
Listen For Event Code Sample
Applications can listen for SSO token events. It is possible that while a user is using an application, an SSO token may become invalid because, for example:
The application must be informed of these events to follow-up on the invalid token by terminating the user's access. The following two sample codes can be used to get token events.
Code Example 5-8 Code Sample To Register For SSOToken Events
token.addSSOTokenListener(myListener);
|
|
where SampleTokenListener is a class defined as:
Code Example 5-9 Code Sample Defining SampleTokenListener Class
|
public void ssoTokenChanged(SSOTokenEvent event) {
|
try {
|
SSOToken token = event.getToken();
|
int type = event.getType();
|
long time = event.getTime();
|
|
SSOTokenID id = token.getTokenID();
|
|
System.out.println("Token id is: " + id.toString());
|
|
if (SSOTokenManager.getInstance().isValidToken(token))
{
|
System.out.println("Token is Valid");
|
} else {
|
System.out.println("Token is Invalid");
|
}
|
|
switch(type) {
|
case SSOTokenEvent.SSO_TOKEN_IDLE_TIMEOUT:
|
System.out.println("Token Idel Timeout event");
|
break;
|
case SSOTokenEvent.SSO_TOKEN_MAX_TIMEOUT:
|
System.out.println("Token Max Timeout event");
|
break;
|
case SSOTokenEvent.SSO_TOKEN_DESTROY:
|
System.out.println("Token Destroyed event");
|
break;
|
default:
|
System.out.println("Unknown Token event");
|
}
|
} catch (Exception e) {
|
System.out.println(e.getMessage());
|
}
|
}
|
}
|
|
After the application registers for SSO token events using addSSOTokenListener, any SSO token events will invoke the ssoTokenChanged() method. The application can take a suitable action in this method.
Sample SSO Java Files
DSAME installs three groupings of sample Java files with instructional text. With these files, a developer can create an SSO token in several ways:
An SSO token can be created for an application that runs on the DSAME server.
An SSO token can be created for an application that runs on a server other than the DSAME server.
An SSO token can be created by a session ID string can be passed through the command line.
The files needed to perform these actions can be found in the Install_Directory/SUNWam/samples/sso directory.
SSO Servlet Sample
This sample can be used to create a token for an application that resides on the same server as the DSAME application. The files used for this sample are:
The instructions in Readme.html can be followed to run this code.
Remote SSO Sample
This sample can be used to create a token for an application that resides on a different server from the one on which the DSAME application lives. The files used for this sample are:
remote.html
SSOTokenFromRemoteServlet.java
SSOTokenSampleServlet.java
The instructions in remote.html can be followed to run this code.
Command Line SSO Sample
This sample illustrates how to validate a user from the command line using a session ID string. The files used for this sample are:
ssocli.txt
CommandLineSSO.java
SSOTokenSample.java
The instructions in ssocli.txt can be followed to run this code.
Multi-JVM Support
DSAME can run on iPlanet Application Server (AS) which supports a multi-JVM environment. In this scenario, based on load balancing, a SSO service could run in any JVM. If one JVM receives the createSSOToken() request, subsequent validation requests must be directed to the same JVM otherwise, the SSO service will send an invalid token response. For this purpose, DSAME uses the sticky session feature of the AS; it is turned on automatically when the DSAME is installed. For more information, see the documentation that comes with iPlanet Application Server.
|
Note
|
The SSO APIs cannot be used in a multi-JVM environment.
|