Adding identity providers

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:

   • To manually create mapping rules

     1. Select Create mapping rules, and then click Add.

     2. In the Add rule window, create Mapping conditions by clicking Add and specifying the required parameters:

        • In Attribute, specify a user attribute that you obtain from the identity provider during authentication.
        • In Condition, specify a condition to apply to the attribute. With the condition Exists, all users with this attribute will be mapped. The condition Contains maps users if this attribute contains any of the specified values. The condition Does not contain maps users if this attribute does not contain any of the specified values.
        • In Value, specify the desired attribute value as a string, comma-separated list, or regular expression.
     3. Select an existing domain group to assign federated users to.
     4. If you have a mapping rule with the condition Exists, select attributes that the name of a local user will consist of. For example, with the mapping attribute email and mapping condition Exists, names of local users may be composed of their emails.

     

   • To automatically create mapping rules

     1. Select Upload a mapping file in the JSON format with already configured mapping rules.

     2. Write mapping rules in the JSON format in the Mapping data field. Alternatively, click Upload, and then browse a JSON file on your local server to load the mapping data from.

        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.

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<…> |
+-------------+---------+-------------------------------+--------------------------+-----------+