<div dir="ltr">Hello,<br><div class="gmail_quote"><div dir="ltr"><div><div><div><div>I&#39;ve been evaluating Keycloak 2 releases recently (documentation and local deployment) to determine if Keycloak might be a suitable fit for a future project we&#39;re considering.<br><br></div>A lot of the moving parts we require are present but I see a few incompatibilities when it comes to the model we need vs my interpretation of Keycloak functionality. <br></div><div><br></div>To help explain what I&#39;m trying to achieve I&#39;ve created two small diagrams:<br><br>1. <a href="https://drive.google.com/file/d/0B9Ye3fFQSfx-YWUtcEF2Z0MxSjA/view" target="_blank">https://drive.google.com/file/d/0B9Ye3fFQSfx-YWUtcEF2Z0MxSjA/view</a><br><br></div>This is the overall goal. On the far right 1 or more OIDC or SAML service instances are grouped together and overseen by 1 or more local administrators. Each group then relies on some<br></div><div>central process to handle authentication, sso and identity resolution by some process it doesn&#39;t need to care about. In our case this would be mostly by authentication against and identity transfer from <br>multiple SAML 2.x IdP (Shibboleth) from which we&#39;d locally store/update/augment as a single cache of identity data. Groups would have the ability to translate/augment identity data before returning it back<br></div><div>to the service instance the end user was attempting to access. <br><br>End users would have the ability to:<br><ul><li>Approve release of identity information to a service group (approval would apply to all service instances within a group);<br></li><li>Review all identity information which is held about them centrally and update if required;<br></li><li>View a list of previous release approvals across all service groups (and revoke if desired);</li><li>Undertake a range of standard session based actions, such as revoking currently active tokens, determining where active sessions are held etc.</li></ul><p>2. <a href="https://drive.google.com/file/d/0B9Ye3fFQSfx-amJZVGF5QWZwdmM/view" target="_blank">https://drive.google.com/file/d/0B9Ye3fFQSfx-amJZVGF5QWZwdmM/view</a></p>This is my interpretation of Keycloak functionality. OIDC and SAML service instances belong to realms and administrators are assigned to a realm. Each realm can be configured to offload authentication<br>and identity resolution to a central realm which can be configured to talk to 1 or more SAML 2.x IdP. This realm will cache identity data locally. When an end user approves identity<br></div><div>release it applies to all service instances within the owning realm.<br></div><div><br>From here though I believe the following differences are present:<br></div><div><ul><li>Each realm duplicates identity data for every user who authenticates to a service within that realm<br></li><ul><li>If user identity changes in the master realm those changes are not reflected in all service facing realms<br></li><li>Any augmentation of identity, such as role membership, is per realm<br></li></ul><li>Users can only manage identity information, release approvals etc per realm</li><li>Session based actions are only per realm<br></li></ul><div><div><div>Based on the above descriptions, any help the community could offer to align my design goals with functionality present Keycloak would be fantastic.<br></div><div><br></div><div>cheers,<br></div><div>Bradley<span class="HOEnZb"><font color="#888888"><br></font></span></div><span class="HOEnZb"><font color="#888888"><div><br>-- <br><div data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><font face="arial, helvetica, sans-serif"><b><span style="font-size:9pt;color:rgb(227,108,10)">Bradley Beddoes</span></b></font><br><font face="arial, helvetica, sans-serif"><font color="#666666"><span style="font-size:8.5pt"></span></font></font><div dir="ltr"><div style="font-size:11pt;margin:0cm 0cm 0.0001pt"><font face="arial, helvetica, sans-serif"><font color="#666666"><span style="font-size:8.5pt"><b>Australian Access Federation Inc</b></span></font></font><span style="text-align:-webkit-auto"></span><span style="font-family:arial,helvetica,sans-serif"></span></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>
</div></font></span></div></div></div></div>
</div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><span style="text-align:-webkit-auto"></span><span style="font-family:arial,helvetica,sans-serif"></span></div></div></div></div></div></div></div></div></div></div></div></div></div>
</div>