Adding identity providers

Before connecting to an identity provider and importing its users, you need to create domain groups for these users and assign respective roles to these groups.

Prerequisites

  • Local domain groups are created, as described in Creating domain groups.
  • The redirection URL (redirect_uri) for the cluster must be https://<url>:8800/api/v2/login/idp/.

To add an identity provider

Admin panel

  1. On the Projects and users screen, click the required domain.
  2. Switch to the Settings > Identity provider screen, and then click Add.
  3. In the Add identity provider window, specify the following parameters:

    1. A custom name of the identity provider that will be shown on the login screen.
    2. The unique issuer ID provided by the OIDC provider. It usually appears as a URN.
    3. The client identifier and secret to access the OIDC provider.
    4. The metadata URL of the OIDC provider's discovery endpoint. The metadata URL is typically the issuer endpoint concatenated with the path /.well-known/openid-configuration. For example, if the issuer ID is https://idp.example.com/adfs/, the metadata URL will be https://idp.example.com/adfs/.well-known/openid-configuration.
    5. Scopes that define what user identity data will be shared by the OIDC provider during authentication.

      The scopes allatclaims and openid are mandatory for Microsoft AD FS providers.

    6. Select Verify SSL if you want the client to validate the server's SSL/TLS certificate when establishing a connection.

    7. Specify the timeout for sending requests to the identity provider, in seconds. The default value is 5.

  4. In the Grant types section, choose between Implicit Flow and Authorization Code Flow:

    • Implicit Flow is used for client-side web applications. This grant type is a simplified authorization code flow that is optimized for clients implemented in a browser. In the implicit flow, instead of issuing the client an authorization code, the client is issued an access token directly.

      The Implicit Flow is mainly used by clients implemented in a browser using a scripting language. The access token and ID token are returned directly to the client, which may expose them to the end user and applications that have access to the end-user's user agent. The authorization server does not perform client authentication.

    • With Implicit Flow, the identity provider provides an access token, which is used to request claims via the UserInfo Endpoint, by presenting the access token.
    • Authorization Code Flow is used for server-side web applications.

    • With Authorization Code Flow, the identity provider provides an authorization code. The authorization code is used to get an ID Token (which also contains the claims).
    • When using the Authorization Code Flow, all tokens are returned from the Token Endpoint.

      The Authorization Code Flow returns an Authorization Code to the Client, which can then exchange it for an ID Token and an Access Token directly. This provides the benefit of not exposing any tokens to the User Agent and possibly other malicious applications with access to the User Agent. The Authorization Server can also authenticate the Client before exchanging the Authorization Code for an Access Token. The Authorization Code flow is suitable for Clients that can securely maintain a Client Secret between themselves and the Authorization Server

  5. In the Mapping section, you can either create mapping rules manually or automatically from a mapping file:

  6. Click Add.

Command-line interface

Use the following command:

vinfra domain idp create --domain <domain> --issuer <issuer> --scope <scope>
                         [--metadata-url <metadata-url>] [--client-id <client-id>]
                         [--client-secret <client-secret>] [--mapping <path>]
                         [--enable] [--disable] [--verify-ssl | --dont-verify-ssl]
                         [--request-timeout <seconds>] <name>
--domain <domain>
Domain name or ID
--issuer <issuer>
Identity provider issuer
--scope <scope>

Scope that define what user identity data will be shared by the identity provider during authentication.

The scopes allatclaims and openid are mandatory for Microsoft AD FS providers.

--metadata-url <metadata-url>
Metadata URL of the identity provider's discovery endpoint
--client-id <client-id>
Client ID to access the identity provider
--client-secret <client-secret>
Client secret to access the identity provider
--mapping <path>

Path to the mapping configuration file.

A mapping file may look as follows:

# cat mapping.json
[
    {
        "local": [
            {
                "user": {
                    "name": "{0}"
                },
                "group": {
                    "name":"users"
                }
            }
        ],
        "remote": [{"type": "email"}]
    }
]

In this example, all users that have the attribute email will be mapped to the group users within the default domain. For details on creating a mapping file, refer to the OpenStack documentation.

--enable
Enable identity provider
--disable
Disable identity provider
--verify-ssl
Enable identity provider endpoints SSL verification
--dont-verify-ssl
Disable identity provider endpoints SSL verification
--request-timeout <seconds>
Identity provider API request timeout (default: 5)
<name>
Identity provider name

For example, to add an identity provider with the name My ADFS within the mydomain domain, run:

# vinfra domain idp create --domain mydomain --issuer https://idp.example.com/adfs/ \
--scope "allatclaims openid email" --client-id xxx --client-secret xxx --mapping mapping.json "My ADFS"

The added identity provider will appear in the vinfra domain idp list output:

# vinfra domain idp list --domain mydomain
+-------------+---------+-------------------------------+--------------------------+-----------+
| id          | name    | issuer                        | scope                    | domain_id |
+-------------+---------+-------------------------------+--------------------------+-----------+
| df5a54ce<…> | My ADFS | https://idp.example.com/adfs/ | allatclaims openid email | 36f454<…> |
+-------------+---------+-------------------------------+--------------------------+-----------+