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*