<div dir="ltr"><div class="gmail_quote"><div dir="ltr">I'm late to this thread -- was out in the woods yesterday.<br></div><div dir="ltr"><br></div><div dir="ltr">On Wed, Mar 9, 2016 at 8:06 PM Andrew Morgan <<a href="mailto:morgan@orst.edu">morgan@orst.edu</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
>> The CAS Protocol 3.0 spec says:<br>
>><br>
>> Services MUST be able to accept service tickets of up to 32 characters in<br>
>> length. It is RECOMMENDED that services support service tickets of up to<br>
>> 256 characters in length.<br></blockquote><div><br></div><div>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).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
>> I don't think that is enough space to track everything needed for a CAS<br>
>> session.  :(<br>
><br>
> 32 isn't, but unless you need much more than a username, 256 should be.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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. <br></blockquote><div><br></div><div>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.</div><div><br></div><div>M<a href="mailto:users-unsubscribe@shibboleth.net" target="_blank"></a><br>
</div><div><br></div></div></div>