9:56 a.m.
Hi folks,
I’ve been looking for an IdP solution for my employer for months and
have felt like I’ve been going round and round in circles, until I
finally gave Keycloak another try. It’s like a breath of fresh air! So
thanks folks.
Our Keycloak instance will be used to protect about a dozen
applications, things like our wiki, monitoring control panel, and so on.
We’ll have two different types of users who will need to use the IdP and
login to these applications: staff and partners.
Staff will need to login using LDAP federation and will be required to
use TOTP. They should not be able to use social providers to log in.
Staff will use their email address to login and all will use a single
RHS domain for their email addresses.
Partners will not have LDAP accounts, and should be able to opt-in to
use TOTP. They should ideally also be able to link social accounts (e.g.
Google or GitHub) to their existing records. Anyone not using our
corporate email domain, but who has an account, should be considered a
partner.
Some of our applications can only be configured with a single OIDC or
SAML provider, so Keycloak would need to handle both types of accounts
(e.g. staff / partner) from a single login interface.
I therefore have a few questions about how I might achieve such a setup:
- Can I make these two types of user coexist in a single realm, or do I
need to split it up?
- How can I enforce policies such as requiring TOTP for our staff?
- Can I prevent users from changing their email address and name in the
account console while still permitting password and authenticator changes?
Thanks in advance for any suggestions.
Cheers,
Chris
--
Chris Boot
bootc(a)boo.tc
10:54 a.m.
Hi Chris,
Couple of points:
1) > Can I make these two types of user coexist in a single realm, or
do I need to split it up?
-Authentication is on a per realm basis
For authentication you configure a corresponding authentication flow, by
default for the entire realm.
With 4.X and, 5.0, you can override the default authentification flow,
for specific client applications
If you want 2 different ways to authenticate (staff with 2FA,
username/apssword + TOPTP ), and external with 1FA (username/password)
best is to have to different realms, withe one realm for staff an other
for external people
2) > How can I enforce policies such as requiring TOTP for our staff?
You just have to indicate that TOTP is required in the realm staff
suathentication flow
3) > Can I prevent users from changing their email address and name in
the account console while still permitting password and authenticator
changes?
At first glance, there seems no specific tuning for this, unless writing
a specific custom plugin.
Vist also our web site for info about TOTP, and realms:
http://www.janua.fr/tag/technical-blog/
Don't hesitate to come back to us if you need any further help
Regards,
Olivier Rivat
<http://www.janua.fr/images/logo-big-sans.png><http://www.janua.fr/i...
<http://www.janua.fr/images/6g_top.gif>
Olivier Rivat
CTO
orivat(a)janua.fr <mailto:dchikhaoui@janua.fr>
Gsm: +33(0)682 801 609
Tél: +33(0)489 829 238
Fax: +33(0)955 260 370
http://www.janua.fr <http://www.janua.fr/>
<http://www.janua.fr/images/6g_top.gif>
Le 21/03/2019 à 15:56, Chris Boot a écrit :
Hi folks,
I’ve been looking for an IdP solution for my employer for months and
have felt like I’ve been going round and round in circles, until I
finally gave Keycloak another try. It’s like a breath of fresh air! So
thanks folks.
Our Keycloak instance will be used to protect about a dozen
applications, things like our wiki, monitoring control panel, and so on.
We’ll have two different types of users who will need to use the IdP and
login to these applications: staff and partners.
Staff will need to login using LDAP federation and will be required to
use TOTP. They should not be able to use social providers to log in.
Staff will use their email address to login and all will use a single
RHS domain for their email addresses.
Partners will not have LDAP accounts, and should be able to opt-in to
use TOTP. They should ideally also be able to link social accounts (e.g.
Google or GitHub) to their existing records. Anyone not using our
corporate email domain, but who has an account, should be considered a
partner.
Some of our applications can only be configured with a single OIDC or
SAML provider, so Keycloak would need to handle both types of accounts
(e.g. staff / partner) from a single login interface.
I therefore have a few questions about how I might achieve such a setup:
- Can I make these two types of user coexist in a single realm, or do I
need to split it up?
- How can I enforce policies such as requiring TOTP for our staff?
- Can I prevent users from changing their email address and name in the
account console while still permitting password and authenticator changes?
Thanks in advance for any suggestions.
Cheers,
Chris
--
11:14 a.m.
On Thu, Mar 21, 2019 at 4:58 PM Olivier Rivat <orivat(a)janua.fr> wrote:
Hi Chris,
Couple of points:
1) > Can I make these two types of user coexist in a single realm, or
do I need to split it up?
-Authentication is on a per realm basis
For authentication you configure a corresponding authentication flow, by
default for the entire realm.
With 4.X and, 5.0, you can override the default authentification flow,
for specific client applications
If you want 2 different ways to authenticate (staff with 2FA,
username/apssword + TOPTP ), and external with 1FA (username/password)
best is to have to different realms, withe one realm for staff an other
for external people
Unless staff and partner do not access the same clients, in this case you
can override the auth flow as Olivier said before
2) > How can I enforce policies such as requiring TOTP for our staff?
You just have to indicate that TOTP is required in the realm staff
suathentication flow
same remark as in 1)
3) > Can I prevent users from changing their email address and name in
the account console while still permitting password and authenticator
changes?
At first glance, there seems no specific tuning for this, unless writing
a specific custom plugin.
In the "required Actions" of your auth flow, "Update Profile" is
enabled
by default , if you disable it they won't be able to change their profile
but still able to configure OTP and change their password.
Vist also our web site for info about TOTP, and realms:
http://www.janua.fr/tag/technical-blog/
Don't hesitate to come back to us if you need any further help
Regards,
Olivier Rivat
<http://www.janua.fr/images/logo-big-sans.png><
http://www.janua.fr/images/LogoSignature.gif>
<http://www.janua.fr/images/6g_top.gif>
Olivier Rivat
CTO
orivat(a)janua.fr <mailto:dchikhaoui@janua.fr>
Gsm: +33(0)682 801 609
Tél: +33(0)489 829 238
Fax: +33(0)955 260 370
http://www.janua.fr <http://www.janua.fr/>
<http://www.janua.fr/images/6g_top.gif>
Le 21/03/2019 à 15:56, Chris Boot a écrit :
> Hi folks,
>
> I’ve been looking for an IdP solution for my employer for months and
> have felt like I’ve been going round and round in circles, until I
> finally gave Keycloak another try. It’s like a breath of fresh air! So
> thanks folks.
>
> Our Keycloak instance will be used to protect about a dozen
> applications, things like our wiki, monitoring control panel, and so on.
> We’ll have two different types of users who will need to use the IdP and
> login to these applications: staff and partners.
>
> Staff will need to login using LDAP federation and will be required to
> use TOTP. They should not be able to use social providers to log in.
> Staff will use their email address to login and all will use a single
> RHS domain for their email addresses.
>
> Partners will not have LDAP accounts, and should be able to opt-in to
> use TOTP. They should ideally also be able to link social accounts (e.g.
> Google or GitHub) to their existing records. Anyone not using our
> corporate email domain, but who has an account, should be considered a
> partner.
>
> Some of our applications can only be configured with a single OIDC or
> SAML provider, so Keycloak would need to handle both types of accounts
> (e.g. staff / partner) from a single login interface.
>
> I therefore have a few questions about how I might achieve such a setup:
>
> - Can I make these two types of user coexist in a single realm, or do I
> need to split it up?
>
> - How can I enforce policies such as requiring TOTP for our staff?
>
> - Can I prevent users from changing their email address and name in the
> account console while still permitting password and authenticator
changes?
>
> Thanks in advance for any suggestions.
>
> Cheers,
> Chris
>
--
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
8:16 a.m.
Hi Olivier, Sebastien,
First of all sorry for the late response, your replies never made it to
me despite me being subscribed to the list. I only found them when
perusing the online archives.
Could you please CC me on replies?
On 21/03/2019 16:14, sblanc at redhat.com (Sebastien Blanc) wrote:
On Thu, Mar 21, 2019 at 4:58 PM Olivier Rivat <orivat at
janua.fr> wrote:
[snip]
> 1) > Can I make these two types of user coexist in a single
realm, or
> do I need to split it up?
>
> -Authentication is on a per realm basis
> For authentication you configure a corresponding authentication flow, by
> default for the entire realm.
>
> With 4.X and, 5.0, you can override the default authentification flow,
> for specific client applications
>
> If you want 2 different ways to authenticate (staff with 2FA,
> username/apssword + TOPTP ), and external with 1FA (username/password)
> best is to have to different realms, withe one realm for staff an other
> for external people
>
Unless staff and partner do not access the same clients, in this case you
can override the auth flow as Olivier said before
Most of our apps will need logins from both types of user; a minority
will only accept logins from staff. Overriding the auth flow per client
doesn't seem like it will work for us. It looks like two realms is the
way to do this, then, which should be fine.
Now, bearing in mind that some of our applications can only authenticate
against one provider at a time, would you recommend having the
"partners" realm broker to the "staff" realm? Or would it be better
to
have a third realm used only for such applications which then brokers to
both the "partners" and "staff" realms?
> 3) > Can I prevent users from changing their email address and
name in
> the account console while still permitting password and authenticator
> changes?
> At first glance, there seems no specific tuning for this, unless writing
> a specific custom plugin.
> In the "required Actions" of your auth flow, "Update Profile" is
enabled
> by default , if you disable it they won't be able to change their profile
> but still able to configure OTP and change their password.
I'll have to try this, thanks. Failing that, Stan's suggestions of
hacking the HTML in the account theme might be good enough for our purposes.
Thanks,
Chris
--
Chris Boot
bootc(a)boo.tc
11:33 a.m.
On 3/21/2019 11:54 AM, Olivier Rivat wrote:
Hi Chris,
Couple of points:
1) > Can I make these two types of user coexist in a single realm, or
do I need to split it up?
-Authentication is on a per realm basis
For authentication you configure a corresponding authentication flow, by
default for the entire realm.
With 4.X and, 5.0, you can override the default authentification flow,
for specific client applications
If you want 2 different ways to authenticate (staff with 2FA,
username/apssword + TOPTP ), and external with 1FA (username/password)
best is to have to different realms, withe one realm for staff an other
for external people
2) > How can I enforce policies such as requiring TOTP for our staff?
You just have to indicate that TOTP is required in the realm staff
suathentication flow
3) > Can I prevent users from changing their email address and name in
the account console while still permitting password and authenticator
changes?
At first glance, there seems no specific tuning for this, unless writing
a specific custom plugin.
Vist also our web site for info about TOTP, and realms:
http://www.janua.fr/tag/technical-blog/
Don't hesitate to come back to us if you need any further help
Regards,
Olivier Rivat
<http://www.janua.fr/images/logo-big-sans.png><http://www.janua.fr/i...
<http://www.janua.fr/images/6g_top.gif>
Olivier Rivat
CTO
orivat(a)janua.fr <mailto:dchikhaoui@janua.fr>
Gsm: +33(0)682 801 609
Tél: +33(0)489 829 238
Fax: +33(0)955 260 370
http://www.janua.fr <http://www.janua.fr/>
<http://www.janua.fr/images/6g_top.gif>
Le 21/03/2019 à 15:56, Chris Boot a écrit :
> Hi folks,
>
> I’ve been looking for an IdP solution for my employer for months and
> have felt like I’ve been going round and round in circles, until I
> finally gave Keycloak another try. It’s like a breath of fresh air! So
> thanks folks.
>
> Our Keycloak instance will be used to protect about a dozen
> applications, things like our wiki, monitoring control panel, and so on.
> We’ll have two different types of users who will need to use the IdP and
> login to these applications: staff and partners.
>
> Staff will need to login using LDAP federation and will be required to
> use TOTP. They should not be able to use social providers to log in.
> Staff will use their email address to login and all will use a single
> RHS domain for their email addresses.
>
> Partners will not have LDAP accounts, and should be able to opt-in to
> use TOTP. They should ideally also be able to link social accounts (e.g.
> Google or GitHub) to their existing records. Anyone not using our
> corporate email domain, but who has an account, should be considered a
> partner.
>
> Some of our applications can only be configured with a single OIDC or
> SAML provider, so Keycloak would need to handle both types of accounts
> (e.g. staff / partner) from a single login interface.
>
> I therefore have a few questions about how I might achieve such a setup:
>
> - Can I make these two types of user coexist in a single realm, or do I
> need to split it up?
>
> - How can I enforce policies such as requiring TOTP for our staff?
>
> - Can I prevent users from changing their email address and name in the
> account console while still permitting password and authenticator changes?
You
can make the email field readonly by changing the HTML in the
account theme. This does not prevent someone from manually sending a
post to the server that would change it, but it might be enough for your
purposes.
>
> Thanks in advance for any suggestions.
>
> Cheers,
> Chris
>
--
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
1869
days inactive
1873
days old
4 comments
4 participants
participants (4)
-
Chris Boot -
Olivier Rivat -
Sebastien Blanc -
Stan Silvert