They should be the correct length. I believe we're using this to generate SAML tokens: https://www.ja-sig.org/svn/cas3/trunk/cas-server-core/src/main/java/org/jasig/cas/util/SamlCompliantUniqueTicketIdGenerator.java
Cheers, Scott On Mon, Jul 20, 2009 at 5:03 PM, Aaron Fuleki <[email protected]> wrote: > 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 > -- 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
