Sun OpenSSO Enterprise 8.0 Deployment Planning Guide

Previous: Chapter 15 Using the Embedded Configuration Data Store for OpenSSO Enterprise
Next: Chapter 17 Configuring System Failover and Session Failover for High Availability

Chapter 16 Implementing Cross-Domain Single Sign-On with Cookie Hijacking Prevention

This chapter provides high-level instructions for deploying OpenSSO Enterprise in a cross-domain single sign-on (CDSSO) environment and configuring the OpenSSO Enterprise server and policy agents to prevent cookie highjacking. Topics include:

About Cross-Domain Single Sign-On

CDSSO extends single sign-on beyond a single domain. Basic single sign-on uses HTTP cookies within a single DNS domain. In basic single sign-on, the OpenSSO Enterprise server and all policy agent-protected resources reside in the same DNS domain. When a user successfully authenticates to an OpenSSO Enterprise server, an SSO token, represented by an HTTP cookie, is set to the user's browser with the OpenSSO Enterprise DNS domain as the cookie domain. From this point until the session terminates or expires, the browser always presents the SSO token to any server or policy agent in the same DNS domain based on the HTTP protocol. This allows OpenSSO Enterprise and the policy agents to reexamine the validity of the user session and identity, and then enforce security policies without re-authentication. But basic single sign-on cannot be used in environments where OpenSSO Enterprise and its policy agents reside in different DNS domains.

For example, OpenSSO Enterprise and some policy agents may reside in www.domain1.com while some other policy agents reside in www.domain2.com. During authentication to OpenSSO Enterprise, the SSO token is set to the browser with domain1.com as the cookie domain. However, when the browser accesses the resources protected by policy agents in domain2.com, the browser does not present the SSO token to the policy agents. For the policy agents, no SSO token means the user is not authenticated. The policy agents force the user to authenticate. The OpenSSO Enterprise in the appropriate DNS domain sees that the browser does have a valid session SSO token. OpenSSO Enterprise redirects the browser back to the original requested resource in www.domain2.com creating a redirection loop.

To overcome this problem, you can configure the CDSSO feature in the OpenSSO Enterprise server in its policy agents. CDSSO is a mechanism for passing SSO tokens to policy agents protecting resources present in different DNS domains. CDSSO makes it possible for users to authenticate once against OpenSSO Enterprise server in a primary DNS domain, and then access resources protected by the policy agents present in other DNS domains without having to re-authenticate. CDSSO is an OpenSSO Enterprise proprietary mechanism to support single sign-on across multiple domains. Alternatively, you can use standards-based Federation protocols to achieve single sign-on across multiple domains.

Figure 16–1 Single Sign-On Failure When Policy Agents Reside in Different DNS Domains

OpenSSO Enterprise policy agent denies access
because the SSO token is unique to the application in DNS Domain 1.

The Policy Agent's Role in CDSSO

The Java EE Policy Agent's Role

Based upon the appropriate HTTP protocols, an SSO token is presented to servers in the DNS domain that is set in the cookie. A server may only set a cookie within their own domain. So despite having a valid SSO token cookie in one domain, policy agent-protected servers in other domains are never presented with this cookie.

CDSSO overcomes the problem with coordinated work between two components:

Cross-Domain Controller (CDC) servlet on the OpenSSO Enterprise server: http(s)://opensso_host:port/opensso/cdcserlvet
CDSSO Redirect Servlet on the Java EE policy agent

http(s)://agent_host:port/agentapp/sunwCDSSORedirectURI

The CDSSO Redirect Servlet extracts the SSO Token sent by the CDC Servlet, and then sets the same SSO Token cookie again. This time the SSO Token is set with the policy agent's fully qualified host name as the cookie domain. This process essentially replicates the SSO Token in the policy agent DNS domain from the OpenSSO Enterprise DNS domain. The following figure illustrates the CDC servlet and CDSSO Redirect Servlet process flows.

Figure 16–2 Process flow for CDC Servlet and CDSSO Redirect Servlet

Text-based diagram. No further explanation needed.

Figure 16–3 Process flow for CDC Servlet and CDSSO Redirect Servlet (continued)

The Web Policy Agent's Role in CDSSO

The Web Policy Agent works similarly as the Java EE Policy Agent except for a slight variance. No CDSSO Redirect Servlet exists on the web policy agent because the agent is an NSAPI plug-in. As a result, the web policy agent combines the above steps 11 through 13 into a single step with no redirection.

About Cookie Hijacking Prevention

A common concern for administrators who want to restrict access to web-based applications in an OpenSSO Enterprise deployment is that hackers might use rogue or untrusted applications to steal, or hijack, session cookies. The way OpenSSO Enterprise is configured influences the way it sets the session cookies. By default OpenSSO Enterprise sets session cookies for the entire domain. All applications hosted on the domain share the same session cookies. This scenario could enable an untrusted application to intervene and gain access to the session cookies, which in turn poses a security threat. To guard against potential threats posed by cookie hijacking, configure CDSSO with cookie hijacking prevention. As a best practice, configure CDSSO with cookie hijacking prevention even in the deployments where all OpenSSO Enterprise components are in same domain. Having CDSSO and cookie hijacking prevention enabled when the deployment involves a single domain may seem unnecessary. But ultimately security is increased by taking advantage of both features.

Key Cookie Hijacking Security Issues and Solutions

The term “cookie hijacking” refers to a situation where an impostor gains unauthorized access to cookies. The imposter could be a hacker using an untrusted application. Cookie hijacking, by itself, does not refer to unauthorized access to protected web resources. When the cookies being hijacked are session cookies, then cookie hijacking potentially increases the threat of unauthorized access to protected web resources, depending upon how the system is configured.

Shared Session Cookies Security Issue

All applications share the same HTTP or HTTPS session cookie. This shared session-cookie scenario enables hackers to intervene by using an untrusted application to hijack the session cookie. With the hijacked session cookie, the untrusted application can impersonate the user and access protected web resources.

OpenSSO Enterprise Solution

Unique SSO token is issued to each application or policy agent after the user has been authenticated. The unique SSO token is referred to as a "restricted token." The restricted token is inextricably connected to the application and to the policy agent. Since each user's SSO token is unique for each application or policy agent, the increased security provided by this scenario prevents an untrusted application, impersonating the user, from accessing other applications. More specifically, the restricted SSO token assigned to a user as a part of the user's session is associated with the policy agent that initiated the original redirection for authentication. So all subsequent requests are checked to verify that they are coming from the same policy agent. If a hacker tries to use the same restricted token to access another application, a security violation is thrown.

What makes the restricted token “restricted” is not related to the syntax of the token. The syntax of a restricted token is the same as that of a regular SSO token. Instead, a specific constraint (IP or DN) is associated with the restricted token. OpenSSO Enterprise server checks the validity of the IP or DN before performing any operation using this restricted token. From OpenSSO Enterprise 8.0 Update 1 onwards, you can configure the DN only restriction. The DN only restriction is suitable if the agents are behind the firewall. This constraint is what ensures that the restricted token is only used for an application that a given policy agent protects.

Access to User Profile Attributes Security Issue

The untrusted application can use the session cookie to obtain and possibly modify the profile attributes of the user. If the user has administrative privileges, the application could do much more damage.

OpenSSO Enterprise Solution

By issuing a restricted SSO token, the set of Session Service operations that can be performed are limited using these tokens. This functionality enables OpenSSO Enterprise to prevent applications from modifying profile attributes of the user. The following figure illustrates a typical OpenSSO Enterprise deployment within an enterprise. While the figure illustrates security issues related to cookie hijacking, the figure also illustrates the solution.

Figure 16–4 Process Flow for Cookie Hijacking Prevention

Text-based diagram. Needs no further explanation.

OpenSSO Enterprise Session Cookies Involved in Issuing Unique SSO Tokens

When OpenSSO Enterprise is configured to issue unique SSO tokens for each application or policy agent, the following cookies are involved:

Table 16–1 Session Cookies in Unique SSO Tokens


Cookie Name	Place Holder Cookie Value	Domain
`iPlanetDirectoryPro`	`SSO-token` The actual cookie value is the value of the token.	The domain is set to the host name of the OpenSSO Enterprise instance where the user was authenticated. Example: `OpenssoHost.example.com`
`iPlanetDirectoryPro`	`restricted-SSO-token` The actual cookie value is the value of the token.	The domain is set to the host name of the policy agent instance for which the restricted token is issued. Example: `agentHost.example.com`
`sunIdentityServerAuthNServer`	`https://OpenssoHost.examplecom:8080` The cookie value is the URL of the OpenSSO Enterprise instance where the user was authenticated. In this example, the protocol is HTTPS.	The domain must be set to cover all instances of OpenSSO Enterprise installed on the network. Example: `.example.com`

Analyzing the Deployment Architecture

The following figure illustrates a typical CDSSO deployment architecture.

Figure 16–5 Deployment Architecture

Process flows from Domain 1 load balancer to
Domain 2 policy agents.

Considering Assumptions, Dependencies, and Constraints

Assumptions and Dependencies

All the components in the deployment have the same GMT time stamp.
CDSSO must be enabled before configuring Cookie Hijacking Prevention.
The Cookie Hijacking Prevention configuration doesn't prevent cookies being viewed or hijacked by hackers using network snooping applications. The only way to prevent this is by using a secure communication protocol such as SSL.
All the agents in the deployment have a unique agent profile in the OpenSSO Enterprise server.

Constraints

CDSSO and Cookie Hijacking Prevention can be used only if OpenSSO Enterprise and policy agents are involved.
Policy agents must be configured to use the same OpenSSO Enterprise infrastructure where multiple OpenSSO Enterprise instances can exist.
Multiple OpenSSO Enterprise instances configured for high-availability must all reside in a single DNS domain. Only policy agents can reside in different DNS domains.

Understanding Typical Business Use Cases

This section describes actual protocol exchanges in four business use cases:

All use cases are based on the same configuration:

The primary domain, DNS Domain 1, is where OpenSSO Enterprise resides. The non-primary domain is DNS Domain 2.
In the primary domain, two OpenSSO Enterprise instances exist. Both are behind a load balancer.
In the primary domain, Policy Agent 1 resides in host1.Domain1.com:7001 with CDSSO disabled.
In the non-primary domain, Policy Agent 2 resides in host2.Domain2.com:80 with CDSSO enabled.
A protected resource /app1/test1.html is deployed in host1.Domain1.com:7001.
A protected resource /app2/test2.html is deployed in host2.Domain2.com:80.

The following figure illustrates the configuration used for all four business use cases.

Figure 16–6 Configuration for Business Use Cases

Process flows from Browser to Policy Agent 1
in Domain 1 and to Policy Agent 2 in Domain 2.

Java EE Policy Agent Use Case 1: Accessing a Protected Resource in the Primary Domain First

In this use case, an unauthenticated user first accesses a resource under Policy Agent 1 in the DNS Domain 1, the primary domain. After the authentication, the OpenSSO Enterprise sets an SSO token in Domain 1. Then the user accesses another resource under Policy Agent 2 in DNS Domain 2, a non-primary domain. The CDSSO sequence is invoked and access is allowed without re-authentication.

An unauthenticated user attempts to access http://Host1.Domain1.com:7001/app1/test1.html, a resource in Domain 1.

The Java EE policy agent intercepts the request and redirects to the OpenSSO Enterprise server login page.
The browser follows the redirection to access the OpenSSO Enterprise login page.
The user provides the credentials and clicks Submit.

A login form is posted to OpenSSO Enterprise server.
- If the user is not authenticated successfully, the server responds by displaying an “Access Denied” message.
- If the user authenticates successfully, the server responds by setting an SSO token (represented by the iPlanetDirectoryPro cookie) in Domain 1. The response includes a redirect to the original requested resource.
The browser follows the redirection to access http://Host1.Domain1.com:7001/app1/test1.html.
1. The SSO token is sent in the HTTP request to the server.
2. The policy agent validates the SSO token and evaluates policies by interacting with the OpenSSO Enterprise server in the background. If access is denied, the policy agent displays an “Access Denied” message. If access is allowed, the policy agent allows the web container to serve the requested protected resource.
The user tries to access another resource http://Host2.Domain2.com:80/app2/test2.html in Domain 2.
1. The SSO token is not sent in the HTTP request because the server Host2.Domain2.com does not match the cookie domain Domain1.com.
2. The policy agent, receiving no SSO token, responds by redirecting the browser to the CDC servlet URL https://serverHost.Domain1.com:8443/opensso/cdcservlet.
3. The policy agent sets a cookie amFilterCDSSORequest to save the following:
  - The user-requested URL
  - Cookie access type, such as GET or POST
  - The value of the RequestID query parameter (AuthnRequestID)
  This cookie is set before redirecting to the OpenSSO Enterprise CDC servlet.
Later, after getting the AuthnResponse from the CDC Servlet, the policy agent retrieves the information from the amFilterCDSSORequest cookie to continue with the user's originally requested URL. The redirection URL contains some parameters to be carried to the CDC servlet. Some of these parameters are:

goto

The URL to which CDC servlet will forward AuthNResponse.

MajorVersion

The Liberty Federation Protocol major version. Set to 1 by default.

MinorVersion

The Liberty Federation Protocol minor version. Set to 1 by default.

RequestID

An AuthnRequestID.

This is a uniquely generated ID. It uses the form:

s<20-digit hexadecimal string>.

The AuthnRequestID is sent to the CDC Servlet so that the its AuthnResponse later can contain this unique identifier. The RequestID is used to tie the response coming back. The RequestID is verified when the response comes back from the CDC servlet

ProviderID

Identifies the provider, which is the policy agent. The value will be of the form: http://agent-host:port/?Realm=<RealmName> where RealmName is what is configured for the property com.sun.identity.agents.config.organization.name in the policy agent profile.

IssueInstant

The time at which the AuthnRequest was created (being sent) in UTC format.
The browser follows the redirection to access the CDC servlet.
1. The SSO token is sent in the HTTP request because the server DNS domain matches the cookie domain.
2. The CDC servlet validates the SSO token and responds with an HTML page.
  
  The page contains an HTML FORM which will be automatically posted to CDSSO Redirect URL on the policy agent. Example: http://Host2.Domain2.com:80/agentapp/sunwCDSSORedirectURI, based on the goto parameter earlier. The form's hidden field LARES is an encoded Liberty-like AuthnResponse that contains the existing SSO Token in Domain1.com.
The browser automatically posts the form with LARES to http://Host2.Domain2.com:80/agentapp/sunwCDSSORedirectURI without user interaction.
1. The policy agent responds by setting a new SSO token with the cookie domain value set as the policy agent's fully qualified host name. Also note the cookie value is exactly the same as the one set in Step 3 response by OpenSSO Enterprise server.
2. The HTTP response also redirects the browser to the original requested resource http://Host2.Domain2.com:80/app2/test2.html.
3. In responding to this request, the policy agent goes through the following steps to validate the received AuthnResponse:
  1. First the requestID, saved in the amFilterCDSSORequest cookie, is verified against the responseID of the AuthnResponse.
  2. The status code of the AuthnResponse is verified to see if it is successful.
  3. The assertion is extracted from the AuthnResponse. There should be only one AuthnResponse.
  4. From the Assertion, the issuer is extracted and is verified against the policy agent list of trusted ID providers.
    
    If the issuer is not in the policy agent trusted list, then user request is blocked. These trusted ID providers are governed by the property com.sun.identity.agents.config.cdsso.trusted.id.provider[x]. See Configuring CDSSO and Cookie Hijacking Prevention. These IDs should contain URLs of the actual OpenSSO Enterprise instances, and should not contain the URL of the load balancer.
  5. The conditions that are in the assertion are also validated.
    
    The main condition is the date validity condition. The date validity attributes (NotBefore and NotOnOrAfter) are verified to be sure the assertion has not expired. So time synchronization between the OpenSSO Enterprise server and the policy agent is essential. The skew factor provided in the policy agent profile com.sun.identity.agents.config.cdsso.clock.skew also helps to overcome any network latencies.
  6. In the response, cookie amFilterCDSSORequest is removed by setting the expiration date in the past.
The browser follows the redirection to access the protected resource again at http://Host2.Domain2.com:80/app2/test.html.
1. The new SSO token is sent to the policy agent.
2. The policy agent validates the SSO token and evaluates the policies.
3. The policy agent, upon successful validation, responds with the content of the protected resource.

Java EE Policy Agent Use Case 2: Accessing a Protected Resource in a Non-Primary Domain First

In this use case, an unauthenticated user first accesses a protected resource in the DNS Domain 2, the non-primary domain. The user then accesses a protected resource in the primary domain, DNS Domain1.

An unauthenticated user attempts to access a resource in Domain 2. Example: http://Host2.Domain2.com:80/app2/test2.html.
The policy agent intercepts the request and receives no SSO Token.

Because CDSSO is enabled, the policy agent responds with a redirection to the OpenSSO Enterprise CDC servlet URL https://serverHost1.Domain1.com:8443/opensso/cdcservlet.
The browser follows the redirection to access the CDC servlet without any SSO token. The CDC servlet responds with a login page.
The user types his credentials on the login page and clicks Submit.

A login form is posted to the OpenSSO Enterprise server.
1. If the user authenticates successfully, the OpenSSO Enterprise responds by setting an SSO token in Domain1.com.
2. The response also redirects the browser back to the CDC servlet https://serverHost1.Domain1.com:8443/opensso/cdcservlet.
The browser follows the redirection to access the CDC servlet again.

This time the SSO token is sent in the HTTP request because the OpenSSO Enterprise server DNS domain matches the cookie domain.
The CDC servlet validates the SSO Token and responds with an HTML page.

The page contains an HTML form which is automatically posted to CDSSO Redirect URL on the policy agent http://Host2.Domain2.com:80/agentapp/sunwCDSSORedirectURI. The form's hidden field LARES is an encoded Liberty-like AuthnResponse that contains the existing SSO Token in Domain1.
The browser automatically posts the form with LARES to http://Host2.Domain2.com:80/agentapp/sunwCDSSORedirectURI with no user interaction.
The policy agent responds by setting a second SSO Token. The second SSO token domain is the policy agent's fully-qualified host name. The cookie value is identical to the cookie value set by the OpenSSO Enterprise server in step 4. The HTTP response also redirects the browser to the original requested resource http://Host2.Domain2.com:80/app2/test2.html.
The browser follows the redirection to access the protected resource again at http://Host2.Domain2.com:80/app2/test2.html.
1. The second SSO Token is sent to the policy agent.
2. The policy agent validates the SSO token, and evaluates the policies.
3. The policy agent, upon successful validation, responds with the content of the protected resource.
The user now attempts to access a resource in the primary domain, Domain 1. Example: http://Host1.Domain1.com:7001/app1/test1.html.

An SSO Token is sent with the HTTP request. The browser now has two SSO Tokens, one for each domain. The sent token was obtained in Step 4.
The policy agent intercepts the request and receives the SSO Token.

The policy agent validates the token and permits the server to serve the content of the protected page.

Web Policy Agent Use Case 1: Accessing a Protected Resource in the Primary Domain First

An unauthenticated user attempts to access a resource in Domain 1. Example: http://Host1.Domain1.com:7001/app1/test1.html.
The Web policy agent intercepts the request and receives no SSO Token. The policy agent responds with a redirection to the OpenSSO Enterprise login page.
The browser follows the redirection to access the OpenSSO Enterprise login page.
The user provides the credentials and clicks Submit.

A login form posted to the OpenSSO Enterprise server.
- If the user is not authenticated successfully, the server responds by displaying an “Access Denied” message.
- If the user authenticates successfully, the server responds by setting an SSO token (represented by the iPlanetDirectoryPro cookie) in Domain 1. The response also includes a redirect to the original requested resource http://Host1.Domain1.com:7001/app1/test1.html.
The browser follows the redirection to access http://Host1.Domain1.com:7001/app1/test1.html.
1. The SSO token is sent in the HTTP request to the server.
2. The policy agent validates the SSO token and evaluates policies by interacting with the OpenSSO Enterprise server in the background. If access is denied, the policy agent displays an “Access Denied” message. If access is allowed, the server responds with the content of the protected resource.
The user tries to access another resource in the non-primary domain, Domain 2. Example: http://Host2.Domain2.com:80/app2/test2.html.
1. The SSO token is not sent in the HTTP request because the policy agent domain Domain2.com does not match the cookie domain Domain1.com.
2. The policy agent, receiving no SSO token, responds by redirecting the browser to the CDC servlet URL https://serverHost.Domain1.com:8443/opensso/cdcservlet.
The redirection URL contains some parameters to be carried to the CDC servlet. Some of these parameters are:

goto

The URL to which CDC servlet will forward AuthNResponse.

This is the originally requested URL with the parameter sunwmethod=GET appended to it.

MajorVersion

The Liberty Federation Protocol major version. Set to 1 by default.

MinorVersion

The Liberty Federation Protocol minor version. Set to 1 by default.

RequestID

An AuthnRequestID.

This is a uniquely generated ID. It uses the following form:

s<20-digit hexadecimal string>.

The AuthnRequestID is sent to the CDC Servlet so that its AuthnResponse later can contain this unique identifier. The RequestID is used to tie the response coming back. The RequestID is verified when the response comes back from the CDC servlet.

ProviderID

Identifies the provider, which is the policy agent. The value will be of the form: http(s)://agent-host:port/amagent?Realm=<RealmName> where RealmName is what is configured for the property com.sun.identity.agents.config.organization.name in the policy agent profile.

IssueInstant

The time at which the AuthnRequest was created in UTC format.
The browser follows the redirection to access the CDC servlet.
1. The SSO token is sent in the HTTP request because the OpenSSO Enterprise server domain matches the cookie domain.
2. The CDC servlet validates the SSO token and responds with an HTML page.
  
  The page contains an HTML FORM which will be automatically posted to the policy agent with no user interaction. Example: http://Host2.Domain2.com:80/app2/test2.html?sunwmethod=GET based on the goto parameter.
The browser automatically posts the form with LARES to http://Host2.Domain2.com:80/app2/test2.html?sunwmethod=Get with no user interaction.
1. The policy agent responds by setting a second SSO Token. The second SSO token domain is the policy agent's fully-qualified host name. The cookie value is identical to the cookie value set by the OpenSSO Enterprise server in step 4.
2. The assertions are extracted from the AuthnResponse. There should only be one AuthnResponse.
3. The policy agent also performs necessary session validation and policy evaluation. If the session is validated, and the policy evaluation succeeds, then the user is allowed access and the protected page is served in response.

Web Policy Agent Use Case 2: Accessing a Protected Resource in the Non-Primary Domain First

An unauthenticated user attempts to access a resource in the non-primary domain, Domain 2. Example: http://Host2.Domain2.com:80/app2/test2.html.
The policy agent intercepts the request and receives no SSO Token.

Because CDSSO is enabled, the policy agent responds with a redirection to the OpenSSO Enterprise CDC servlet URL https://serverHost1.Domain1.com:8443/opensso/cdcservlet.
The browser follows the redirection to access the CDC servlet without any SSO token. The CDC servlet responds with a login page.
The user types his credentials on the login page and clicks Submit.

A login form is posted to the OpenSSO Enterprise server.
1. If the user authenticates successfully, the OpenSSO Enterprise server responds by setting an SSO token in Domain1.com.
2. The response also redirects the browser back to the CDC servlet https://serverHost1.Domain1.com:8443/opensso/cdcservlet.
The browser follows the redirection to access the CDC servlet again.

This time the SSO token is sent in the HTTP request because the server DNS domain matches the cookie domain.
The CDC servlet validates the SSO Token and responds with an HTML page.

The page contains a HTML form which is automatically posted to the policy agent http://Host2.Domain2.com:80/app2/test2.html?sunwMethod=GET.

This is derived from the goto and target parameters. The form's hidden field LARES is an encoded Liberty-like AuthnResponse that contains the existing SSO Token in Domain1.
The browser automatically posts the form with LARES to http://Host2.Domain2.com:80/app2/test2.html?sunwMethod=GET with no user interaction.
The policy agent validates the AuthNResponse, and responds by setting a second SSO Token. The second SSO token domain is the policy agent's fully-qualified host name. The cookie value is identical to the cookie value set by the OpenSSO Enterprise server in step 4.
The policy agent performs necessary session validation and policy evaluation. If the session is validated, and the policy evaluation succeeds, then the user is allowed access and the protected page is served in response.
The user now attempts to access a resource in the primary domain, Domain 1. Example: http://Host1.Domain1.com:7001/app1/test1.html.

An SSO Token is sent with the HTTP request. The browser now has two SSO Tokens, one for each domain. The sent token was obtained in Step 4.
The policy agent intercepts the request and receives the SSO Token.

The policy agent validates the token and permits the server to serve the content of the protected page.

Configuring CDSSO and Cookie Hijacking Prevention

The configuration instructions in this section use the following mapping based on Figure 16–5:

Table 16–2 Mapping Fig 16–5 to Server Names


Figure Label	Server Name Example
Load Balancer 1	`lb1_server.hostname`
Load Balancer 2	`lb2_server.hostname`
OpenSSO Enterprise Server 1	`server1.hostname`
OpenSSO Enterprise Server 2	`server2.hostname`

To Enable CDSSO and Cookie Hijacking Prevention in Java EE Policy Agent

Enable CDSSO for the Centralized Mode policy agent profile.
1. Log in to the OpenSSO Enterprise server as an administrator.
2. In the OpenSSO Enterprise administration console, go to Realm > Agents > J2EE Agents > Agent_Name > SSO.
3. Enable the property Cross Domain SSO
4. Set the value for the CDSSO Redirect URI.
  
  Example: /agentapp/sunwCDSSORedirectURI
5. Set the value for the CDSSO Servlet URL.
  
  Example:
  lb2_server_protocol://lb2_server.hostname:lb2_server.port/server-deployment-uri/cdcservlet
6. Set the CDSSO Clock Skew to 0.
7. Add the CDSSO Trusted ID Provider.
  
  Example:
  server1_protocol://server1.hostname:server1.port/server1-deployment-uri/cdcservlet server2_protocol://server2.hostname:server2.port/server2-deployment-uri/cdcservlet

Enable CDSSO for the Local Mode policy agent profile:

Edit OpenSSOAgentConfiguration.properties and set CDSSO related parameters. Example:

com.sun.identity.agents.config.cdsso.enable = true 
com.sun.identity.agents.config.cdsso.redirect.uri=/agentapp/sunwCDSSORedirectURI 
com.sun.identity.agents.config.cdsso.cdcservlet.url[0] = 
  <lb2_server_protocol>://<lb2_server.hostname>:
  <lb2_server.port>/<server-deployment-uri>/cdcservlet 
com.sun.identity.agents.config.cdsso.clock.skew = 0 
com.sun.identity.agents.config.cdsso.trusted.id.provider[0]= 
  <server1_protocol>://<srver1.hostname>:
  <server1.port>/<server1-deployment-uri>/cdcservlet 
com.sun.identity.agents.config.cdsso.trusted.id.provider[1] = 
  <server2_protocol>://<server2.hostname>:
  <server2.port>/<server2-deployment-uri>/cdcservlet

Enable Cookie Hijacking Prevention in the OpenSSO Enterprise server.

In the OpenSSO Enterprise administration console, go to Configuration >Sites and Server >Default server settings > Advanced and set the following properties:

com.sun.identity.enableUniqueSSOTokenCookie=true 
com.sun.identity.authentication.uniqueCookieName=sunIdentityServerAuthNServer 
com.sun.identity.authentication.uniqueCookieDomain=server domain

Go to Configuration > System > Platform .

Remove server domain and add the OpenSSO Enterprise server host name.

Caution –
If OpenSSO Enterprise is deployed behind a load balancer, then in step 3c, do not use the OpenSSO server host name. Instead, be sure to use the load balancer host name.

Enable a unique SSO token cookie in the agent profile.

Do one of the following:
- For the Centralized Mode policy agent, go to RootRealm > Agents> J2EE Agents > AgentName > Advanced > Custom Properties, and add the following property: com.sun.identity.enableUniqueSSOTokenCookie=true.
- For the Local Mode policy agent, in the OpenSSOAgentConfiguration.properties file, add the following property: com.sun.identity.enableUniqueSSOTokenCookie=true.

To Enable CDSSO and Cookie Hijacking Prevention in the Web Policy Agent

Enable CDSSO for the Centralized Mode policy agent profile.
1. Log in to the OpenSSO Enterprise server as an administrator.
2. In the OpenSSO Enterprise administration console, go to Realm > Agents > Web Agents > Agent_Name > SSO.
3. Enable the property Cross Domain SSO.
4. Set the value for the CDSSO Servlet URL.
  
  Example:
  lb2_server_protocol://lb2_server.hostname:lb2_server.port/server-deployment-uri/cdservlet

Enable CDSSO for the Local Mode policy agent profile:

Edit OpenSSOAgentConfiguration.properties and set CDSSO related parameters. Example:

com.sun.identity.agents.config.cdsso.enable = true
com.sun.identity.agents.config.cdsso.cdcservlet.url[0] = 
  lb2_server_protocol://lb2_server.hostname:
  lb2_server.port/server-deployment-uri/cdcservlet

Enable Cookie Hijacking Prevention in the OpenSSO Enterprise server.

In the OpenSSO Enterprise administration console, go to Configuration >Sites and Server >Default server settings > Advanced and set the following properties:

com.sun.identity.enableUniqueSSOTokenCookie=true 
com.sun.identity.authentication.uniqueCookieName=sunIdentityServerAuthNServer 
com.sun.identity.authentication.uniqueCookieDomain= server domain

Go to Configuration > System > Platform .

Remove server domain and add the server host name.

Caution –
If OpenSSO Enterprise is deployed behind a load balancer, then in step 3c, do not use the OpenSSO server host name. Instead, be sure to use the load balancer host name.

Evaluating Benefits and Trade-offs

The benefit of using CDSSO with Cookie Hijacking Prevention is that resources are protected among multiple domains. Security is significantly increased. The trade-off is that the CDSSO solution is proprietary to OpenSSO Enterprise. Integrating the CDSSO solution with other single sign-on products is not possible.