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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[email protected]> as: [email protected]<mailto:[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]<mailto:[email protected]> as: [email protected]<mailto:[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]<mailto:[email protected]> as: [email protected]<mailto:[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]<mailto:[email protected]> as: [email protected]<mailto:[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]<mailto:[email protected]> as: [email protected]<mailto:[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]<mailto:[email protected]> as: [email protected]<mailto:[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
