6.2.10. Authentication types

<< Prev   Next >>

6.2.10.1. General information

Authentication is a procedure that verifies whether the provided ID (name) belongs to the user. 1C:Enterprise supports multiple authentication types, which are described in further sections.

6.2.10.2. 1C:Enterprise authentication

The user can be authenticated by 1C:Enterprise by providing their username and password (typed in authentication dialog box, passed as command-line parameters, or passed in the infobase connection string for an external connection or automation server). In this case, username and password verification is performed by 1C:Enterprise.

6.2.10.3. OS authentication

The user can be authenticated implicitly using the operating system functionality. To enable this authentication type, you need to match the 1C:Enterprise user to an operating system user. On startup, 1C:Enterprise prompts the operating system for information on the currently authenticated OS user. For this purpose, Windows uses SSPI interface and Linux uses GSS-API. Then the match between the operating system user and 1C:Enterprise user is verified. If the matching user is found, 1C:Enterprise user is authenticated and the authentication dialog box is not displayed.

Specify the operating system user as follows: \\domain_name\username. The username contains Latin letters only. The format of domain name and username might depend on settings of the domain controller and its accounts. Correct name of the operating system user can be found in the records of CONN event in the technological log. Look for Txt property that starts with Srvr: DstUserName2. For example, the 30:30.551013-0,CONN,2,process=rmngr,OSThread=24204,t:clientID=3,Txt=Srvr: DstUserName2: d1.d2\user1(d1.d2\user1) event means that you must specify the OS username in the infobase user description as follows: \\d1.d2\user1.

When forced 1C:Enterprise authentication is required, specify /WA- command-line parameter in the startup command line of the client application. The /WA+ command-line parameter forces OS authentication (enabled by default).

See also:

• Technological log

6.2.10.4. OpenID authentication

OpenID (https://openid.net/) is a protocol that allows a user to authenticate in many unrelated resources, systems, and so on using a single account. 1C:Enterprise uses a protocol based on OpenID 2.0 under Direct Identity model.

The general procedure is as follows:

• User attempts to sign in to 1C:Enterprise.
• 1C:Enterprise identifies that OpenID authentication is enabled for the infobase using the default.vrd publication file.
• Authentication request is sent to OpenID provider. OpenID provider must be able to receive requests from the address of the infobase publication.
• If an interactive action is needed (for example, the first authentication for this user ID is performed, or the user authentication data has expired), the provider informs 1C:Enterprise that username and password are required. 1C:Enterprise performs the interactive action and returns the requested data to the OpenID provider.

  User authentication data is stored in cookie files located in web browser storage. Thin client uses own storage.

• If the provider authenticates the user, a flag is returned to 1C:Enterprise indicating that the user is authenticated.

OpenID authentication only works when the infobase is accessed over HTTP or HTTPS. This means that OpenID authentication is only available for web client, mobile client, and thin client connected to the infobase via the web server. Upon OpenID authentication, there might be cross-domain requests if you use a thin client or Mozilla Firefox, Google Chrome, and Safari.

An OpenID provider can be a 1C:Enterprise infobase published on a server in a special way, or an information system that has OpenID Authentication 2.0 and extension of this protocol implemented on the 1C:Enterprise platform. The address of the OpenID provider is specified in default.vrd file (<rely> element) when publishing an infobase that is an OpenID provider's client.

It is important to understand that the key field used to match the 1C:Enterprise infobase user and OpenID provider user is a value specified in the Name property of the infobase user. In other words, a user can sign in to the infobase if the Name property in the infobase contains an ID returned by the OpenID provider. For description of an ID to be returned, refer to documentation of the OpenID provider used.

User password is set at the OpenID provider. If a 1C:Enterprise infobase acts as the OpenID provider, the password is set in this infobase. The password set in the infobase that operates as the OpenID provider's client is ignored during OpenID authentication. If a third-party OpenID provider is used, the password is set by this provider. After the user password is changed in the OpenID provider user storage, the 1C:Enterprise follows the following rules:

• User is considered authenticated in any currently running sessions until these sessions are terminated.
• When creating a new session, the user is prompted for the password even if the user authentication data has not expired yet.

When forced OpenID authentication is required, specify /OIDA+ command-line parameter (enabled by default) in the startup command line of the client application. The /OIDA command-line parameter is used to force disable OpenID authentication.

For more information on configuring web server to support OpenID authentication, see article OpenID authentication support settings.

See also:

• OpenID Authentication 2.0 (see https://openid.net/specs/openid-authentication-2_0.html).
• Additional requirements for an OpenID provider

6.2.10.5. OpenID Connect authentication

OpenID Connect (https://openid.net/connect/) is a protocol that is an extension 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 option to use the Unified System for Identification and Authentication (USIA).

To map 1C:Enterprise users and authentication provider users, the following data is used:

• On the authentication provider side, the email address as a key parameter is used by default. When setting up access to the OpenID Connect provider, you can specify an authentication token field to be used as a key field.
• On 1C:Enterprise side, the key parameter is located in the Name property of the infobase user by default. You can set the OSUser or Email property, as well as a value from the UserMatchingKeys collection as a key field.

If the UserMatchingKeys collection is used for mapping, you can fill it using 1C:Enterprise language only. The code can be as follows:

IBUser = InfobaseUsers.Find(UserCode);
IBUser. UserMatchingKeys.Insert("googleIV", "user-name@google.com");
IBUser.Write()

The UserMatchingKeys collection element is used if the provider list in the default.vrd file contains a description of a provider whose name property is equal to the googleIV value. The user who is identified by the UserCode variable value will be used upon session startup if the mapping field value from the token returned by the OpenID Connect provider is user-name@google.com. See the googleIV provider details in the example for the openidconnect.providers item of the default.vrd file.

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

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

If your mobile device is not in compliance with the requirements above, you might need to authenticate again on the side of OpenID Connect provider in a mobile client. To start forced authentication when you sign in next time, run Log out command in the mobile client.

See also:

• OpenID Connect operations
• default.vrd file

6.2.10.6. JWT authentication

Token is a tool to authenticate a user or a separate session in the application. JSON Web Token (JWT) is a standard for access token creation based on JSON format. JWT is described in the RFC 7519 standard (https://datatracker.ietf.org/doc/html/rfc7519). JWT is used for user authentication in client/server applications.

JWT authentication is available only in infobases that are published on the web server. To specify JWT, use the AccessToken command of the client application startup command-line.

A published infobase must be configured in a certain way. To set up a publication, use the default.vrd file.

See also:

• JWT operation description
• default.vrd file

6.2.10.7. Two-factor authentication

6.2.10.7.1. General information

The platform can perform user authentication independently, or it can use the results of authentication performed by another resource that it trusts (operating system or OpenID provider). In any case, the user enters a username and a password. If the correct username/password pair is entered, the platform considers that the user is identified and grants them access to the application.

This conventional scheme is simple and convenient, but has one significant drawback. You need to remember the password, and it must be short and simple for that. But such password is easy to hack. For a password to be difficult to hack, it must be long and complex. But such password is not easy to remember. For this reason, in reality it all comes down to people using simple and the same passwords for different resources.

Two-factor authentication is a method that allows you, on the one hand, to complicate access to user data for hackers, and on the other hand, it is a solution that mitigates the disadvantages of classical password protection to some extent.

Two-factor authentication requires the user to have two of the three possible types of authentication data:

• Something they know and remember. This is the username and password.
• Something they own. This can be a user cell phone or email.
• Something inherent to them. This can be a physical feature of the user, such as a fingerprint, a portrait, or an iris pattern.

The point of two-factor authentication is that the user must double confirm their identity in order to get access to the application solution. Moreover, they need to do that in different ways. For example, entering the username and password will be the first authentication factor and entering the code sent to the cell phone will be the second authentication factor.

The verification of the first authentication factor is performed by 1C:Enterprise platform itself, and a third-party service, which is called the second factor provider, is used to process the second authentication factor.

Second factor provider (the "provider" term can be used in this section) is an HTTP service that provides API for performing certain actions. A 1C:Enterprise infobase can act as the second factor provider if a set of HTTP services for forwarding messages and performing authentication is implemented in the infobase. It can be a third-party service that sends SMS or e-mail messages, it can be a service that generates codes of the second authentication factor or a service that interacts with the user through its own mobile application, and so on. All that matters is that the provider can be accessed via HTTP requests.

You can use the two-factor authentication only for authentication with 1C:Enterprise tools (standard authentication) in any infobase mode and for any client application.

See also:

• 1C:Enterprise authentication

6.2.10.7.2. Options for using the second factor

So, the standard 1C:Enterprise authentication (the first factor) is as follows:

1. The user starts the client application. The client application asks the user for the first authentication factor: username and password. The user enters the username and password, and the client application sends them to the server.
2. Server checks the username and password for correctness.
3. If the data entered is correct, the server checks that the user needs only one authentication factor to use the application. If the second factor is not used, it is considered that the user is fully identified and can start operations. This is a common authentication scenario.

If two-factor authentication is set for the user, the first two steps are performed as before (entering the username and password and checking this data by 1C:Enterprise server).

The use of the second factor can be performed in two ways:

1. 1C:Enterprise server itself generates a second factor and checks if the user correctly entered the value of this factor. The provider only performs the transport function. It transmits the second factor value to the user. In this case, both 1C:Enterprise server and the user know the channel used to transmit the second factor value.

   The procedure is as follows:

   • 1C:Enterprise server informs the application that the user needs to specify a second authentication factor.
   • Application displays the second factor input form.
   • 1C:Enterprise server generates and sends the value of the second factor (for example, a certain number) to the user. The user must enter this value in the form opened by the application. The second factor value can be sent to the user by e-mail or SMS.
   • User receives the second factor data and enters it in the dialog box opened by the application. The application sends the second factor data to 1C:Enterprise server.
   • 1C:Enterprise server verifies that the entered data matches the data generated and sent to the user by the server.
   • If the second factor value transmitted by the application and the one generated by the 1C:Enterprise server match, the user is identified and granted access to the application.
2. 1C:Enterprise server uses a third-party service that sends the result of applying the second factor by the user to 1C:Enterprise server. In this case, 1C:Enterprise server has no information on the type of the used second factor. The method for transmitting the second factor is also determined by the selected second factor provider. 1C:Enterprise server only has information that there is a trusted service that in response to the requirement to use the second authentication factor informs whether the second factor is applied successful or not.

   The procedure is as follows:

   • 1C:Enterprise server informs the client application that the user must authenticate the second factor on the provider side.
   • Client application shows the form to the user, where the user must perform a certain action after being authenticated by the second factor provider.
   • Server sends an HTTP request to the provider with a request to authenticate the user.
   • Provider begins the authentication procedure. The authentication method is at the discretion of the provider.
   • After the authentication procedure is completed, the user reports this to the client application.
   • Client application passes this information to 1C:Enterprise server, which requests the second factor provider for authentication results.
   • Provider reports the authentication result to the server. If authentication is successful, the user is considered identified and they are granted access to the application.

Each method reviewed in this section has a certain support from the 1C:Enterprise application. Setting of the second authentication factor is reviewed in the next section.

6.2.10.7.3. Second factor setting

Setting of using the second factor in 1C:Enterprise is divided into several parts:

• Configuring templates of requests that are sent to providers.
• Binding a request template to an infobase user.
• Requests parameterization.

Let's take a closer look at each part.

To describe the HTTP request to be sent to the provider, the SecondAuthenticationFactorSettingTemplate object is used. One of the options of the second authentication factor is selected while setting the template parameters. If it is necessary to implement the first option of the second authentication factor (1C:Enterprise server generates, sends and checks the second factor value), the AuthenticationHTTPRequest and the AuthenticationHTTPRequestMethod properties are used. The first property contains description of the HTTP request (an object of the HTTPRequest type), and the second parameter allows you to specify which HTTP method will be used to request the second authentication factor to the provider.

If it is necessary to implement the second authentication option (1C:Enterprise server only initiates authentication in the second factor provider and receives its result), the parameters reviewed above remain. They are used for the second authentication factor. To check the authentication result, use the following additional properties: AuthenticationResultVerificationHTTPRequest and AuthenticationResultVerificationHTTPRequestMethod.

Each template has its own name (property of the same name), which allows you to identify the template when performing further actions.

When creating an HTTP request for setting any property, keep in mind the following features:

1. HTTP method is specified as a string. This is because the HTTP specification allows usage of custom verbs (methods).
2. Request text may contain parameters. A parameter is a text starting with the "&" character. For example, you can use the & user_name parameter to specify a username. These parameters will be replaced with real values at the time of sending the request (will be reviewed below). The reason for this decision is the assumption that the HTTP requests of the second authentication factor for different users will be almost the same. Differences will be observed only in some information that is specific to a particular user. For example, a conditional request to send a text message with the second factor code looks as follows: . When sending the request, the &phone_number parameter is to be replaced with the actual phone number of the user.

   The platform provides the predefined &secret variable, which contains the value of the second factor generated by the platform.

Having all the information, let's look at an example of creating a template for working with the second factor according to the first option (the platform generates, sends, provides input and verification of the second factor):

Request = New HTTPRequest;
Request.Resource Address = "&addr";
Request: SetBodyFromString ("Enter the & secret value. Do not tell this value to anyone!", "Utf-8");
Provider = SecondAuthenticationFactorSettingsTemplates.CreateTemplate();
Provider.AuthenticationHTTPRequest = Request;
Provider.AuthenticationHTTPRequestMethod = "POST";
Provider.Name = "Request - response";
Provider.Record();

The first three strings form the HTTP request that will be used by the platform. The remaining strings create the template of the second factor provider, which will send the request using the POST method and have the name Request – response.

If it is necessary to create a template for the second factor provider used according to the second option (all actions are performed by the provider, the platform only initiates the operation start and requests the authentication result), then the above example is to be changed in such a way that:

1. Authentication request meets the requirements of the provider used.
2. Request to check the authentication results is created and set in the template. This request will be made after the user "informs" the client application that they passed authentication at the provider.

After saving one or several templates for providers, you can assign one of the templates to the user. Keep in mind that you can assign multiple templates to one user and specify how they will be processed.

To set up user settings, two properties of the InfobaseUser object are used:

• SecondAuthenticationFactorSetting. Here you need to assign an array of objects of the SecondAuthenticationFactorSetting type.
• SecondAuthenticationFactorSettingsProcessing. Describes what the platform will do if several second factor providers are specified, and the first (in the traversal order) provider returns an error.

After specifying the above properties, the object describing the infobase user is to be recorded.

The last point to consider is where the platform will get the values that will replace the variables in HTTP requests. For this, let's have a look at the SecondAuthenticationFactorSetting object. This object contains two fields:

• SettingTemplateName. In this field, specify the name of the template of the second factor provider setting, which was specified in the Name property when setting the provider template.
• Parameters. You need to assign a match to this property. The match should contain as many elements as the parameters are contained in the setting template of the second factor provider (with the exception of the &secret parameter). A parameter name (without the "&" character) acts as a map item key, and a variable value is a value.

Now we have all the information we need to indicate to the infobase user that two-factor authentication is required when signing in to the infobase.

ProviderParameters = New Map;
ProviderParameters.Insert("addr", "http://example.com/resource");
UserSetting = New SecondAuthenticationFactorSetting;
UserSetting.SettingTemplateName = "Question - answer";
UserSetting.Parameters = ProviderParameters;

UserSettings = New Array;
UserSettings.Add(UserSetting);

User = InfobaseUsers.FindByName("Seller");
User.SecondAuthenticationFactorSettings = UserSettings;
User.SecondAuthenticationFactorSettingsProcessing = SecondAuthenticationFactorSettingsProcessingType.UseNextIfFailed;
User.Record();

The platform will replace parameter names with the actual values in the following properties:

• HTTPRequest.ResourceAddress property.
• HTTPRequest.Headers property.
• HTTPRequest object request body. The method of specifying the request body does not affect the substitution.
• SecondAuthenticationFactorSettingTemplate.AuthenticationHTTPRequestMethod property.
• SecondAuthenticationFactorSettingTemplate.AuthenticationResultVerificationHTTPRequestMethod property.

Note that if the second factor provider selected for the user is "broken", the user cannot get access to the infobase. In this case, the term "broken" means any event that does not allow the provider to complete its task: no Internet connection for access from the server to the provider, no Internet connection for access from the provider to the user, an error on the provider side, and so on.

It is also necessary to understand that if you plan to use a third-party provider of the second factor, then the services of this provider may be paid and the provider may put forward additional conditions and restrictions that lie outside the 1C:Enterprise system and are not considered in this documentation.

6.2.10.7.4. OpenID Authentication and two-factor authentication

1C:Enterprise supports authentication using the OpenID protocol. If the information system uses OpenID authentication, the second factor is to be requested by the OpenID provider. This is true as well if a 1C:Enterprise infobase is specified as an OpenID provider. In other words, two-factor authentication must be configured in the infobase that is the OpenID provider.

6.2.10.8. Use of biometrics to log in through a mobile client

So far as devices which support biometric authentication (i.e. they have a fingerprint sensor, face or iris scanner, and so on) are concerned, Use biometrics check box is available in a mobile client infobase setting and authentication (on a mobile device) dialog boxes. Whenever this check box is checked, the following mechanism is activated:

• When you sign in for the first time, usernames and passwords you enter for the infobase and authentication using OpenID and web server are stored in a secure storage.
• The next time you sign in, the following logic is implemented:
  • First, an attempt to sign in is made without using data available in a secure storage to verify that authentication is not currently required or there is relevant authentication data disclosed by OpenID provider. If a mobile device stores relevant authentication data, a request to provide biometric data for authentication purposes is made only when authentication data life cycle expires.
  • If the previous step failed, a user is prompted to undergo biometric authentication using a mobile operating system interface. The authentication type specified in mobile device user settings is requested.
  • If biometric authentication is abandoned by a user, the standard authentication dialog box with username and password is displayed.
  • If biometric data is accepted by the mobile device, data saved during prior successful authentication is recovered from the secure storage. The said data is used for authentication purposes.
  • If this data is not accepted by a mobile device, data saved during prior successful authentication is deleted from the secure storage. Then, the standard authentication dialog box with username and password is displayed.
• No biometric data is used if authentication is made through OpenID Connect as in this scenario a protected web page of OpenID Connect provider is used to perform authentication. On this page, the previously saved username and password for this provider cannot be inserted automatically. Moreover, OpenID Connect supports repeated authentication on this device without any time limit for entering username and password.

  If your mobile device supports authentication through OpenID Connect, this method is used for authentication purposes. Whenever authentication through OpenID Connect is abandoned, you can sign in fast using biometric data. To repeatedly authenticate through OpenID Connect, an attempt to sign in must fail first.

<< Prev   Next >>