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 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}
font-size: medium;">
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} font-size: small;">
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} font-size: small;">
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} font-size: small;">
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, 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 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] [4] as:
[email protected] [5]
To unsubscribe, change settings or access archives,
see http://www.ja-sig.org/wiki/display/JSG/cas-user [6]
--
You are
currently subscribed to [email protected] [7] as: [email protected]
[8]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-user [9]
--
You are currently
subscribed to [email protected] [10] as: [email protected] [11]
To
unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-user [12]
--
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] mailto:[email protected]
[5]
mailto:[email protected]
[6]
http://www.ja-sig.org/wiki/display/JSG/cas-user
[7]
mailto:[email protected]
[8] mailto:[email protected]
[9]
http://www.ja-sig.org/wiki/display/JSG/cas-user
[10]
mailto:[email protected]
[11] mailto:[email protected]
[12]
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
