Well, probably not instead of. More like in addition to, right? Any particular reason why ST/TGT generation should be taken away from clients?
> On Dec 27, 2014, at 5:20 AM, Jérôme LELEU <lel...@gmail.com> wrote: > > 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 > <http://www.casinthecloud.com/> | Twitter: @leleuj > Chairman of CAS: www.jasig.org/cas <http://www.jasig.org/cas> | Creator of > pac4j: www.pac4j.org <http://www.pac4j.org/> > 2014-12-24 4:38 GMT+01:00 Misagh Moayyed <mmoay...@unicon.net > <mailto: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 <https://github.com/Jasig/cas/pull/452> > > > On Dec 23, 2014, at 12:31 PM, William G. Thompson, Jr. <wgt...@gmail.com > > <mailto: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 > > <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 > > <mailto: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 > >> <https://groups.google.com/forum/#!topic/jasig-cas-dev/ybQcp5RsYFw> > >> [2] https://github.com/Jasig/cas/issues/503 > >> <https://github.com/Jasig/cas/issues/503> > >> > >> -- > >> You are currently subscribed to cas-dev@lists.jasig.org > >> <mailto:cas-dev@lists.jasig.org> as: wgt...@gmail.com > >> <mailto:wgt...@gmail.com> > >> To unsubscribe, change settings or access archives, see > >> http://www.ja-sig.org/wiki/display/JSG/cas-dev > >> <http://www.ja-sig.org/wiki/display/JSG/cas-dev> > > > > -- > > You are currently subscribed to cas-dev@lists.jasig.org > > <mailto:cas-dev@lists.jasig.org> as: mmoay...@unicon.net > > <mailto:mmoay...@unicon.net> > > To unsubscribe, change settings or access archives, see > > http://www.ja-sig.org/wiki/display/JSG/cas-dev > > <http://www.ja-sig.org/wiki/display/JSG/cas-dev> > > > > > -- > You are currently subscribed to cas-dev@lists.jasig.org > <mailto:cas-dev@lists.jasig.org> as: lel...@gmail.com > <mailto:lel...@gmail.com> > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev > <http://www.ja-sig.org/wiki/display/JSG/cas-dev> > > > -- > You are currently subscribed to cas-dev@lists.jasig.org > <mailto: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
