<html><body><div style="font-family: Arial; font-size: 12pt; color: #000000"><div>I was thinking about roles like user groups in a file system, which may not be the correct use of roles, but in any case syncing from the app to KeyCloak is a better solution.<br></div><div><br></div><div><span name="x"></span><div>Regards<br></div><div><br></div><div>Matthew Casperson<br><a data-mce-href="https://www.redhat.com/wapps/training/certification/verify.html?certNumber=111-072-237&isSearch=False&verify=Verify" href="https://www.redhat.com/wapps/training/certification/verify.html?certNumber=111-072-237&isSearch=False&verify=Verify">RHCE, RHCJA # 111-072-237</a><br>Engineering Content Services<br>Brisbane, Australia</div><span name="x"></span><br></div><hr id="zwchr"><div style="color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;" data-mce-style="color: #000; font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><b>From: </b>ssilvert@redhat.com<br><b>To: </b>keycloak-dev@lists.jboss.org<br><b>Sent: </b>Tuesday, 10 December, 2013 4:07:52 AM<br><b>Subject: </b>Re: [keycloak-dev] Can a master list of roles be retrieved?<br><div><br></div>On 12/9/2013 8:50 AM, Bill Burke wrote:<br>> I don't know why you'd want to sync with any master list, but you could. <br>> The Keycloak Admin REST interface is itself an application with roles <br>> assign to it. Each application is itself a User. So you'd just assign <br>> a Admin API role and the application could query for anything it wanted <br>> (based on its permissions).<br>><br>> Most applications will inheritantly know which roles they require. Role <br>> mappings are contained within the token they receive from the <br>> auth-server. They idea is that security-wise, applications become <br>> stateless. This is especially important for REST services that aim to <br>> be completely stateless.<br>I'd go even further. I think an application will ALWAYS know which<br>roles it requires. I just can't think of a time where that is not true<br>except for the degenerate case where the application is built without<br>any roles at all.<br><div><br></div>The example of selecting which roles should edit a particular record<br>doesn't make sense to me. Keycloak wouldn't define that because<br>Keycloak doesn't understand what those records are used for. The<br>application has to define those roles because the application<br>understands the context.<br><div><br></div>It seems to me that any sync that must be done should actually go the<br>other direction. A Keycloak subsystem (which I'm starting on today),<br>should attempt to find out which roles are declared in the application<br>and then let Keycloak know about them at deploy time.<br>><br>> On 12/8/2013 4:44 PM, Matt Casperson wrote:<br>>> If I wanted my client application's UI to be able to authorise roles to<br>>> perform certain actions, could I query a KeyCloak server for the master<br>>> list?<br>>><br>>> An example might be listing all the roles so I could select those that<br>>> should be able to edit a particular record. So rather than manually<br>>> syncing a list of roles between my application and KeyCloak, I would<br>>> query the KeyCloak server for the current list of roles to ensure that I<br>>> always have an accurate list.<br>>><br>>> Regards<br>>><br>>> Matthew Casperson<br>>> RHCE, RHCJA # 111-072-237<br>>> <https://www.redhat.com/wapps/training/certification/verify.html?certNumber=111-072-237&isSearch=False&verify=Verify><br>>> Engineering Content Services<br>>> Brisbane, Australia<br>>><br>>><br>>><br>>> _______________________________________________<br>>> keycloak-dev mailing list<br>>> keycloak-dev@lists.jboss.org<br>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev<br>>><br><div><br></div>_______________________________________________<br>keycloak-dev mailing list<br>keycloak-dev@lists.jboss.org<br>https://lists.jboss.org/mailman/listinfo/keycloak-dev<br></div><div><br></div></div></body></html>