Mods to the service interface make good sense to me. Not sure we could introduce those without breaking compatibility for 4.1, could we? Record them for now for v5?
On the subject of timeouts, I think it makes sense of both the TGT and PGT to be tied together by default. We should however consider how a PGT can be created without a present TGT and what it would impact in the code to create one without the other. It looks like, looking at STImpl and TGTImpl, that the parent TGT for a PGT can become nil with ease, but we need to get a prototype together to see what the ramifications are. If it can be done with no hassle, we should consider exposing options so the PGT can live on. Another option would be to simply update the TGT timestamp so we bypass the inactivity period. Also, PGT/PT ticket ids are actually explicit now: https://github.com/Jasig/cas/pull/452 > On Dec 23, 2014, at 12:31 PM, William G. Thompson, Jr. <wgt...@gmail.com> > wrote: > > This is a good move. As you point out it should help with readability > and make it easier to reason about the code in the context of the > protocol spec....ubiquitous language as it were. > > http://martinfowler.com/bliki/UbiquitousLanguage.html > > It is probably worth considering what this change would mean to the > CAS service interface as well. Should it have analogous PGT/PT > methods? > * grantProxyTicket() > * validateProxyTicket() > * delegate(or create)ProxyGrantingTicket() > * destroyProxyGrantingTicket() > > Also a good time to think about how the TGT timeouts and user > initiated logout interact with PGTs. > > User logs to portal via CAS. Portal obtains a PGT. User initiated > logout (or TGT timeout) kills TGT while portal session remains valid. > What is/should be the state of the PGT? What happens when PGT itself > times-out, but app/portal session still valid? etc... > > Small issuer...but it is probably also worth considering > re-introducing PGT/PT into the ticket IDs. Currently they all get ST > or TGT regardless of the type of ticket. > > Best, > Bill > > > > On Mon, Dec 22, 2014 at 11:24 PM, Misagh Moayyed <mmoay...@unicon.net> wrote: >> Team, >> Among some of the design ideas that were brought up recently on cas-dev to >> reduce complexity, I think it was Bill who proposed separating PGTs and PTs >> conceptually from their counterparts so that not only they are made more >> visible in terms of cas protocol terminology, but also, I think the divorce >> would allow us to create separate expiration policies for PGTs. Something >> for which we currently have an outstanding request [1][2]. It seems like >> this is something we can do easily without breaking changes, not entirely >> sure there. I have done a cursor code review and it looks like something >> that we can achieve for 4.1 in the interest of making progress via >> incremental improvements. >> >> So, I suppose there would need to be: >> >> A ProxyGrantingTicket class, a specialized version of TicketGrantingTicket >> A ProxyTicket class, a specialized version of ServiceTicket >> Mods to CASImpl and ServiceTickets to return and delegate to the above >> components >> CASImpl would then be able to carry an extra expiration policy that would be >> fitted for PGTs >> >> >> Logically, it makes sense to me that 1-3 would be in one change block and 4 >> would be in another. It’s also possible that we do just 4 but that just >> feels a bit too queasy. So before switching gears to work on this I thought >> I’d share and ask if everyone agrees with this proposal and whether we can >> move forward. Is this agreeable? >> >> Misagh >> >> [1] https://groups.google.com/forum/#!topic/jasig-cas-dev/ybQcp5RsYFw >> [2] https://github.com/Jasig/cas/issues/503 >> >> -- >> You are currently subscribed to cas-dev@lists.jasig.org as: wgt...@gmail.com >> To unsubscribe, change settings or access archives, see >> http://www.ja-sig.org/wiki/display/JSG/cas-dev > > -- > You are currently subscribed to cas-dev@lists.jasig.org as: > mmoay...@unicon.net > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev > -- You are currently subscribed to cas-dev@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
