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

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:

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

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

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

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:

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

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 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.

The SSO token is sent in the HTTP request to the server.

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.

The SSO token is not sent in the HTTP request because
the server Host2.Domain2.com does not match the
cookie domain Domain1.com.

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 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.

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 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.

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.

The HTTP response also redirects the browser to the
original requested resource http://Host2.Domain2.com:80/app2/test2.html.

In responding to this request, the policy agent goes
through the following steps to validate the received AuthnResponse:

First the requestID, saved in the amFilterCDSSORequest cookie, is verified against the responseID of the AuthnResponse.

The status code of the AuthnResponse is
verified to see if it is successful.

The assertion is extracted from the AuthnResponse. There should be only one AuthnResponse.

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.

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.

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.

The new SSO token is sent to the policy agent.

The policy agent validates the SSO token and evaluates
the policies.

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.

If the user authenticates successfully, the OpenSSO
Enterprise responds by setting an SSO token in Domain1.com.

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.

The second SSO Token is sent to the policy agent.

The policy agent validates the SSO token, and evaluates
the policies.

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

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 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.

The SSO token is sent in the HTTP request to the server.

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.

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.

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.

The SSO token is sent in the HTTP request because
the OpenSSO Enterprise server 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
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.

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 assertions are extracted from the AuthnResponse. There should only be one AuthnResponse.

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

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 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.

If the user authenticates successfully, the OpenSSO
Enterprise server responds by setting an SSO token in Domain1.com.

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.

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.