Managing OpenID Connect and SAML Clients

Clients are entities that can request authentication of a user. Clients come in two forms. The first type of client is an application that wants to participate in single-sign-on. These clients just want SafeNet Access Exchange to provide security for them. The other type of client is one that is requesting an access token so that it can invoke other services on behalf of the authenticated user. This section discusses various aspects around configuring clients and various ways to do it.

OIDC clients

Open ID Connect is the recommended protocol to secure applications. It was designed from the ground up to be web friendly and it works best with HTML5/JavaScript applications.

Creating an OpenID Connect client

To protect an application that uses the OpenID connect protocol, you create a client.

Procedure

1. Click Clients in the menu.

2. Click Create client.

1. Leave Client type set to OpenID Connect.

2. Enter a Client ID.

   This ID is an alphanumeric string that is used in OIDC requests and in the SafeNet Access Exchange database to identify the client. 5. Supply a Name for the client.

   If you plan to localize this name, set up a replacement string value. For example, a string value such as MISSING VARIABLE: myapp.

3. Click Save.

Client ID- The alphanumeric ID string that is used in OIDC requests and in the SafeNet Access Exchange database to identify the client.

Name- The name for the client in SafeNet Access Exchange UI screen. To localize the name, set up a replacement string value. For example, a string value such as MISSING VARIABLE: myapp.

Description- The description of the client. This setting can also be localized.

Always Display in UI- Always list this client in the Account Console even if this user does not have an active session.

Client authentication

The type of OIDC client.

• ON : For server-side clients that perform browser logins and require client secrets when making an Access Token Request. This setting should be used for server-side applications.

• OFF: For client-side clients that perform browser logins. As it is not possible to ensure that secrets can be kept safe with client-side clients, it is important to restrict access by configuring correct redirect URIs.

Authorization- Enables or disables fine-grained authorization support for this client.

Standard Flow- If enabled, this client can use the OIDC Authorization Code Flow.

Direct Access Grants- If enabled, this client can use the OIDC Direct Access Grants.

Implicit Flow- If enabled, this client can use the OIDC Implicit Flow.

Service account roles- If enabled, this client can authenticate to SafeNet Access Exchange and retrieve access token dedicated to this client. In terms of OAuth2 specification, this enables support of Client Credentials Grant for this client.

Auth 2.0 Device Authorization Grant- If enabled, this client can use the OIDC Device Authorization Grant.

OIDC CIBA Grant- If enabled, this client can use the OIDC Client Initiated Backchannel Authentication Grant.

Root URL- If SafeNet Access Exchange uses any configured relative URLs, this value is prepended to them.

Home URL- Provides the default URL for when the auth server needs to redirect or link back to the client.

Valid Redirect URIs- Required field. Enter a URL pattern and click + to add and - to remove existing URLs and click Save. You can use wildcards at the end of the URL pattern. Exclusive redirect URL patterns are typically more secure.

Web Origins- Enter a URL pattern and click + to add and - to remove existing URLs. Click Save. This option handles CORS. If browser JavaScript attempts an AJAX HTTP request to a server whose domain is different from the one that the JavaScript code came from, the request must use CORS. The server must handle CORS requests, otherwise the browser will not display or allow the request to be processed. This protocol protects against XSS, CSRF, and other JavaScript-based attacks.

Domain URLs listed here are embedded within the access token sent to the client application. The client application uses this information to decide whether to allow a CORS request to be invoked on it. Only SafeNet Access Exchange client adapters support this feature.

Admin URL- Callback endpoint for a client. The server uses this URL to make callbacks like pushing revocation policies, performing backchannel logout, and other administrative operations. For SafeNet Access Exchange servlet adapters, this URL can be the root URL of the servlet application.

Enabled- When turned off, the client cannot request authentication.

Login theme- A theme to use for login, OTP, grant registration, and forgotten password pages.

Consent required- If enabled, users have to consent to client access. For client-side clients that perform browser logins. As it is not possible to ensure that secrets can be kept safe with client-side clients, it is important to restrict access by configuring correct redirect URIs.

Display client on screen This switch applies if Consent Required is Off. - Off: The consent screen will contain only the consents corresponding to configured client scopes. - On: There will be also one item on the consent screen about this client itself.

Client consent screen text- Applies if Consent required and Display client on screen are enabled. Contains the text that will be on the consent screen about permissions for this client.

Front channel logout- If Front Channel Logout is enabled, the application should be able to log out users through the front channel as per Open ID Connect Front-Channel Logout specification. If enabled, you should also provide the Front-Channel Logout URL.

Front-channel logout URL- URL that will be used by SafeNet Access Exchange to send logout requests to clients through the front-channel.

Backchannel logout URL- URL that will cause the client to log itself out when a logout request is sent to this realm (via end_session_endpoint). If omitted, no logout requests are sent to the client.

Backchannel logout session required- Specifies whether a session ID Claim is included in the Logout Token when the Backchannel Logout URL is used.

Backchannel logout revoke offline sessions- Specifies whether a revoke_offline_access event is included in the Logout Token when the Backchannel Logout URL is used. SafeNet Access Exchange will revoke offline sessions when receiving a Logout Token with this event.

Client scopes

Use SafeNet Access Exchange to define a shared client configuration in an entity called a client scope. A client scope configures protocol mappers and role scope mappings for multiple clients.

Client scopes also support the OAuth 2 scope parameter. Client applications use this parameter to request claims or roles in the access token, depending on the requirement of the application.

To create a client scope, follow these steps:

1. Click Client Scopes in the menu. The Client scopes list is displayed.

1. Click Create.

2. Name your client scope.

3. Click Save.

A client scope has similar tabs to regular clients. You can define protocol mappers and role scope mappings. These mappings can be inherited by other clients and are configured to inherit from this client scope.