Description

OpenID Connect authentication

OpenID Connect (http://openid.net/connect/)  ‑protocol is an expansion of the OAuth 2.0 authorization protocol. OpenID Connect allows 1C:Enterprise to verify user identities based on the authentication by the third-party provider. This protocol is applicable when using thin, mobile, or web client. 1C:Enterprise cannot be the OpenID Connect provider. Third-party providers are used for this purpose. OpenID Connect protocol support also means the potion to use the Unified System for Identification and Authentication (USIA).

To match 1C:Enterprise users and authentication provider users, email messages are used. The OpenID Connect provider provides email services for 1C:Enterprise. The user email address must be specified in the Name property of the Infobase user.

So far as a mobile client is concerned, authentication is provided using a web browser supported by a mobile device:

• OS Android: Google Chrome.
• OS iOS: 9.0 or later.

If your mobile device is not in compliance with the aforesaid requirements, repeated authentication is required on the side of the OpenID Connect provider in a mobile client. To start forced authentication when you log in next time, run Log out command in the mobile client.

Description of the work using the OpenID Connect provider 

Items description

<openidconnect>

This item describes the settings related to authentication over OpenID Connect protocol. Applicable when using thin client and web client. <openidconnect> item is subordinate to <point> item. No more than one is allowed. <providers> and <allowStandardAuthentication> items are subordinate to <openidconnect> item. No more than one subordinate element is allowed.

This item does not have any attributes.

<openidconnect>
 <providers><![CDATA[[
   <json-data>
   ]]]>
 </providers>
 <allowStandardAuthentication>true</allowStandardAuthentication>
<openidconnect>

<providers>

This item contains description of external OpenID providers supporting OpenID Connect v1.0 authentication protocol (http://openid.net/connect/). The description is an array of objects, where each object describes one OpenID provider. The array is represented by JSON serialization.

Each provider is described with the object with the following properties:

• name ‑ provider ID. Must be unique within the array. If the array contains several providers with the same ID, the last one will be used.
• title ‑ provider text representation. Will be displayed on the provider button in the authentication page unless the image (image) is specified.
• image ‑ provider graphical representation. Will be displayed on the provider button in the authentication page. The image is specified as data:image in base64 format.
• discovery ‑ describes provider URL (if supported), which allow to retrieve all its settings (discovery endpoint URL) when accessed.
• provideconfig ‑ provider settings description as JSON file (unless the provider supports the request to retrieve settings). The data must be in OpenID Provider Metadata format (http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata).
• clientconfig ‑ client configuration as JSON file. This data format matches OAuth 2.0 Authorization Request format (http://openid.net/specs/openid-connect-core-1_0.html#AuthRequest), to which the authority that must contain authentication provider URL is added. Contents of this property depend on the provider used.

  redirect_uri property in clientconfig structure has URL which is used to enter an authentication data processor in an application which requests such authentication. As a rule, the said URL is as follows: https://IBhost/IBname/authform.html :

  • IBhost ‑ name of a host, where an infobase is published.
  • IBname ‑ name of an infobase which has been published ("name" means information entered in Name field in the infobase publication dialog box or any similar value, if any other publication method is used.
• dialect ‑ defines the protocol that will be used to interact with the provider. If ru-esia value is specified, then the protocol of the Unified system for identification and authentication will be used to interact with the provider (USIA, http://minsvyaz.ru/ru/activity/directions/13/). If this attribute is not specified or its value differs from ru-esia, then OpenID Connect v1.0 protocol will be used to interact with the provider.
• crypto ‑ contains a structure that describes the cryptography module that is used to sign requests. Signing requests is necessary if the USIA protocol is used to interact with the provider (dialect property is equal to the ru-esia value). The structure contains the following properties:
  • module_name ‑ cryptography module name;
  • module_path ‑ path to the cryptography module;
  • module_type ‑ cryptography module type;
  • cert_thumbprint ‑ certificate thumbprint that will be used to sign requests. Certificate search will be executed by thumbprint. The certificate must be previously stored in the personal certificate store.

    The fields of the structure located in the crypto property are similar to the parameters of the constructor of the CryptographyManager object.

Provider description example:

<openidconnect>
 <providers><![CDATA[[
   {
    "name": "google",
    "title": "Google",
    "discovery": "https://accounts.google.com/.well-known/openid-configuration",
    "clientconfig": {
     "authority": "https://accounts.google.com/",
     "client_id": "<client ID>",
     "redirect_uri": "https://localhost/openidc/authform.html",
     "response_type": "id_token token",
     "scope": "openid email",
     "filterProtocolClaims": true,
     "loadUserInfo": false
    }
   },
   {
    "name": "microsoft",
    "title": "Microsoft",
    "image": "data:image/png;base64,………",
    "discovery": "https://login.microsoftonline.com/<client ID>/.well-known/openid-configuration",
    "clientconfig": {
     "authority": "https://login.microsoftonline.com/<client ID>/",
     "client_id": "<client ID>",
     "redirect_uri": "https://localhost/openidc/authform.html",
     "response_type": "id_token token",
     "scope": "openid email"
    }
   },
   {
    "name": "googleII",
    "title": "Another Google",
    "providerconfig": {
       "issuer": "https://accounts.google.com",
       "authorization_endpoint": "https://accounts.google.com/o/oauth2/v2/auth",
       "token_endpoint": "https://www.googleapis.com/oauth2/v4/token",
       "response_types_supported": ["code","token"],
       "scopes_supported": ["openid","email","profile"]
    },
    "clientconfig": {
       "authority": "https://accounts.google.com/",
       "client_id": "<client ID>",
       "redirect_uri": "https://localhost/openidc/authform.html",
       "response_type": "id_token token",
       "scope": "openid email"
    }
   }
   ]]]>
 </providers>
 <allowStandardAuthentication>true</allowStandardAuthentication>
</openidconnect>

<allowStandardAuthentication>

The item allows or prohibits 1C:Enterprise authentication. If this item is false, authentication using the providers described in default.vrd file will be available in the authentication form on web client startup.

The item can take the following values:

• true ‑ 1C:Enterprise authentication is permitted. Default value.
• false ‑ 1C:Enterprise authentication is forbidden.

Operation scenario

Authentication using the OpenID Connect provider is available only if the parameters of one or more providers are specified in the default.vrd file. When trying to use a client application (thin or web client) to access the infobase, the following actions are executed:

• If the provider is explicitly specified in the client application command line, the jump is executed in accordance with the parameters, specified in default.vrd file for this provider.
• Otherwise, the platform forms a start form (depending on the client application), on which all configured OpenID Connect providers are located (in the default.vrd file). Depending on the settings, this web page may contain the access button using the standard 1C:Enterprise authentication.
• After selecting the provider, the user is redirected to the provider's authentication page. On this page, the user authenticates with selected provider in any possible method (for this provider).
• Then the provider redirects the user to a special page of the 1C:Enterprise system, passing a JSON file as a "parameter" (JSON Web Token, JWT) with the authentication results. URL of this page is specified in redirect_uri property in clientconfig structure of provider element.
• Using the authentication results passed by the provider, 1C:Enterprise retrieves the user email from the provider.
• Retrieved e-mail address is used to search for the user in the 1C:Enterprise infobase. Search is executed by the user property Name.
• After that the authentication is deemed to be successful and the application startup continues.

If authentication on the provider side fails, the provider's actions are not defined.