Information Technology Reference
In-Depth Information
overly complicate things at that stage. The user provisioning is therefore
applied to the IAM directory (not Active Directory) and database. Next, you
plan to roll out IAM to another intranet application, this time exploiting
SPNEGO and Active Directory. Let's say there's an overlap between the two
sets of users, so there are some users who will need to access both these
applications. Let's also say that the LAN user ID for these users is different
from their SSO user ID as stored in the IAM directory
49
. How will you
proceed?
Well, it depends on whether you want these users to have Single Sign -On
across these two applications right away, or whether you would like to keep
the logins separate for a while and provide Single Sign -On only after you
“harmonise” the User ID scheme.
If you want these users to get Single Sign-On rightaway, then you must
ensure that this intersecting group of users has the same UUID within AD
and in the IAM directory. Since both applications use CAS, the first
application they hit will result in a Ticket-Granting Ticket being generated
and stored in a browser cookie against the CAS server's domain name. The
TGT will also be stored in the ticket registry with that user's UUID in the
BLOB attribute. When the user then tries to access the second application
(no matter in which order the two are accessed), the browser will present
the TGT to CAS and CAS will dutifully refrain from challenging them afresh
for their authentication credentials. But here's the rub. The information
about the user that's associated with the TGT in the Service Registry has
been retrieved from the database based on the UUID stored in the directory.
Unless the UUIDs of the user in the two directories are the same, the user
information could be different depending on the order in which the
applications are accessed. This is why users who need to access multiple
applications need to have a consistent UUID across the user repositories
they span.
If, on the other hand, you're content to delay Single Sign-On until all user
authentication data is consistently and non-redundantly stored in one or the
other directory, you will need to maintain two CAS domain names, because
CAS will need to create two TGT cookies, and the only way to do that
without conflict is to store them under two different domain names. You
may use domain names like “sso.myorg.com” and “sso-spnego.myorg.com”,
for example. That way, when the user tries to access the second application,
there will be no TGT cookie corresponding to that CAS domain, so CAS will
challenge the user or browser for their credentials afresh. This is acceptable
49
E.g., LAN user IDs could be 6-character strings, while SSO User IDs could have a
“firstname.lastname” scheme.
