About the Liberty ID-FF Process

The Liberty ID-FF is designed to work with heterogeneous platforms,
various networking devices (including personal computers, mobile phones,
and personal digital assistants), and emerging technologies. The process
of Liberty ID-FF federation begins with authentication. A user attempting
to access a resource protected by OpenSSO Enterprise are redirected to the proprietary Authentication Service via
an OpenSSO Enterprise login page. After the user provides credentials, the Authentication Service allows
or denies access to the resource based on the outcome.

When the user attempts access to a resource that belongs to
a trusted member provider of a configured circle of trust, the process
of user authentication begins with the search for a valid OpenSSO Enterprise session
token from the proprietary Authentication Service. The process can go in one of two
directions based on whether a session token is found.

If no session token is found, the principal is redirected
to a location defined by the pre-login URL to establish a valid session.

If a session token is found, the principal is granted
(or denied) access to the requested page. Assuming access is granted,
the requested page contains a link so the principal may federate the OpenSSO Enterprise identity
with the identity local to the requested site. If the principal clicks
this link, federation begins.

Figure 11–5 illustrates
these divergent paths. The process shown is the default process when
no application has been deployed. When an application is deployed
and using OpenSSO Enterprise, the process will change based on the query parameters
and preferences passed to OpenSSO Enterprise from the participating application.
For more information, see Sun OpenSSO Enterprise 8.0 Administration Guide.

Figure 11–5 Default Process of Federation

As illustrated, the pre-login process establishes a valid OpenSSO Enterprise session.
When a principal attempts to access a service provider site and no OpenSSO Enterprise session
token is found, OpenSSO Enterprise searches for a federation cookie. A federation
cookie is implemented by OpenSSO Enterprise and is called fedCookie. It can have a value of either yes or no, based on the principal’s federation status.

Note –

A federation cookie is not defined
in the Liberty Alliance Project specifications.

At this point, the pre-login process may take one of the following
paths:

If a federation cookie is found and its value is no, a OpenSSO Enterprise login page is displayed and the principal submits
credentials to the proprietary Authentication Service. When authenticated by OpenSSO Enterprise,
the principal is redirected to the requested page, which might contain
a link to allow for identity federation. If the principal clicks this
link, federation begins.

If a federation cookie is found and its value is yes, the principal has already federated an identity but
has not been authenticated by an identity provider within the circle
of trust for this OpenSSO Enterprise session. Authentication to OpenSSO Enterprise is achieved
on the back end by sending a request to the principal’s identity
provider. After authentication, the principal is directed back to
the requested page.

If no federation cookie is found, a passive authentication
request (one that does not allow identity provider interaction with
the principal) is sent to the principal’s identity provider.
If an affirmative authentication is received back from the identity
provider, the principal is directed to the OpenSSO Enterprise Authentication Service, where a
session token is granted. The principal is then redirected to the
requested page. If the response from the identity provider is negative
(for example, if the session has timed out), the principal is sent
to a common login page to complete either a local login or Liberty ID-FF federation.