How to make ajax CORS requests to shibboleth protected rest api?
fox at washington.edu
Thu May 28 15:49:58 EDT 2015
Since rest-api trusts siteA completely this can be simpler, using what
Oauth calls "Client Credentials Grant" (effectively cutting out a
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.
The token is a session cookie is every respect except for how it's delivered.
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?
> 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.
More information about the users