Skip to Content.
Sympa Menu

oidc-survey - Re: Quick notes from today's OIDC Survey meeting

Subject: OIDC Survey Working Group

List archive

Re: Quick notes from today's OIDC Survey meeting


Chronological Thread 
  • From: Alan Crosswell <>
  • To: David Walker <>
  • Cc: , , , Dedra Chamberlin <>, Gary Chapman <>, , , , , , , , , , "Wu, Albert" <>, ,
  • Subject: Re: Quick notes from today's OIDC Survey meeting
  • Date: Tue, 27 Sep 2016 10:02:14 -0400
  • Ironport-phdr: 9a23:mUs07xfX49CG0eM2QzV/sRF6lGMj4u6mDksu8pMizoh2WeGdxc2zbR7h7PlgxGXEQZ/co6odzbGJ4+a9AidZvN6oizMrTt9lb1c9k8IYnggtUoauKHbQC7rUVRE8B9lIT1R//nu2YgB/Ecf6YEDO8DXptWZBUj22Dwd+J/z0F4jOlIz3krnqo9yAKzlP0Ra0f7J+ZCq/qQbcrIFCjZRrLqU80DPIpGdFYeJb2TkuKF6OyUXS/MC1qbdn+iIYkOgm7NVfXKH+N/AxSbVeJD8hN30w7szi8xTPUF3ctTMnTmwKn08QUED+5xbgU8K063Oiuw==

Sorry I'm not there for TechEx. I've been experimenting with a number of OAuth2/OIDC implementations with the primary focus of integrating with MuleSoft API Gateway (commercial product). I briefly looked at MitreID Connect, then kind of landed on WSO2-IS and OpenAM, with PingFederate on the to-do list. According to MuleSoft documentation (which doesn't always match reality), their cloud integration product only supports OpenAM or PingFederate (both commercial products; OpenAM is CDDL fake open source). I may have this wrong. One can certainly use any OAuth2/OIDC OP for Oauth2 flows, but MuleSoft also needs to register the same client credentials for things like SLA-based rate-limiting and throttling policies, client registration and approval workflows, operational metrics collection and so on.

The goals I am trying to achieve are:
- easy API consumer workflow to register clients
- federation support for authorization code workflow with SAML (Shib or CAS), social (Facebook, Google, etc.)
- access token validation and exposure of OIDC subject and valid scopes to the Mulesoft app (via HTTP headers passed from the API GW policy engine)
  - This can be an OIDC JWT, or an online method of token introspection like RFC7662. I prefer to avoid proprietary (undocumented) online token validation.

Open questions/wants/wishes for me are:
- User/subject approval of individual scopes (OpenAM and WSO2-IS approvals appear to be all or nothing, but maybe I just haven't studied them enough)
- Questionable whether early access token revocation (before expiration) is a requirement or not. 
  - Mulesoft's OAuth2 API GW Policies cache the validation (using an undocumented validation endpoint but likely using userinfo/tokeninfo endpoints) for the life of the access token so as to avoid hitting the OP too much.
  - JWT's are of course offline so have no early revocation option. 
  So maybe it's just a question of how much exposure time post-revocation we are worried about which determines the lifetime of the access token.

For those using MuleSoft Anypoint Platform for API Gateway policy management, I've got an alpha-quality OAuth2 RFC7662 introspect validation policy here. Currently does not cache so performance will be poor. There's also a JWT validation policy by Mulesoft here.

/a

On Mon, Sep 26, 2016 at 5:31 PM, David Walker <> wrote:

Everyone,

I've posted some quick notes from today's lunch meeting on our wiki space (https://spaces.internet2.edu/x/5wYZBg).  Please fix my mistakes and omissions.

I've also added instructions for subscribing to our mailing list on the wiki. ("To subscribe this list, email with the subject line subscribe oidc-survey.") Please do so soon, as I make no promises to continue to send to all of you individually in the future...

David




--
Alan Crosswell
Assoc. VP & CTO




Archive powered by MHonArc 2.6.19.

Top of Page