Actually, my internal keycloak users use only a login for authentication
but I suppose it is possible to ask for the internal keycloak email first.
I think in my use case, a simple choice list for using a federation and the
login/password on the left is great. Storing the latest used IdP in a
cookie will increase the user experience for federated users.
Your flow is great also but in my case I don't know the proportion of
internal users and federated users... so I think keeping a visible
login/password box is not a big deal for now.
This system will be in production end of year so we'll have feedback at
this time. We also have some existing users that will be migrated as
internal user keycloak.
Le mer. 21 oct. 2015 à 09:13, Stian Thorgersen <sthorger(a)redhat.com> a
écrit :
One flow that I've considered would be:
1. Ask for email only
2. Lookup user, if user is found and has link to IdP redirect directly to
IdP
3. Go through list of IdPs - each IdP would have a email domain associated
with it. If one matches the provided email redirect to IdP
4. If neither 2 or 3 matches then display ask for password. As we know the
user know we can also ask for OTP on the same page if user has OTP enabled
Is that a flow that would work for you?
On 21 October 2015 at 09:06, Jérôme Blanchard <jayblanc(a)gmail.com> wrote:
> Hi Stian,
>
> Thanks a lot for your precisions which will help me a lot. I have already
> develop a theme in an earlier version and I had completely forgot that it
> would do the trick, great idea.
> I will also investigate the idea of implementing an authenticator in
> order to add a cookie remembering the last used IdP because I also need the
> classic login for some users.
>
> Best Regards, Jérôme.
>
> Le mer. 21 oct. 2015 à 08:34, Stian Thorgersen <sthorger(a)redhat.com> a
> écrit :
>
>> There's no limit with the buttons, although it would become unusable.
>> You can change this by creating your own theme though and use a drop down
>> or whatever you'd like.
>>
>> Another idea is something we've discussed before which is to register
>> certain email domains with a specific IdP. For example <user>(a)corp.com
>> is automatically redirected to
idp.corp.com. With the new authenticator
>> SPI you could create this flow yourself and remove the password field from
>> the initial screen.
>>
>> You may end up wanting to implement an authenticator for this in either
>> case so you can add a cookie to remember the last used IdP.
>>
>> When you use identity brokering in Keycloak, Keycloak becomes the
>> "Service Provider" in the external IdP, not the individual clients. So
only
>> the Keycloak server has to be registered with the external IdP.
>>
>> On 20 October 2015 at 17:33, Jérôme Blanchard <jayblanc(a)gmail.com>
>> wrote:
>>
>>> Hi all,
>>>
>>> I'm trying to integrate keycloak in a federation of indentities
>>> (shibolleth) using the SAMLv2 Identity Provider. The problem is that the
>>> federation count something like 100 Identity Providers and I'm afraid of
>>> the L&F of the GUI as for now, adding 3 of them is creating a button for
>>> each. Is there is a limit or something that creates a drop down menu ?
>>> (like this list
https://discovery.renater.fr/renater)
>>>
<
https://discovery.renater.fr/renater/?entityID=https%3A%2F%2Fsaga.renater...
>>> The goal for me is to create a kind of parser for this idps list :
>>>
http://federation.renater.fr/renater/idps-renater-metadata.xml
>>> in order to parse this list and maintain my IDPs in keycloak up to date.
>>>
>>> Another question is : is each client in keycloak has to be declared as
>>> a Service Provider or only the keycloak server ?
>>>
>>> If you have any feedback for shibolleth federation integration using
>>> keycloak I'll be very glad to share them.
>>>
>>> Thanks a lot, Best Regards, Jérôme.
>>>
>>> _______________________________________________
>>> keycloak-user mailing list
>>> keycloak-user(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>>
>>