SSO

In addition to giving the users the option to log in with a username and a password, it is also possible to log in via Single Sign-On (SSO). However, a single user must be configured to either log in with a username and a password or to log in via SSO.


If the property "Enable Single-Sign-On" (in the lower part of the user settings. See screenshot below) of a user is disabled, the user can log in in via username/password. If the property is enabled, the user can log in via SSO:


NG remembers the Identity provider (IdP) used for the first successful login of a SSO user. This way, we ensure that a user cannot login via multiple identity providers.


The name (see arrow in the next screenshot) of a SSO user must be identical to the preferred username configured at the IdP.



Identity providers (IdPs) for the SSO users can be created and configured here:



If you are using Azure AD, the issuer URI often ends with a suffix like "/v2.0" . With Azure AD SSO will not work without this appended version number.


Please be aware that clicking the checkmark (see screenshot below) will write your changes to NG's configuration immediately:



The display name of a configured identity provider will be shown on the login page. In our example: to log in via the IdP with the display name "Microsoft" click on "LOG IN VIA MICROSOFT":



The “LOG in via ...” button will only be displayed for IdPs which are fully configured. Each fully configured IdP will display a log-in button on the login page.


If you want to log in with a username and a password, click instead "Log in with credentials". This will bring you to this screen:




Requirements regarding the configuration on the IdP side:

  • The redirect URI is an important setting on the IdP side, and it’s required for the communication with FF. It defines where the user should be redirected to, after a successful authentication. For NG, this will be the root URL of the UI, appended with the query parameter idp=<providerKey>. The providerKey is a required setting for every identity provider configured on FF side. So for example https://[your-ng-server-url-here].de/fact-finder-ui/?idp=keycloak  (with the correct server-address instead of [your-ng-server-url-here] ) would be a valid redirect URI. It’s important to configure this exact URI at the IdP, otherwise requests to the IdP will be rejected.

  • The provider must be able to answer OIDC Discovery requests.

  • The provider must be able to answer requests with the scopes openid, profile and offline_access.

  • The OIDC claim which is parsed for the sake of user identification is called preferred_username and must be present in the identity tokens or access tokens returned by the IdP.

  • Other required claims which have to be present in identity/access tokens are: sub, iss, iat, exp

  • Tokens must be signed, and the signature must be verifiable with the corresponding public key which is returned by the JWKS endpoint of the IdP.

  • The NG instance must be registered as an app/client with the following settings:
    •  Client ID
    •  Client secret
    •  Redirect URI: The URI to which the browser will be redirected, after a user was successfully authenticated by the IdP.
    •  Also, please adjust the providerKey used in the example redirect URI to one that is specified in one of your screenshots (e.g. customer)


Limitations:

  • Please be aware that SSO users can neither edit nor create non-SSO users. This is forbidden on purpose. This way it is ensured that users who are no longer employees of the company (and are off-boarded at IdP side) don't keep access to NG and cannot find another way to decouple their accounts from the SSO. Therefore it is important to have at least one non-SSO user with admin-rights. Only this kind of user can create all types of users.
  • Converting regular users into SSO users via the checkbox removes the password. As of now, this conversion cannot be reverted.