Shibboleth IDP 3 as CAS Server

[Cantor, Scott]

On 6/12/15, 11:33 AM, "dev on behalf of Marvin Addison" <dev-bounces at shibboleth.net on behalf of marvin.addison at gmail.com> wrote:

>The main requirement for an IdPSession is for tracking an SPSession to support SLO, which is an important use case in CAS. I suppose that could be made optional, which I recall is what you did in the SAML SSO flows.

Got it. I think it would be very advisable to make that optional because it would be very nice for people to be able to use the CAS support on a clustered IdP with only the CAS portion impacted by any added clustering considerations. Also without having to enable sessions if for whatever reason that was desired. Just for consistency if nothing else.

>The other prominent case is that I couldn't figure any other way for determining a principal name other than by digging it out of the IdP session; see BuildAttributeContextAction for an example.

Could it be stored together with the ticket? I guess I thought it was actually in the ticket.

I don't know if it's an option or not (ticket size limitations?) but the other trick is encrypting the user identity into the value used as a ticket, which is how queries in SAML get supported with transients.

-- Scott