This may be silly, but please help me wrap my head around this, fellow
listers. My research into using SAML as an SSO bridge between CAS 3
and a Juniper Networks IVE VPN appliance has resulted in the following
points, which seem to conflict somewhat; please correct me if I'm wrong.
1) CAS supports the SAML 1.1 Artifact Profile Scenario, via the
samlValidate service, which can respond with SAML assertions when
requested.
2) If I'm reading the docs correctly, CAS expects to see a valid
ticket ID as the samlp:AssertionArtifact value in the initial SAML
request (see http://www.ja-sig.org/wiki/display/CASUM/SAML+1.1 ).
3) The SAML spec states that artifacts must be exactly 42 bytes long
prior to Base 64 encoding (see section 4.1.1.8, "Artifact Format" of http://www.oasis-open.org/committees/download.php/3405/oasis-sstc-saml-bindings-1.1.pdf
). That's 2 bytes for a type code, and 20 bytes for a service id,
which only leaves 20 bytes for an assertion handle.
Furthermore, an engineer from Juniper confirmed that the IVE's
Artifact Consumer Service will reject artifacts shorter or longer than
42 bytes as invalid.
4) A CAS Ticket ID is probably longer than 20 bytes.
Question:
How is it possible to construct SAML artifact that, when received
by a downstream artifact consumer service, unpacks to reveal some
token that CAS can assert as valid? Am I missing something here? It
seems that the consumer is expected to decode the artifact and
retrieve the samlp:AssertionArtifact from the 20 byte assertion
handle, but they look longer than 20 bytes to me. I'm not sure how
else the two systems could know they are talking about the same user
session unless the artifact contains a token that correlates to a CAS
ticket or proxy ticket.
Our initial idea was to build an Inter-Site Transfer Service that sits
on a uPortal instance, intercepts requests for SAML-protected
resources, requests a proxy ticket from CAS, uses that ticket id to
generate an artifact, then posts the browser to the SAML consumer (the
Juniper VPN), which unpacks the artifact and generates a SAML request
to CAS. Do we need yet another service to cache session information
and perform lookups against artifacts?
Any insights out there?
-Aaron
---------------------------------
Aaron Fuleki
Web Services Manager
Denison University
740.587.5752
---------------------------------
--
You are currently subscribed to [email protected] as:
[email protected]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-user
