Information Technology Reference
In-Depth Information
Tip 3
: Share repositories between internal- and external-facing CAS servers
While CAS is stateless (i.e., no in-memory state), it does reference data in
three data stores, i.e., the directory, the user database and the ticket
registry.
Sharing the directory and database makes sense because you can provision
all users to a single repository and have them access either internal- or
external-facing applications, from either within the corporate LAN or from
outside. A suitable directory structure as we will describe later can support
all types of access.
Similarly, sharing the ticket registry can also make sense. In certain use
cases, it may be necessary to grant access to an application that is normally
internal-facing to an external user or vice-versa. Having a shared ticket
registry can ensure that SSO spans both internal and external systems with
no additional effort.
Tip 4
: Most importantly, try and adopt a “Two-Layer Protocol Architecture”
and use CAS to hide the various challenge/assertion protocols required, from
application interceptors
As we will see in the next three sections, we often have a requirement for
other “challenge/assertion” protocols to authenticate users. Rather than
complicate the entire Access Management infrastructure to support these
varied protocols, we suggest a simple “Two-Layer Protocol Architecture”
that looks like this:
Layer 1: The CAS protocol should be the sole “internal” protocol seen by
application interceptors, i.e., they will expect CAS service tickets with every
initial access from a browser and will redirect the browser to a CAS server if
they don't find one. They will also make a validation request to the CAS
server to verify the authenticity of every service ticket presented to them.
Layer 2: The CAS server (and any associated products) will manage the
various “external” challenge/assertion protocols that may be required.
