DataSealer dependencies

[Marvin Addison]

I'm late to this thread -- was out in the woods yesterday.

On Wed, Mar 9, 2016 at 8:06 PM Andrew Morgan <morgan at orst.edu> wrote:

> >> The CAS Protocol 3.0 spec says:
> >>
> >> Services MUST be able to accept service tickets of up to 32 characters
> in
> >> length. It is RECOMMENDED that services support service tickets of up to
> >> 256 characters in length.
>

That's also what the v2 specification says, but it's worth noting that the
IdP functionality targets the 2.0 protocol with a couple extensions that
became 3.0 features (attribute release, method=POST).


> >> I don't think that is enough space to track everything needed for a CAS
> >> session.  :(
> >
> > 32 isn't, but unless you need much more than a username, 256 should be.
>

It's a little weird how this began about DataSealer and moved to CAS
storage implementation, but there is indeed a connection. So I do think
it's possible to encode all the data needed by some kinds of tickets in the
ticket itself using the data sealer such that there's no storage
requirement at all. I'm pretty sure this would work fine for service
tickets; for proxy-granting tickets, I'd have to give more thought.

I don't think that any CAS client I'm aware of has any practical limitation
on maximum ticket length beyond browser limits, so the latter would be the
limitation in practice, which is something we're already dealing with.


> What about the list of services that were used, for the purpose of
> SLO? ... I don't know if there are other things stored in the CAS session.
>

There is no "CAS session" per se; the CAS session is the IdP session. The
IdP session does the session tracking, the CAS protocol simply looks up the
IdP session and stores the service information (if the session is found).
This is the functionality that you'd lose with dropping server-side
storage: no SLO for CAS services. I fully believe in choices, and if that's
one that some deployers would find useful, I'm all for it. I'll file an RFE
to investigate "stateless tickets" and start a new thread so folks can
follow.

M <users-unsubscribe at shibboleth.net>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20160310/0733ba7d/attachment.html>