<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;"><div>I’m very glad about the discussion here about roles and groups, since granting access to user is the core of access management.</div><div>This said, we had been forced to look forward the group object 8or a similar role object) to managing access entitlements because these run out of gas at about 100.000 users and we are targeting millions of users.</div><div>We had even to go further on the „role“: the current definition describe an entitlement just with the name of a role (or a group) and we needed something more.</div><div><br></div><div>At the end we come up with a simple concept.</div><div><br></div><ol><li>the Roles are modeled by an attribute in the user object itself. Of course the Attribute is multivalued. This gives us the capability to retrieve all the needed information with a single LDAP operation. No more group search, cascading groups: which are cumbersome and time consuming.</li><li>This Attribute contains a structured value of the type: <realm><client><role><parameter>. WE are playing with the idea to store this in a son structure. In the future, given the sensitivity of the access, we may think to have this signed (like in a JWT), to ensure reliability of the information.</li><li>A separate identity management system will take care of the management of this attribute, AMS has only the task to pass over the values to the application.</li></ol><div><br></div><div>We are going to implement that with our resources, extending KeyCloak where needed, but I would like to share this ideas to have an open discussion on this. </div><div>Further it would be nice to see some aspects of this implemented in KeyCloak. We may decide to share the code.</div><div><br></div><div>Regards,</div><div>Giovanni</div><div> </div><br></body></html>