How to make ajax CORS requests to shibboleth protected rest api?

[Jim Fox]

Since rest-api trusts siteA completely this can be simpler, using what 
Oauth calls "Client Credentials Grant" (effectively cutting out a 
middleman).

1) siteA authenticates user, and calls rest-api's token endpoint with user info.
2) rest-api constructs a token (just a session cookie, really) and gives it to siteA.
3) siteA included the token on the web page it sends to the browser.
4) javascript includes the token in all requests to rest-api.

The token is a session cookie is every respect except for how it's delivered.

Jim




On Thu, 28 May 2015, Luke Palnau wrote:

> Date: Thu, 28 May 2015 12:14:58
> From: Luke Palnau <lpalnau at umich.edu>
> To: Liam Hoekenga <liamr at umich.edu>, users at shibboleth.net
> Cc: DePriest Dockins <ddockins at umich.edu>
> Reply-To: Shib Users <users at shibboleth.net>
> Subject: Re: How to make ajax CORS requests to shibboleth protected rest api?
> 
> I think I understand this, but let's check:
> rest-api (new rest api protected by oauth2 that doesn't want to have to reauthenticate consumers from siteA)
> siteA (original site protected by shib that wants to make ajax calls to the new protected rest-api)
> rest-api and siteA are not on the same domain name, thus making the ajax calls CORS.
>  1. siteA loads and browser negotiates for shib session
>  2. siteA then sends browser to get a 3-legged oauth2 token from rest-api (using google OAUTH2 provider). 
>  3. browser is already shib authenticated (and would need to authorize rest-api the first time)
>  4. browser gets sent to the callback url at rest-api
>  5. rest-api stores the token and its expiration in a token store (to validate future calls to protected endpoint)
>  6. browser gets redirected back to siteA with the token as a url parameter (All remaining calls to protected rest-api endpoints by siteA must
>     contain the OUATH2 token in the request header.)
>  7. siteA calls protected rest-api endpoint with OAUTH2 token
>  8. protected rest-api endpoints looks in the token store to see if the provided token is valid and not expired before responding
>  9. cron purges expired token records on a regular basis.
> If that's correct/close, does google's OAUTH2 provider keep hackers from submitting tokens on the callback url, or is that not really an issue?
> 
> 
> 
> -Luke
> 734.604.2271
> 
> On Wed, May 27, 2015 at 5:00 PM, Liam Hoekenga <liamr at umich.edu> wrote:
>
>       On Wed, May 27, 2015 at 3:15 PM, Jim Fox <fox at washington.edu> wrote:
>                   I don't really follow the rest of the message, but that is the technical situation. AJAX calls normally have
>                   to happen after the browser has negotiated for a session (by virtue of them having access to the same cookie
>                   store when they make the calls to the server).
> 
>
>             We do this cross-domain ajax using an oauth mechanism.  The original site, where you have a session, sets a token on the
>             app's page.  Your ajax code includes this token in requests to the remote site where it is used for authn.  It's not shib
>             or saml.
> 
> 
> Hi Luke -
> 
> We don't currently offer a centralized OAUTH2 provider.  DePriest and I met with the Law School about a month ago, and they've expressed
> their interest in such a service.
> 
> In the meantime, you might be able to use the one provided by the Directory of APIs (http://developer.it.umich.edu/), but I think you'd
> probably need to put register your APIs with that service (they wouldn't need to be publicly available).
> 
> You could also take advantage of the OAUTH2 provider offered via Google (I think this is what you want
> - https://developers.google.com/+/api/oauth).  Since our google instance is protected using Shibboleth, you'd be using UMich accounts.
> 
> Liam
> 
> 
> 
>