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
