Hi, The impacts are not completely clear to me, but it feels right to have a better split between PGT and TGT.
Going further on this, I was thinking about the meaning of the PGT: wouldn't it be better to return PGT / PT for the REST protocol instead of TGT / ST? Thanks. Best regards, Jérôme LELEU Founder of CAS in the cloud: www.casinthecloud.com | Twitter: @leleuj Chairman of CAS: www.jasig.org/cas | Creator of pac4j: www.pac4j.org 2014-12-24 4:38 GMT+01:00 Misagh Moayyed <mmoay...@unicon.net>: > 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: > lel...@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: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
