Information Technology Reference
In-Depth Information
2.
The Service Provider has no way of authenticating the RA or of trusting
any credentials that the RA may present to it directly. So it redirects the
RA to an Identity Provider (IdP) that it trusts, and will only accept a
proof of authentication from that trusted source. With CAS, this is a
simple HTTP redirect to the URL of the IdP, with the URL of the SP
appended. The latter URL is required because the IdP needs to be able
to redirect the RA back to the original SP after successful validation of
the RA's credentials.
3.
The RA follows the redirect and accesses the IdP. With CAS, since the
URL contains the SP's URL, the IdP knows which application is being
accessed.
4.
The IdP challenges the RA to provide authentication credentials. In the
case of CAS, this is usually just a login page that employs HTTP Form-
based Authentication.
5.
The RA submits its credentials to the IdP. With CAS, a user fills in the
login page with a user ID and password and submits the form. The form
submission is over HTTPS for security.
At this point, the IdP validates the user's credentials against a repository
(usually an LDAP directory). If the credentials are valid
20
, the IdP
generates two tokens - the Authentication Token is called a “Ticket-
Granting Ticket” (TGT), which is the Single Sign-On token. Production of
this token by the RA within a certain session duration means the RA will
not have to log in afresh. The Application Access Token is called a
“Service Ticket” (ST) that the Service Provider requires if it has to allow
the RA access to its functions. In CAS, the TGT is a session cookie while
the handle to the ST is a string appended to the application's URL. The
tickets are also stored in a local Ticket Registry for future reference, as
will be seen
21
. The TGT is typically stored for a few hours because that
defines the length of an SSO session, while the ST only needs to be
20
If the credentials are not valid, CAS can be configured to simply display the
login page again. This can continue until the directory server locks out the
user account.
21
CAS can be extended to retrieve any additional user attrib utes from a user
repository after authentication, and to store these attributes along with the
TGT in a “blob” attribute that is meant for this purpose. This is done just
once at initial login, and these user attributes can thenceforth be retrieved
from the Ticket Registry on each subsequent application access, saving a
fresh user repository access each time.
