keycloak-scim/topics/identity-broker/first-login-flow.adoc

64 lines
5.2 KiB
Text
Raw Normal View History

2016-05-26 16:09:04 +00:00
[[_identity_broker_first_login]]
=== First Login Flow
2016-05-27 15:23:34 +00:00
When a user logs in through identity brokering some aspects of the user are imported and linked within the realm's local database.
When {{book.project.name}} successfully authenticates users through an external identity provider
there can be two situations:
* There is already a {{book.project.name}} user account imported and linked with the authenticated identity provider account.
In this case, {{book.project.name}} will just authenticate as the existing user and redirect back to application.
* There is not yet an existing {{book.project.name}} user account imported and linked for this external user.
Usually you just want to register and import the new account into {{book.project.name}} database, but what if there is an existing
2016-05-27 15:23:34 +00:00
{{book.project.name}} account with the same email? Automatically linking the existing local account to the external
identity provider is a potential security hole as you can't always trust the information you get from the external identity provider.
Different organizations have different requirements when dealing with some of the conflicts and situations listed above.
For this, there is a `First Login Flow` option in the IDP settings which allows you to choose a <<fake/../../authentication/flows.adoc#_authentication-flows, workflow>> that will be
used after a user logs in from an external IDP the first time.
By default it points to `first broker login` flow, but you can configure and use your own flow and use different flows for different identity providers.
2016-05-26 16:09:04 +00:00
The flow itself is configured in admin console under `Authentication` tab.
When you choose `First Broker Login` flow, you will see what authenticators are used by default.
You can re-configure the existing flow. (For example you can disable some authenticators, mark some of them as `required`, configure some authenticators, etc).
Or you can even create a new authentication flow and/or write your own Authenticator implementations and use it in your flow.
See link:{{book.developerguide.link}}[{{book.developerguide.name}}] for more details.
2016-05-26 16:09:04 +00:00
==== Default First Login Flow
Let's describe the default behaviour provided by `First Broker Login` flow.
Review Profile::
This authenticator might display the profile info page, where the user can review his profile retrieved from an identity provider.
2016-05-26 16:09:04 +00:00
The authenticator is configurable.
You can set the `Update Profile On First Login` option.
2016-05-26 16:09:04 +00:00
When `On`, users will be always presented with the profile page asking for additional information in order to federate their identities.
When `missing`, users will be presented with the profile page only if some mandatory information (email, first name, last name) is not provided by the identity provider.
2016-05-27 15:23:34 +00:00
If `Off`, the profile page won't be displayed, unless user clicks in later phase on `Review profile info` link (page displayed in later phase
by `Confirm Link Existing Account` authenticator)
2016-05-26 16:09:04 +00:00
Create User If Unique::
This authenticator checks if there is already an existing {{book.project.name}} account with same email or username like the account from the identity provider.
If it's not, then the authenticator just creates a new local {{book.project.name}} account and links it with the identity provider and the whole flow is finished.
2016-05-26 16:09:04 +00:00
Otherwise it goes to the next `Handle Existing Account` subflow.
2016-05-27 15:23:34 +00:00
If you always want to ensure that there is no duplicated account, you can mark this authenticator as `REQUIRED` . In this case, the user
will see the error page if there is existing {{book.project.name}} account and the user will need to link his identity provider account through Account management.
2016-05-26 16:09:04 +00:00
Confirm Link Existing Account::
2016-05-27 15:23:34 +00:00
On the info page, the user will see that there is an existing {{book.project.name}} account with same email.
He can review his profile again and use different email or username (flow is restarted and goes back to `Review Profile` authenticator).
2016-05-27 15:23:34 +00:00
Or he can confirm that he wants to link the identity provider account with his existing {{book.project.name}} account.
2016-05-26 16:09:04 +00:00
Disable this authenticator if you don't want users to see this confirmation page, but go straight to linking identity provider account by email verification or re-authentication.
Verify Existing Account By Email::
2016-05-27 15:23:34 +00:00
This authenticator is `ALTERNATIVE` by default, so it's used only if the realm has SMTP setup configured.
It will send mail to the user, where he can confirm that he wants to link the identity provider with his {{book.project.name}} account.
2016-05-26 16:09:04 +00:00
Disable this if you don't want to confirm linking by email, but instead you always want users to reauthenticate with their password (and alternatively OTP).
Verify Existing Account By Re-authentication::
This authenticator is used if email authenticator is disabled or non-available (SMTP not configured for realm). It will display a login screen
where the user needs to authenticate with his password to link his {{book.project.name}} account with the Identity provider.
2016-05-27 15:23:34 +00:00
User can also re-authenticate with some different identity provider, which is already linked to his {{book.project.name}} account.
You can also force users to use OTP. Otherwise it's optional and used only if OTP is already set for the user account.
2016-05-26 16:09:04 +00:00