Hello,
I'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're considering.

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.

To help explain what I'm trying to achieve I've created two small diagrams:

1. https://drive.google.com/file/d/0B9Ye3fFQSfx-YWUtcEF2Z0MxSjA/view

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
central process to handle authentication, sso and identity resolution by some process it doesn't need to care about. In our case this would be mostly by authentication against and identity transfer from
multiple SAML 2.x IdP (Shibboleth) from which we'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
to the service instance the end user was attempting to access.

End users would have the ability to:
  • Approve release of identity information to a service group (approval would apply to all service instances within a group);
  • Review all identity information which is held about them centrally and update if required;
  • View a list of previous release approvals across all service groups (and revoke if desired);
  • Undertake a range of standard session based actions, such as revoking currently active tokens, determining where active sessions are held etc.

2. https://drive.google.com/file/d/0B9Ye3fFQSfx-amJZVGF5QWZwdmM/view

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
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
release it applies to all service instances within the owning realm.

From here though I believe the following differences are present:
  • Each realm duplicates identity data for every user who authenticates to a service within that realm
    • If user identity changes in the master realm those changes are not reflected in all service facing realms
    • Any augmentation of identity, such as role membership, is per realm
  • Users can only manage identity information, release approvals etc per realm
  • Session based actions are only per realm
Based on the above descriptions, any help the community could offer to align my design goals with functionality present Keycloak would be fantastic.

cheers,
Bradley

--
Bradley Beddoes
Australian Access Federation Inc