Social Identity Providers - dcm4che/dcm4chee-arc-light GitHub Wiki

Secure Archive with Keycloak and configure one or more Identity Providers

• Google as Identity Provider
• Github as Identity Provider

1. Create Mapper(s) to assign roles to the users, authenticating themselves via Social Identity Provider, to access and/or have modification rights on the archive. Go to the Mappers tab of the created Identity Providers in Keycloak and Create.
2. Select Hardcoded Role from Mapper Type dropdown.
3. For the Role field Select Role as user. Enter Name for your mapper and Save.
4. (Optional, not recommended) If you want users authenticated via Identity Providers to also have admin rights, create a second mapper and repeat steps 2 and 3, except Select Role as admin.
5. Alternatively (recommended), if you want certain specific users logged in with Identity Providers to have admin rights, then logon to Keycloak admin console using one of the existing users have administration rights and manually map the admin role to those users.

By default, when a user logs in using a Social Identity Provider, if the user did not have the First/Last name fields set in their profile with the Social Identity Provider, Keycloak displays an Update Account Information page. This page shows the fields Username, Email, First Name, and Last Name. On updating these fields, user can proceed to the archive UI page.

If one wants to disable this Update Profile, login to Keycloak admin console and go to Authentication -> Flows -> First Broker Login -> Review Profile(review profile config) -> Actions (Config) -> Update Profile on First Login -> OFF and Save.

By default, when a user logs in with a Social Identity Provider for the first time, Keycloak checks in its database and creates a unique user for it. On subsequent logins, Keycloak links the user ID to the user logged in with Social Identity Provider. Once logged in to archive UI, any user (including users logged in with Social Identity Provider) have an option to Edit Account in Keycloak. This also allows them to update their passwords. In case of the user that logged in with Social Identity Provider, Keycloak has no password stored for this user in its database (or LDAP, if User Federation is configured). This implies that a user logged in with Social Identity Provider to archive UI can't update their password as there is no previous existing password for this user.

To enable users logging in via Social Identity Providers to update their password, login to Keycloak admin console and go to Authentication -> Flows -> First Broker Login -> Create User If Unique(create unique user config) -> Actions (Config) -> Require Password Update After Registration -> ON and Save.

By doing this, not only can the users logged in with Social Identity Providers update their passwords using Edit Account from Archive UI, but also allows them to directly login with their email ID and this password (available now in Keycloak db or LDAP), without having the need to authenticate via Social Identity Provider), on subsequent logins to archive UI.

Access archive UI and use a Social Identity Provider for login.

Note : If a user has already logged in once with an email ID registered with a particular Social Identity Provider and then chooses to login with another Social Identity Provider with same email ID, then Keycloak displays an Account already exists page with options to Review Profile or Add to existing account. By continuing with :

• Add to existing account option and if Update Password on First Logon was configured, then user can directly login with the password used on updating password on first logon with first Social Identity Provider. Doing this, links the second Social Identity Provider with this user in Keycloak. Verify this linking of Social Identity Providers by logging in to Keycloak admin console and go to Identity Provider Links of a particular user logged with a Social Identity Provider.
• Review Profile option, Keycloak displays the Update Account Information page. This option is not of help as Keycloak doesn't accept the request even on an update of the fields, since the email ID remains the same and is used to identify with the user in Keycloak.