About Web Login

The Web Login encompasses two things. First, it acts itself as an OpenID Connect (OIDC) Identity Provider (IdP) that other clients can connect to and authenticate. Second, it is itself able to connect to a third-party OpenID Connect or SAML 2.0 Identity Provider and outsource the authentication to that. These two features can be combined; a client can connect to the OIDC IdP exposed by our Security to obtain an OIDC token, while the Security redirects the client to an external SAML or OIDC IdP to perform authentication.

Security as an OIDC Identity Provider

There are currently third-party clients (for example Alexa, Cortana) that use OIDC to log into GENESIS64. ICONICS' clients (GraphWorX64, AnyGlass, UWP) also make use of this OIDC Identity Provider when they are instructed to use the “web login” feature (this is controlled by a check box on the Web Login tab of the Global Settings). Other third parties can also use this feature, but ICONICS' OIDC implementation does not expose all features of the specifications.

ICONICS' implementation of OIDC/OAuth implements these specifications:

The only OIDC Flow that is supported is the ‘Authorization Code’ flow. When setting up OIDC to support Cortana, Alexa or other bots that are supported by GENESIS64, please follow the documentation for the bot support.

Security with an External OIDC or SAML Identity Provider

Security can redirect the user to a 3rd party OIDC or SAML Identity Provider to perform authentication. This process returns a token that identifies the user in some form. There are two requirements that must be met to successfully log in the user into GENESIS64 using this token. First, the token must be mapped to a user that is known beforehand. This means that the list of users must be populated, either manually or by connecting to an Active Directory. Second, it is necessary to configure what information to extract from the security token (this extracted information is called a Claim later) and how to find an existing user based on that. There is more information about the claim extraction in the individual sections for OIDC and SAML, but both provide some common functionality:

  1. The ‘Show list of claims’ hyperlink in Workbench opens a web page that redirects to the external Identity Provider and then lists all the claims that it extracted from the token. To use this link, it is necessary to apply the changes on this Workbench form and wait a second for the server to notice the changes and reconfigure.

  2. The selected claim can be mapped to one of a fixed list of user attributes:

    1. Display Name

    2. Unique Name – for Active Directory, this is the user’s GUID in string form

    3. Active Directory SID – can only be used if the users come from Active Directory

    4. User Lookup Identifier – this is a text field in Workbench that can be filled with an arbitrary unique value.

Changing the URL that Security Listens On and Enabling HTTPS

This URL and protocol (http/https) can be changed through Platform Services Configuration dialog, on the Basic tab in the Web server endpoints section. The table here lists all the URLs that the Security listens on. It is advisable to change the asterisk in the URL to a specific DNS name, as an asterisk here creates security vulnerabilities. Although technically possible, it is not advisable to change the path in the URL from the default ‘/fwxserverweb/’.

The Public Origin field can be used to change how the Security advertises itself. This must contain only the protocol and host part of the URL, without the trailing slash, for example: ‘https://test.example.com’.

There are two use cases for this field:

  1. To advertise to clients that they should use HTTPS instead of HTTP.

  2. To advertise the correct host name. This is especially necessary if running behind a reverse proxy server and cannot be inferred by the Security.

See Also: