<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>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).<br><br>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).<br><br>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).<br><br>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.<br><br>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).<br><br>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).<br><br>written on a phone. Hope it makes sense.<br><br><hr>From: cal@fbsdata.com<br>Date: Mon, 7 Dec 2015 08:43:45 -0600<br>To: steve.garing@guvera.com<br>CC: openid-general@lists.openid.net<br>Subject: Re: [OpenID] Return Authorities to Client<br><br><div dir=ltr><div><div>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.<br><br></div>However, section <a href="http://openid.net/specs/openid-connect-core-1_0.html#AdditionalClaims" target=_blank>5.1.2</a> states that you can add any custom claims that you'd like. Pick a unique name like "mitre_scopes" and add it to your <a href="http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata" target=_blank>discovery document's</a> <span style="font-family:monospace,monospace;">claims_supported</span> property. Then expose that claim as an array over ID Tokens/UserInfo as normal.<br><br></div>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. ;-)<br><div><div><div><div><div class=ecxgmail_extra><br clear=all><div><div class=ecxgmail_signature>Good luck!<br><br></div><div class=ecxgmail_signature>--Cal<br><br></div><div class=ecxgmail_signature>---------------------------------------------------------------<br>Cal Heldenbrand<br> Web Operations at FBS<br> Creators of <a href="http://flexmls.com" target=_blank>flexmls</a>® and <a href="http://sparkplatform.com" target=_blank>Spark Platform</a><br> <a href="mailto:cal@fbsdata.com" target=_blank>cal@fbsdata.com</a></div></div>
<br><div class=ecxgmail_quote>On Mon, Dec 7, 2015 at 4:42 AM, Steve Garing <span dir=ltr><<a href="mailto:steve.garing@guvera.com" target=_blank>steve.garing@guvera.com</a>></span> wrote:<br><blockquote class=ecxgmail_quote style="border-left:1px #ccc solid;padding-left:1ex;"><div dir=ltr><div><div dir=ltr><div style="font-size:13px;">Hi,</div><div style="font-size:13px;"><br></div><div style="font-size:13px;">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.</div><div style="font-size:13px;"><br></div><div style="font-size:13px;">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?</div><div style="font-size:13px;"><br></div><div style="font-size:13px;">Thanks,</div><div style="font-size:13px;">Steve</div></div></div>
</div>
<br>_______________________________________________<br>
general mailing list<br>
<a href="mailto:general@lists.openid.net">general@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-general" rel=noreferrer target=_blank>http://lists.openid.net/mailman/listinfo/openid-general</a><br>
<br></blockquote></div><br></div></div></div></div></div></div>
<br>_______________________________________________
general mailing list
general@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general </div></body>
</html>