Information Technology Reference
In-Depth Information
Extension Case Study 3: Federated Identity with SAML Tokens
In theory, it is fairly simple to extend our Two-Layer Protocol Architecture to
support federated identity mechanisms as well.
As we mentioned before, the key aspect of federated identity is that the
organisation that receives user credentials does not have to have that user
previously provisioned within its user directory. The information about the
user (a set of assertions) is taken on trust because it is asserted by a trusted
partner organisation. For this to happen, we need a way to authenticate the
assertions rather than the user. This is usually done by validating a digitally
signed document against the signing organisation's public key that has
previously been received through a trusted channel.
To understand federated identity systems better, we find it useful to refine
the standard model containing a Service Provider (SP) and an Identity
Provider (IdP), by identifying a third component that we call an Identity
Consumer (IdC). The identity Consumer is just a role played by the Identity
Provider itself when the Service Provider requests it to validate a service
token, but we find it useful to separate this role out under a separate name,
and you will see why shortly.
In the standard CAS model, the CAS SSO server is the one that performs
authentication of user credentials against a directory, checks their access
rights to the application
28
and generates tickets. At this point in time, it is the
Identity Provider, because it is generating one or more identity tokens. The
interceptor (on behalf of the application) then receives a service ticket that it
is expected to trust. Typically, the interceptor will ask the CA S SSO server to
validate the presented ticket before it grants access to the resources it
protects. It's a way of asking, “Do you really know this guy?” At this point,
the CAS SSO server plays the role of the Identity Consumer, because it is
being presented with an identity token that it has to verify.
In the non-federated case, the CAS SSO server is both the Identity Provider
and the Identity Consumer and sits within the corporate network.
28
Of course, as described before, the actual
enforcement
of access control may be
performed by the interceptor instead of by CAS based on the roles that are (or
aren't!) passed in. However, the logical function of validating authorisation is
performed by CAS.
