Eric, That solves it. Nicely done. That amounts to the Untrusted Application no longer being a bearer of the bearer token (proxy ticket) since if the encryption works the Untrusted Application never gets to see the plaintext proxy ticket.
This is a nice solution in that it requires no modification to the CAS server itself. Andrew On Fri, Jan 11, 2013 at 1:15 PM, Domazlicky, Eric <[email protected]>wrote: > Andrew,**** > > ** ** > > Maybe I’m missing something but couldn’t the CAS Proxy Tomo describes > simply encrypt the Proxy Ticket when presenting it to the untrusted > application, thus negating the issues with the Untrusted application having > access to a cleartext Proxy Ticket?**** > > ** ** > > *From:* Andrew Petro [mailto:[email protected]] > *Sent:* Friday, January 11, 2013 9:34 AM > *To:* [email protected] > *Subject:* Re: [cas-user] Using CAS Proxy to provide "untrusted" apps > access to business data services?**** > > ** ** > > Tomo,**** > > ** ** > > Clever on the Untrusted Application never uses CAS itself.**** > > ** ** > > The campus page sets the targetService so the Untrusted app can't provide > an alternate service address. All the untrusted app ever gets is a > proxyticket that it passes through to a campus-defined service facade that > submits the proxyticket to get the user's ID and then use that to call the > real service. The untrusted app only ever gets ProxyTickets through > requests to a campus landing page that is invisible to the user but which > does the calls to CAS to get the ProxyTicket to give to the Untrusted app. > **** > > ** ** > > Okay. But the Untrusted Application, instead of presenting the proxy > ticket to the Institutional Web Service, can instead validate the proxy > ticket itself with CAS, specifying the service parameter as that of the > Institutional Web Service. Now the Untrusted Application has the > end-user's username. And then it drops a cookie or notes the IP address or > even uses fancy browser fingerprinting to "remember" this user.**** > > ** ** > > And then it displays an error page "Sorry, an error occurred. Please try > again."**** > > ** ** > > And then the end user tries again. Sames steps to get another Proxy > Ticket to the Untrusted Application. This time the Untrusted Application > presents that Proxy Ticket to the Institutional Web Service.**** > > ** ** > > And now the Untrusted Application combines the user identity and the > Institutional Web Service's data to break the anonymity.**** > > ** ** > > The problem is that proxy tickets are fundamentally bearer tokens, and if > they pass through the Untrusted Application, the Untrusted Application gets > to be the bearer and can choose to itself redeem the ticket rather than > presenting it to its intended recipient. You can achieve the anonymity in > the Untrusted Application that you seek by authenticating the Institutional > Web Service when the Institutional Web Service gets the username. That > could either be by enhancing CAS to support client authentication on the > validation request (i.e., proxy tickets stop being bearer tokens and start > being redeemable only by their intended recipient) or by requiring the > Institutional Web Service to itself get a PGT and use a PT with itself as > the last authenticated proxy in the chain to get the username (proxy > tickets remain bearer tokens, but the Untrusted Application never gets to > bear a token that can be redeemed for a username).**** > > ** ** > > Kind regards,**** > > ** ** > > Andrew**** > > ** ** > > ** ** > > ** ** > > On Fri, Jan 11, 2013 at 12:05 PM, <[email protected]> wrote:**** > > Andrew,**** > > Thanks for the feedback! **** > > My idea was that the untrusted app has NO direct contact with CAS - it > redirects to a campus page that redirects to cas (along with a parameter > that specifies the untrusted app's URL so the campus page can redirect the > user back to the untrusted app after the authentication with CAS). CAS > sends them back to the campus page which then sends the proxyticket as an > argument in a redirect back to the untrusted app. **** > > Untrusted App - > UCB Landing Page (which gets Untrusted App referrer URL) > -> CAS (with referrer URL as parameter) -> UCB Landing Page (with referrer > URL as parameter) -- CAS call to get ProxyTicket -> Untrusted App (with > ProxyTicket as parameter)**** > > To the user it looks like they're authenticating from the untrusted app > but they're really authenticating to a campus page that it is doing all the > heavy lifting and passing the proxyticket to the untrusted app so it can > make its service call. The campus page sets the targetService so the > Untrusted app can't provide an alternate service address. All the > untrusted app ever gets is a proxyticket that it passes through to a > campus-defined service facade that submits the proxyticket to get the > user's ID and then use that to call the real service. The untrusted app > only ever gets ProxyTickets through requests to a campus landing page that > is invisible to the user but which does the calls to CAS to get the > ProxyTicket to give to the Untrusted app. **** > > Does that make more sense?**** > > Thanks!**** > > Tomo**** > > **** > > On Fri, 11 Jan 2013 08:36:58 -0500, Andrew Petro <[email protected]> > wrote:**** > > Tom, **** > > > We've got our CAS locked down so that only approved apps can access it > AND it also uses the targetService parameter so that only an app at the > targetService URL can submit the proxyTicket - if the untrusted app (or any > other) tries to submit it then it gets an error**** > > ** ** > > Service identifier checking on ticket validation may not be buying you > what you think it's buying you. :)**** > > ** ** > > The purpose of service identifier checking on ticket validation, that is, > the reason that CAS requires that the service= parameter match on > /cas/login?service= and /cas/serviceValidate?service=, e.g., and on > /cas/proxy?targetService= and on /cas/proxyValidate?service= , is *not* to > prevent an entity other than the intended target of the ticket from > validating the ticket. This check *doesn't* accomplish that.**** > > ** ** > > Rather, the purpose of that matching is to prevent the entity validating > the ticket from *accidentally* accepting as authenticating to it a ticket > intended to authenticate to some other service.**** > > ** ** > > Close, but an important distinction.**** > > ** ** > > So, yes, an Untrusted Application would get a ticket validation error > represented in the CAS server logs along the lines of**** > > ** ** > > ticket 'ST-263-PjTUuKYMKkG7xFsefRgy-cas-t1' does not match supplied > service. The original service was '.../CASProxyFacade/CASProxy.asp' and the > supplied service was '.../CASProxyFacade/untrustedapp.asp'.**** > > ** ** > > if it wasn't careful enough in abusively validating the proxy ticket it > obtained via /cas/proxy, but of course all the Untrusted Application has to > do is be smarter about what value it supplies for the service= on that > ticket validation request to overcome this.**** > > ** ** > > Vis: [1]**** > > ** ** > > End user logs in to Untrusted Application:**** > > ** ** > > /cas/login?service=UntrustedApplication**** > > ** ** > > CAS supplies an ST and issues the redirect, to**** > > ** ** > > UntrustedApplication?ticket={service_ticket}**** > > ** ** > > UntrustedApplication validates the service ticket, intended for it, as**** > > ** ** > > > /cas/serviceValidate?service=UntrustedApplication&ticket={service_ticket}&pgtUrl=UntrustedApplicationCallbackUrl > **** > > ** ** > > CAS does the proxy callback in the middle of this pushing a Proxy Granting > Ticket {pgt} and PGTIOU to the UntrustedApplicationCallbackUrl, and > responds to the validation request with a validation response. Suppose the > CAS service registry is configured such that the Untrusted Application gets > an opaque identifier rather than the end user's username, so the user > remains anonymous. The Untrusted Application now has a PGT. **** > > ** ** > > The Untrusted Application exercises its PGT to obtain a PT:**** > > ** ** > > /cas/proxy?pgtId={pgt}&targetService=InstitutionalWebService .**** > > ** ** > > CAS responds to this by giving the Untrusted Application a Proxy Ticket > {pt}.**** > > ** ** > > Now. What the Untrusted Application is intended to do is present that > {pt} unvalidated to the Institutional Web Service which would validate it. > But instead, the Untrusted Application goes ahead and validates it itself: > **** > > ** ** > > /cas/proxyValidate?ticket={pt}&service=InstitutionalWebService**** > > ** ** > > CAS *isn't* authenticating that it's the InstitutionalWebService that's > asking. It's only answering the question "Whom, if anyone, does this > ticket authenticate to this service?" And the answer that that is: the end > user, as proxied through UntrustedApplication. Which CAS releases in the > validation response.**** > > ** ** > > So now the user is no longer anonymous to UntrustedApplication. > UntrustedApplication has determined the username.**** > > ** ** > > Then UntrustedApplication again exercises its PGT to obtain another PT:*** > * > > ** ** > > /cas/proxy?pgtId={pgt}&targetService=InstitutionalWebService .**** > > ** ** > > CAS responds to this issuing a new Proxy Ticket, let's call it {pt2}**** > > ** ** > > Now UntrustedApplication accesses InstitutionalWebService, authenticating > using that {pt2}, to get some information**** > > ** ** > > InstitutionalWebService/courseScheduleForUser?ticket={pt2} , say.**** > > ** ** > > Even if InstitutionalWebService's reponse is in itself carefully > anonymized, UntrustedApplication can now marry that response to what it > knows about this user to match the schedule back up with the individual.** > ** > > ** ** > > So, if the InstitutionalWebService is configured, via the CAS services > registry, to get the username in ticket validation responses, and if > UntrustedApplication can proxy to InstitutionalWebService, > UntrustedApplication can get the username.**** > > ** ** > > ** ** > > A couple tweaks you could make to address this. One would be to really > require that CAS-using applications authenticate themselves when validating > tickets. This is a Good Idea. Client SSL certs or shared secrets or > something. Dovetails into current discussions of next rev of CAS Protocol. > **** > > ** ** > > Another would be to also configure Institutional Web Service to itself > receive anonymized (opaque identifier) validation responses from CAS, but > allow it to in turn proxy to another service that is able to validate that > proxy ticket to get the username from CAS and then releases that username > back to Institutional Web Service. That is, invent a > UsernameReleasingWebService that accepts a proxy ticket from specific > trusted institutional proxying applications. UntrustedApplication would not > be permitted to proxy CAS authenticate directly to > UsernameReleasingWebService. InstitutionalWebService would.**** > > ** ** > > This solves the problem because applications *are* authenticated when the > obtain proxy granting tickets. So you can be sure, when you're presented > with a valid proxy ticket, that it came through the described chain. > Releasing the attribute only in the face of a PT authenticating the > application you want to release the attribute to solves the problem of > authenticating the application obtaining the attribute.**** > > ** ** > > Hope all this helps,**** > > ** ** > > Andrew**** > > ** ** > > [1] : where UntrustedApplication, UntrustedApplicationCallbackUrl, > InstitutionalWebService are all properly encoded URLs :)**** > > ** ** > > ** ** > > ** ** > > On Fri, Jan 11, 2013 at 12:28 AM, <[email protected]> wrote:**** > > Hi Andrew,**** > > Thanks for the thoughtful response - I hadn't thought to try attempting to > get the id from the proxyticket in the untrusted app since I was pretty > sure the proxy request's targetService URL restricted it but that was just > an assumption!**** > > We've got our CAS locked down so that only approved apps can access it AND > it also uses the targetService parameter so that only an app at the > targetService URL can submit the proxyTicket - if the untrusted app (or any > other) tries to submit it then it gets an error like**** > > ticket 'ST-263-PjTUuKYMKkG7xFsefRgy-cas-t1' does not match supplied > service. The original service was '.../CASProxyFacade/CASProxy.asp' and the > supplied service was '.../CASProxyFacade/untrustedapp.asp'.**** > > We'll have to make sure any changes to our config doesn't undo the > targetService > validation!**** > > Any other thoughts or comments - this was very helpful!**** > > Thanks,**** > > Tomo**** > > **** > > On Thu, 10 Jan 2013 18:06:07 -0500, Andrew Petro <[email protected]> > wrote:**** > > Clever. **** > > Let me summarize as an Untrusted Application is to use a CAS Proxy Ticket > to authenticate to an Institutional Web Service, and you'd like the end > user to be anonymous to the Untrusted Application but known (further, > authenticated) to the Institutional Web Service.**** > > In a normal CAS interaction, the end user would log into the Untrusted > Application using CAS and the Untrusted Application would obtain a Proxy > Granting Ticket in the course of validating the Service Ticket, and would > see the end user's identity from that Service Ticket validation.**** > > Of course, you could configure CAS via the service registry such that the > Untrusted Application *doesn't* get the end user's userid and instead gets > an opaque identifier. That should solve the > user-is-anonymous-to-the-untrusted-application problem.**** > > The Untrusted Application is going to use that Proxy Granting Ticket to > obtain a Proxy Ticket, and then will present that Proxy Ticket to the > Institutional Web Service to obtain some interesting if anonymized > information. As you say, the Institutional Web Service is going to need to > redeem that Proxy Ticket for a validation response including the end user's > identity.**** > > And here's a problem. In normal, ootb CAS, nothing authenticates the > service validating a service or proxy ticket. So the Untrusted Application > could, instead of presenting the Proxy Ticket to the Institutional Web > Service, instead itself validate the Proxy Ticket with CAS and get the CAS > validation response that was intended for the Institutional Web Service. > That validation response will have the end user's identity in it. The end > user is no longer anonymous.**** > > I suppose you could solve that by introducing authentication of the > application requesting ticket validation. That wouldn't be that hard to > do, whether by shared secret, or SSL client cert. And then CAS would know > to only validate the proxy tickets intended for the Institutional Web > Service when the Institutional Web Service authenticates for that > validation call.**** > > More generally, yes, CAS and proxy CAS does enable a different kind of > trust of the developers involved. I worked on Yale's portal as a student > employee. One neat consequence of proxy CAS is that I *couldn't* > arbitrarily query production web services accepting proxy tickets even > though I was developing portlets (well, then, channels) that exercised > those services. Could only get a valid production proxy ticket in the > context of a real production CAS SSO session, after all. Very nice, that. > **** > > Hope this note helps. Sounds like a fun project and I hope to hear how it > goes.**** > > Kind regards,**** > > Andrew**** > > ** ** > > On Thu, Jan 10, 2013 at 5:39 PM, <[email protected]> wrote:**** > > Hi folks, > > We have a number of eager and talented student developers who would love > to be able to build powerful apps to help their peers. The challenge is > that many of the richest applications would use sensitive data (e.g. a > student's Previous/Current Class Enrollments so they could build a Class > Scheduling App using available Class Schedule data). > > It would be inadvisable to allow unknown apps to query sensitive business > services directly, but it is possible to use CAS Proxy to have the user > authenticate to a campus page and then redirect the user's browser (along > with a proxy ticket) to an untrusted app which could then send the proxy > ticket to a service facade that was set to receive the proxy ticket, get > the user's ID from CAS using the proxyticket and send the id to a business > service (e.g. a Transcript Service) and then return the business data (e.g. > past class enrollments) without any personally identifiable information. > > Given this configuration, a student app could take any CAS authenticated > user and get business data for that user (and only that user) that would be > appropriate for this purpose (e.g. just business data that has no PII). > The key is that the untrusted app never receives anything that can be tied > to the user - all it ever receives is a proxyticket and unidentifiable > business data. > > Has anyone done this already or see any red flags about it? > > > Thanks! > > Tom O'Brien > > > -- > You are currently subscribed to [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user**** > > -- > You are currently subscribed to [email protected] as: > [email protected]**** > > ** ** > > ** ** > > ** ** > > ** ** > > > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user**** > > **** > > -- > You are currently subscribed to [email protected] as: [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user**** > > -- > You are currently subscribed to [email protected] as: [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user**** > > **** > > -- > You are currently subscribed to [email protected] as: [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user**** > > ** ** > > -- > You are currently subscribed to [email protected] as: > [email protected] > > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user**** > > -- > You are currently subscribed to [email protected] as: [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
