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

Luke Palnau lpalnau at umich.edu
Thu May 28 15:14:58 EDT 2015


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20150528/6c0ee026/attachment.html>


More information about the users mailing list