Yes, one can see the interaction similarities. One big difference is PGT/PT requires a valid TGT/ST to start with.
Initially the REST interface was created to support services making use of other CAS protected services directly (i.e. no human user present). So it follows that TGT/ST would be issued directly against the service credential rather than proxied via a user credential. Supporting the native desktop/mobile app use case came after the fact and was not part of the initial design. While there are examples of folks using the REST interface for this, it's not clear to me that the community/project has a recommended approach. This important use case probably could use some thought. Happy New Year! Best, Bill On Wed, Dec 31, 2014 at 4:05 AM, Jérôme LELEU <lel...@gmail.com> wrote: > 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: 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: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
