[OpenID] Return Authorities to Client

[Peter Williams]

I'm ever less invoked in us real estate it , but one of the things I'm still doing as a consulting task is show how to build a cascade of 3 (and perhaps 4) openid providers (and articulate why).

First, assume a google-like spa world in which a website exposes endpoints suitable for downloading Javascript apps (and libraries in Javascript implementing such as ssl/https). Those are augmented by webapi endpoints, to which the modules first do a secure bind (applying openid discovery over that custom https). Being oauth clients, they talk to the webapi's own as endpoints to get bearer tokens (id tokens, in spa).

in my workd, such a spa is supported by a real estate specific as (that knows about real estate claims). Ie. Authorization in the webapi as may invoke authorization and perhaps saml2 idp at the real estate as. A chain of tokens is the result (in the webapi calls).

Being a Microsoft shop, our as endpoints for that real estate as/idp are really a wrapper for an as/idp (federated or not) delivered by the azure aad fabric. Which mints and signs jrt etc.

what i expect us: chains of tokens  and ckaims in a leaf token that conveys the provenance of its value (from a upstream token, relied upon by such as an aad instance that uses, say, a google openid connect service).

I had all this is saml/sts era. And I used it heaviky. I expect it in openid connect land too, when building out a national scale (realty scoped) id fabric (that cooperates with every other industries similar fabric when contributing to a single national Id).

written on a phone. Hope it makes sense.

From: cal at fbsdata.com
Date: Mon, 7 Dec 2015 08:43:45 -0600
To: steve.garing at guvera.com
CC: openid-general at lists.openid.net
Subject: Re: [OpenID] Return Authorities to Client

I'll take a crack at this, even though I'm probably not the most qualified to do so.  OAuth2 scopes are outside the specification scope of OpenID Connect.

However, section 5.1.2 states that you can add any custom claims that you'd like.  Pick a unique name like "mitre_scopes" and add it to your discovery document's claims_supported property.  Then expose that claim as an array over ID Tokens/UserInfo as normal.

This is non-standard though, so it doesn't fully answer your question.  You might want to take a look at User-Managed Access (UMA) which is a standard way of conveying authorization / access control between many parties.  I'm in my beginning phases of researching UMA, so don't take my advice too heavily.  ;-)
Good luck!

--Cal

---------------------------------------------------------------
Cal Heldenbrand
   Web Operations at FBS
   Creators of flexmls® and Spark Platform
   cal at fbsdata.com

On Mon, Dec 7, 2015 at 4:42 AM, Steve Garing <steve.garing at guvera.com> wrote:
Hi,
Is there a standard way to return the authorities to a client?  I haven’t been able to get the authorities returned via standard functionality in the MITREid Connect project and we’d like the clients to have visibility of a users role to determine some client side functionality.
Would it correct to think that the clients can request and extra scope like ‘authorities’ and then provide the authorities in the id_token and from the userinfo endpoint?
Thanks,Steve


_______________________________________________

general mailing list

general at lists.openid.net

http://lists.openid.net/mailman/listinfo/openid-general





_______________________________________________
general mailing list
general at lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20151207/e2f388b0/attachment.html>