<html><head><style>
body {
        font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;
        padding:1em;
        margin:auto;
        background:#fefefe;
}
h1, h2, h3, h4, h5, h6 {
        font-weight: bold;
}
h1 {
        color: #000000;
        font-size: 28pt;
}
h2 {
        border-bottom: 1px solid #CCCCCC;
        color: #000000;
        font-size: 24px;
}
h3 {
        font-size: 18px;
}
h4 {
        font-size: 16px;
}
h5 {
        font-size: 14px;
}
h6 {
        color: #777777;
        background-color: inherit;
        font-size: 14px;
}
hr {
        height: 0.2em;
        border: 0;
        color: #CCCCCC;
        background-color: #CCCCCC;
display: inherit;
}
p, blockquote, ul, ol, dl, li, table, pre {
        margin: 15px 0;
}
a, a:visited {
        color: #4183C4;
        background-color: inherit;
        text-decoration: none;
}
#message {
        border-radius: 6px;
        border: 1px solid #ccc;
        display:block;
        width:100%;
        height:60px;
        margin:6px 0px;
}
button, #ws {
        font-size: 12 pt;
        padding: 4px 6px;
        border-radius: 5px;
        border: 1px solid #bbb;
        background-color: #eee;
}
code, pre, #ws, #message {
        font-family: Monaco;
        font-size: 10pt;
        border-radius: 3px;
        background-color: #F8F8F8;
        color: inherit;
}
code {
        border: 1px solid #EAEAEA;
        margin: 0 2px;
        padding: 0 5px;
}
pre {
        border: 1px solid #CCCCCC;
        overflow: auto;
        padding: 4px 8px;
}
pre > code {
        border: 0;
        margin: 0;
        padding: 0;
}
#ws { background-color: #f8f8f8; }
.bloop_markdown table {
border-collapse: collapse;
font-family: Helvetica, arial, freesans, clean, sans-serif;
color: rgb(51, 51, 51);
font-size: 15px; line-height: 25px;
padding: 0; }
.bloop_markdown table tr {
border-top: 1px solid #cccccc;
background-color: white;
margin: 0;
padding: 0; }
.bloop_markdown table tr:nth-child(2n) {
background-color: #f8f8f8; }
.bloop_markdown table tr th {
font-weight: bold;
border: 1px solid #cccccc;
margin: 0;
padding: 6px 13px; }
.bloop_markdown table tr td {
border: 1px solid #cccccc;
margin: 0;
padding: 6px 13px; }
.bloop_markdown table tr th :first-child, table tr td :first-child {
margin-top: 0; }
.bloop_markdown table tr th :last-child, table tr td :last-child {
margin-bottom: 0; }
.bloop_markdown blockquote{
border-left: 4px solid #dddddd;
padding: 0 15px;
color: #777777; }
blockquote > :first-child {
margin-top: 0; }
blockquote > :last-child {
margin-bottom: 0; }
code, pre, #ws, #message {
word-break: normal;
word-wrap: normal;
}
hr {
display: inherit;
}
.bloop_markdown :first-child {
-webkit-margin-before: 0;
}
code, pre, #ws, #message {
font-family: Menlo, Consolas, Liberation Mono, Courier, monospace;
}
.send { color:#77bb77; }
.server { color:#7799bb; }
.error { color:#AA0000; }</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="bloop_markdown"><p>Ahh that does clear things up a bit, however I was thinking of building something a bit differently and was hoping for your thoughts on it.</p>
<p>I want the AuthServer, backed by LDAP, to understand the mapping of LDAP filters to ROLEs for each client. On the “Edit Client” screen, there would be a new tab: Roles. Administrators for an app would list all the roles and a series of LDAP filters that grant those roles:</p>
<ul>
<li>ROLE_ADMIN = (uid=bob_the_admin)</li>
<li>ROLE_USER = (guid=pa_users)(uid=bob_the_admin)</li>
<li>ROLE_EMAILER = (uid=bob_the_admin)</li>
</ul>
<p>The AuthServer would perform that mapping and return the set of roles the user is authorized for. Then, the client app can just look at the token to see what roles are valid. </p>
<p>This role info would presumably be encoded into the JWT id token. When the client gets the id token from the authorization, it stores it in the user session. Every time a request is made from the end user, you look up the id token and extract the set of roles.</p>
<p>The benefit with this approach, is you centralize the mapping of users to roles. So for folks deploying the application, rather than editing some Spring config file, they can use a UI to administer. I’m not asking for this change to be incorporated into your project, but does this seem like a good idea with regards to OpenID Connect architecture? </p>
<p></p></div><div class="bloop_original_html"><style>body{font-family:Helvetica,Arial;font-size:13px}</style><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div> <br> <div id="bloop_sign_1437664954775682816" class="bloop_sign"><div style="font-family:helvetica,arial;font-size:13px"><br></div></div> <br><p class="airmail_on" style="color:#000;">On July 23, 2015 at 3:20:27 AM, Justin Richer (<a href="mailto:jricher@mit.edu">jricher@mit.edu</a>) wrote:</p> <blockquote type="cite" class="clean_bq"><span><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div></div><div>
<title></title>
The roles between both of those servers are not connected in any
way. An account on the IdP could have ROLE_ADMIN there but not have
ROLE_ADMIN on the client (simple-web-app is the demo client
application). Think of it this way: you could use this client with
a non-spring-based IdP that has no notion of what ROLE_ADMIN or
ROLE_USER are. The roles that those accounts might have in the
server, if they even exist, have no bearing on the client.
<div class=""><br class=""></div>
<div class="">It’s up to the AuthenticationProvider in the client
code to determine which users get which roles locally. This is
configured in the current branch using the OIDCAuthoritiesMapper
plugin component, which we provide a simple implementation that
lets you name your users who get ROLE_ADMIN by their iss/sub pairs:
<div class=""><br class=""></div>
<div class=""><a href="https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server/blob/master/openid-connect-client/src/main/java/org/mitre/openid/connect/client/NamedAdminAuthoritiesMapper.java" class="">https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server/blob/master/openid-connect-client/src/main/java/org/mitre/openid/connect/client/NamedAdminAuthoritiesMapper.java</a></div>
<div class=""><br class=""></div>
<div class="">If you look in this code, you can see that this
service gets handed the incoming ID Token and the user info object.
A custom implementation can map that information onto whatever
local ROLE_ values that it wants, regardless of the server’s setup.
Thus, it’s up to you whether you’d like to map your client’s
ROLE_ADMIN users by their identities (iss/sub pairs) or by other
attributes that you fetch from the server.</div>
<div class=""><br class=""></div>
<div class=""> — Justin<br class="">
<div>
<blockquote type="cite" class="">
<div class="">On Jul 22, 2015, at 7:55 PM, Matt Hughes <<a href="mailto:hughes.matt@gmail.com" class="">hughes.matt@gmail.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<div class="bloop_markdown">
<p class="">I’m running both the
OpenID-Connect-Java-Spring-Server/openid-connect-server-webapp and
the OpenID-Connect-Java-Spring-Server/sample-webapp projects.</p>
<p class="">Sample Webapp defines resources that are protected by
either ROLE_USER or ROLE_ADMIN. In the connect server (IDP), user
roles are stored in the database. I’m having a hard time figuring
out how, once the sample webapp has the access_token, it knows what
roles the users has. Is it able to extract that information out of
the access_token? Or does it make a web request to the IDP asking
for role info?</p>
<p class="">My next step is to try to use an LDAP server as the
IDP. However, looking at the sample LDAP project, I don’t
understand how roles fit into the picture there. Once a user is
authenticated against an LDAP provider, how would the IDP or RP map
roles onto the user?</p>
<div class=""><br class="webkit-block-placeholder"></div>
</div>
<div class="bloop_original_html">
<div id="bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; margin: 0px;" class=""><br class=""></div>
<div class="bloop_container">
<div class="bloop_frame"></div>
</div>
<br class="">
<div id="bloop_sign_1437587336505021952" class="bloop_sign">
<div style="font-family:helvetica,arial;font-size:13px" class="">
<br class=""></div>
</div>
</div>
<div class="bloop_markdown">
<div class=""><br class="webkit-block-placeholder"></div>
</div>
</div>
_______________________________________________<br class="">
mitreid-connect mailing list<br class="">
<a href="mailto:mitreid-connect@mit.edu" class="">mitreid-connect@mit.edu</a><br class="">
http://mailman.mit.edu/mailman/listinfo/mitreid-connect<br class=""></div>
</blockquote>
</div>
<br class=""></div>
</div>
</div></div></span></blockquote></div><div class="bloop_markdown"><p></p></div></body></html>