Description

Second-factor authentication

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 a 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, on the one hand, to complicate hackers' access to other people's data, and on the other hand, ‑ it is a solution that allows mitigating 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. In this case, some physical feature of the user may be used: a fingerprint, a portrait, an iris pattern.

The point of two-factor authentication is that the user must double confirm their identity ‑ in order to gain access to the application solution. Moreover, they need to do that in different ways. For example, entering the username/password (and this will be the first authentication factor), and then enter the code sent to their cell phone (and this 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.

The Second-factor provider (we may use "provider" term in this section) ‑ is an HTTP service that provides a software interface for performing certain actions. The provider of the second factor can be, for example, the 1C:Enterprise Infobase, where a set of HTTP services that allow forwarding messages or performing authentication, is implemented. 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 service that interacts with the user through its own mobile application, etc. All that matters is that the provider can be accessed via HTTP requests.

Two-factor authentication can be used in any 1C: Enterprise Infobase version and for any client application.

Options for using the second factor

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

• The user starts the client application. The client application prompts the user to input the first authentication factor ‑ i.e. login and password. The user inputs these, and the client application sends these to the server.
• The server checks the username and password for correctness.
• 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 that exists in the platform now.

If two-factor authentication is set for the user, then the first two steps are performed, as before ‑ i.e. entering the login/password and checking these data for 1C:Enterprise servers.

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

• The 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 ‑ i.e. transmitting of the second-factor value to the user. In this case both the 1C:Enterprise server and the user know using which channel the value of the second factor will be transmitted.

  The procedure is as follows:

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

  The procedure is as follows:

  • The 1C:Enterprise server informs the client application that the user must authenticate the second factor on the provider side.
  • The client application shows the form to the user, in which the user must execute a certain action after the user is authenticated by the provider of the second factor.
  • The server sends an HTTP request to the provider with a request to authenticate the user.
  • The 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.
  • The client application passes this information to the 1C:Enterprise server, which is requested by the provider of the second factor about the authentication results.
  • The provider informs the authentication result to the server. If it is successful, then the user is considered identified and he is granted access to the application.

Each of the methods reviewed in this section has certain support from the 1C:Enterprise system. The setting of the application of the second authentication factor is reviewed in the next section.

Second-factor setting

The setting of application of the second factor in the 1C:Enterprise system is divided into several parts:

• The setting of request templates 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 that should be sent to the provider, the TemplateOfSettingsOfTheSecondAuthenticationFactor object is used. The choice of one of the options for the second authentication factor is carried out in the process of setting the template parameters. In case when it is necessary to implement the first option of the second authentication factor (1C:Enterprise server itself generates, sends and checks the value of the second factor), the HTTPRequestToAuthentication and the HTTPRequestToAuthenticationMethod properties are used. The first property contains a 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.

In case when it is necessary to implement the second authentication option (1C:Enterprise server only initiates authentication in the provider of the second factor and receives its result), the parameters reviewed above remain and are used for their intended purpose-to start using the second authentication factor. To check the authentication result, two additional properties are used: HTTPRequestForChekingTheAuthenticationResult and MethodOfHTTPRequestForCheckingTheAuthentication Result.

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

When forming an HTTP request (for setting any property), one should keep in mind the following features:

• The HTTP method is specified as a string. This is because the HTTP specification allows the use of custom verbs (methods).
• The request text may contain parameters. Parameters ‑ is some text starting with the "&" character. For example, you can use the & user_name parameter to specify a user name. 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 an SMS message with the code of the second factor will look like this: . When sending a request, the & phone_number parameter will need to be replaced with the user's actual phone number.

  The platform provides a 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 = TemplatesOfSettingsOfTheSecondFactorOfAuthentication.CreateTemplate();
Provider.HTTPRequestForAuthentication = Request;
Provider.HTTPRequestMethodForAuthentication = "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.

As probably it has already become clear if it is necessary to create a template for the provider of the second factor working according to the second option (all actions are executed by the provider itself, the platform only initiates the operation start and requests the authentication result), then the above example should be processed in such a way that:

• The authentication request met the requirements of the provider used.
• A request was generated (and set in the template) to check the authentication results. This request will be executed after the user "inform" the client application that he had passed authentication with the provider.

After we saved one or several templates for providers, it became possible to 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:

• SettingSecondAuthenticationFactor ‑ here you need to assign an array of objects of the SettingSecondAuthenticationFactor type.
• ProcessingSettingsForTheSecondAuthenticationFactor ‑ describes what the platform will do if several providers of the second factor are specified, and the first (in the traversal order) provider returned an error.

After specifying the above properties, the object describing the Infobase user should be recorded.

We need to consider the last moment: where will the platform get the values that will be substituted for the variables in HTTP requests? To do this, we’ll take a closer look at the SettingSecondAuthenticationFactor object. This object contains two fields:

• SettingsTemplateName ‑ here you should specify the name of the template of the setting of the second-factor provider, 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). The key of the correspondence element is the name of the parameter (without the "&" character), and the value ‑is the value of the variable.

Now we have all the information in order to indicate to the Infobase user the necessity to execute two-factor authentication when entering the Infobase.

ProviderParameters = New Map;
ProviderParameters.Insert("addr", "http://hostname/resource");
UserSettings = New SettingSecondFactorOfAuthentication;
UserSetting.SettingTemplateName = "Question - answer";
UserSetting.Parameters = ProviderParameters;
 
UserSettings = New Array;
UserSettings.Add(UserSetting);
 
User = InfobaseUsers.SearchByName("Seller");
User.SettingsOfSecondFactorOfAuthentication = UserSettings;
User.ProcessingOfSettingOfTheSecondFactorOfAuthentication = TypeOfProcessingOfSettingsOfTheSecondFactorOf Authentication.UseNextInCaseOfError;
User.Record();

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

• property HTTPRequest.ResourceAddress;
• property HTTPRequest.Headings;
• body of object request HTTPRequest (the method of specifying the request body does not affect the substitution work);
• property TemplateOfSettingOfTheSecondFactorOfAuthentication.HTTPRequestMethodForAuthentication;
• property TemplateOfSettingOfTheSecondFactorOfAuthentication.HTTPRequestMethodForCheckingAuthenticationResult.

It remains to mention that if the provider of the second factor selected for the user is "broken",‑ the user can not get access to the Infobase. In this case, the term "broken" means any event that does not allow the provider to complete its task: there is no Internet for access from the server to the provider, there is no Internet for access from the provider to the user, an error has occurred on the provider’s side, etc.

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.

OpenID Authentication and two-factor authentication

The 1C:Enterprise program system supports authentication using the OpenID protocol. If the information system uses OpenID authentication, then the second factor should be requested by the OpenID provider. This is true, including if the 1C:Enterprise system Infobase is specified as an OpenID provider. In other words, two-factor authentication must be configured in the Infobase that is the OpenID provider.