Information Technology Reference
In-Depth Information
Not all organisations use CAS, so we can hardly expect the Identity Assertion
to be a CAS Service Ticket. The industry standard for identity assertions is a
SAML2 29 token. We therefore need a way to validate SAML2 tokens. But as
we have seen, token validation is not all there is to federated identity
management. Even if we extend CAS to integrate with a SAML2 token
validation component, that's not an architectural fit for the federated case.
This is where Shibboleth enters the picture.
Rather than set up a completely independent infrastructure based on
Shibboleth for the federated identity case, we would like to follow our
architectural approach of using the CAS protocol internally, so that our
interceptors do not have to know about Shibboleth. The University of
California at Merced has pretty much the same idea, and they provide a
Shibboleth-CAS “gateway” to keep interceptors innocent of the existence of
Shibboleth. They have a more interesting way to justify the Two-Layer
Protocol Architecture. In their eloquent words, it is easier to “CASify”
applications than to “Shibbolize” them.
The following diagram shows a setup combining CAS and Shibboleth to
provide federated identity using the same pattern as for LAN integration
with SPNEGO.
29
Security Assertion Markup Language, a dialect of XML. CAS version 4 is slated to
support the SAML2 format even for its own Service Tickets, but the version we used
was CAS 3.3.1, which used a native format.
Search WWH ::




Custom Search