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 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, 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] [2] as: [email protected] [3] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user [4] -- 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 Links: ------ [1] mailto:[email protected] [2] mailto:[email protected] [3] mailto:[email protected] [4] 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
