[keycloak-user] Fwd: functionality questions (Keycloak 2)

Bradley Beddoes bradleybeddoes at aaf.edu.au
Mon Jul 4 00:37:46 EDT 2016


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*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160704/088af180/attachment.html 


More information about the keycloak-user mailing list