Great. We’re getting closer to a solution using two realms.
Esentially,
1. we have a ‘registered users’ realm. Where the prospective students get created.
2. We have an ‘internal’ realm where our LDAP users are. The registered realm is an
IdP for the internal realm. That way our SP’s only need to talk to one realm.
3. If a user registers in the reg realm it creates an id in the internal realm.
4. If / when that user gets an LDAP id created, we get the user to sign in to the
internal realm using their existing ID.
5. They unlink their existing id from their reg realm user.
6. They then sign in using their LDAP ID and link their reg realm ID (we then delete
the original linked id from the internal realm as it is really only a shell / placeholder.
All the attributes the SP sees are coming from the reg realm).
Having the two realms allows:
- The ability to get the user to sign in as two ID’s at the same time for the
purposes of linking / unlinking.
- Persisitance of the original registered id and it’s attributes. This is useful
to manage the user ceasing their role as a student and returning to only use their
registered ID (alumni).
Ideally, we wouldn’t create an id for the registered user in the internal realm at all. It
would be great to be able to just pass their data through from the reg realm and then when
they get an LDAP ID, we can create the link. I believe keeping an IdP authenticated
session in memory only is on the roadmap.
We’re struggling a little bit with what uniqueID to pass through to the SP’s to maintain
the single Id / profile in the SP.
I think this scenario is fairly specific to University environments and probably isn’t
seen much in the corporate world. E.g. Not many users need to transition from customer to
employee and back again.
Any help or advice much appreciated.
Adam
From: Stian Thorgersen [mailto:sthorger@redhat.com]
Sent: Friday, 30 September 2016 4:06 PM
To: Adam Keily <adam.keily(a)adelaide.edu.au>; Bill Burke <bburke(a)redhat.com>
Cc: keycloak-user(a)lists.jboss.org
Subject: Re: [keycloak-user] Realm Config Recommendations
We're currently re-working user federation SPI, but the new SPI should be ready in
2.3. Once it is I think you should be able to do what you want.
Bill - can you take a peak at the original use-case and comment if it's achievable?
It's an interesting use-case.
On 30 September 2016 at 07:53, Adam Keily
<adam.keily@adelaide.edu.au<mailto:adam.keily@adelaide.edu.au>> wrote:
Hi Stian,
Just revisting this. Can you elaborate on “you could use the admin endpoints to link the
KC user to an LDAP user when the student is created in LDAP”
How do you see this working?
Adam
From: Stian Thorgersen [mailto:sthorger@redhat.com<mailto:sthorger@redhat.com>]
Sent: Wednesday, 7 September 2016 10:15 PM
To: Adam Keily
<adam.keily@adelaide.edu.au<mailto:adam.keily@adelaide.edu.au>>
Cc: keycloak-user@lists.jboss.org<mailto:keycloak-user@lists.jboss.org>
Subject: Re: [keycloak-user] Realm Config Recommendations
If you don't mind having prospective students in LDAP as well you can have them
created in LDAP when they register in Keycloak. This applies to users registering with
social IdPs as well. Might even help your onboarding of students as you'd already have
some details filled in.
Otherwise you could use the admin endpoints to link the KC user to an LDAP user when the
student is created in LDAP.
On 30 August 2016 at 06:17, Adam Keily
<adam.keily@adelaide.edu.au<mailto:adam.keily@adelaide.edu.au>> wrote:
Hi,
I’m new to keycloak and we’re investigating using it within our University. In the first
instance it would be used as a registration point for external users e.g. prospective
students etc. They will either register via the form or using social IdP’s in order to
access various apps for these types of users.
We want to remain open to using Keycloak for our internal (AD / LDAP) users to
authenticate to these same apps as well as corporate applications.
The tricky part comes where a prospective student (external identity) enrols and becomes a
regular student (LDAP user). We would like them to continue to be recognised as a single
identity and have their registered identities merged / linked with their new internal
id.
Hoping someone might be able to provide some guidance on the best way to go. There are a
few ideas I’ve been testing.
One is to have a single keycloak realm for user registration and configure LDAP as a user
federation source. However this would seem to rule out linking the accounts?
Another idea was to configure two realms (internal and external) and have the internal
realm act as an IdP for the external realm.
Another option is to create three realms, internal, external and combined. The combined
realm is used for SSO for all apps and the internal and external realms are configured to
be IdP’s for the combined realm. I can’t help but feel this is starting to get more
complicated than is necessary.
Any guidance or thoughts would be much appreciated.
Regards
Adam
--
Adam Keily
Risk & Security Services
The University of Adelaide
_______________________________________________
keycloak-user mailing list
keycloak-user@lists.jboss.org<mailto:keycloak-user@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-user