Share via

Setting Authentication

  • Article

For the RTC Client API version 1.0, the application is able to specify the authentication mechanism in the provisioning profile. The RTC Client 1.0 profile allows the Basic and Digest authentication methods to be specified in the <auth> tag of the XML profile. Because Basic and Digest are considered relatively weak mechanisms, the NTLM and Kerberos authentication methods are introduced for RTC Client 1.2.

RTC Client 1.0 set the authentication levels to the minimum; however, it allowed incoming sessions with a higher level of required authentication to increase the authentication level for the session if the server supported the authentication method. For the RTC Client 1.2 applications, the allowed authentication methods are specified in the allowedauth element of the profile. The server will accept challenges only for methods specified in the <allowedauth> tag or the <auth> tag.

Initially, the application creates the profile with the IRTCClientProvisioning::GetProfile method. Once the profile is created, the application calls the IRTCProfile2::put_AllowedAuth method to update the allowed authentication methods on the profile. The IRTCProfile2::get_AllowedAuth method retrieves the authentication levels stored on the profile. If the IRTCProfile2::put_AllowedAuth method is not called, by default, the RTC Client API will enter NTLM and Kerberos in the <allowedauth> tag.

The <allowedauth> tag can specify Kerberos, NTLM, Digest, and Basic. When an authentication challenge comes into the RTC Client API, the most secure authentication method supported by both the client and the server will be used. The priority order for authentication methods is Kerberos, NTLM, Digest, and Basic. The application can also specify that the NT credentials be used for authentication by specifying “logoncred” in the <allowedauth> tag. The logoncred method cannot be the only method specified in the <allowedauth> tag; at least one other authentication type, such as Kerberos or NTLM, must also be specified with logoncred. It is possible that the server may not challenge the client and, therefore, the client may never be validated.

If the <allowedauth> tag is present in the profile, the RTC Client API will use this tag to determine which authentication scheme to use to answer authentication challenges from the server. If only the <auth> tag is present in the profile, the RTC Client API will use it to answer authentication challenges. If both the allowedauth and the <auth> tags are present, the RTC Client API looks at only the <allowedauth> tag. If the <allowedauth> tag contains the empty string (“”), then the Client API will not respond to any authentication challenges from the server.

If the transport types specified in the profile are TLS or TCP, the default allowedauth setting will be NTLM and Kerberos. The default setting can be overridden by calling the IRTCProfile2::put_AllowedAuth method and specifying the types of authentication to include in the profile.

The process for creating a profile and authenticating the client is as follows:

  1. The application creates the profile with the IRTClientProvisioning::GetProfile method.
  2. The application can set the desired authentication schemes by calling the IRTCProfile2::put_AllowedAuth method and specifying RTCAU_DIGEST and RTCAU_KERBEROS in the lAllowedAuth flags.
  3. The client attempts to register with the server using the IRTCClientProvisioning2::EnableProfileEx method.
  4. The server sends a challenge specifying NTLM and Digest.
  5. The client API checks the <allowedauth> entries for NTLM and Digest.
  6. The profile specifies Digest as the highest supported authentication mechanism, so the Client API will respond with Digest.

Note  Application developers are strongly urged to consider using TLS transport to determine the server’s certificate during an authentication challenge. This helps to prevent a malicious server from intercepting the TLS connection and propagating an attack against the user.

When using the basic authentication scheme, the transport must always be TLS. However, when using the NTLM and Kerberos authentication methods, the transport can be either TCP or TLS.