Hi, To reply to Misagh also, I was questioning myself (maybe uselessly) about web interactions versus REST ones.
Using his browser, the user communicates with websites and the CAS server: a cookie stores the TGT identifier, HTTP redirections are used, service tickets are delivered as url parameters, web sessions are created in websites. After being authenticated (via a service ticket) in a website, the identity can be proxified to another web service, getting a general PGT and then a PT for each target web service. PGT and PT are both parameters: no cookies, no HTTP redirections, no web sessions are involved in that case. On the other hand, a desktop / mobile application can authenticate a user and get a service ticket to call a web service. No cookies, no HTTP redirections, no web sessions involved here as well. Or maybe I ate too much Christmas pudding ;-) 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-30 19:35 GMT+01:00 Scott Battaglia <scott.battag...@gmail.com>: > The rest API is for service-to-service interaction, and in that case the > service is actually getting a TGT, not a PGT. > > On Sat, Dec 27, 2014 at 6: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 | 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: >> scott.battag...@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: 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
