Atura Security

At Atura, we take security seriously. When interacting with an AI assistant, end-users will often supply sensitive information, and we need to be careful how this information is transmitted and stored.

The diagram below shows protocols used between internal bot components as well as external components. It also details the authentication/authorisation mechanism.

Security protocols

Messages are usually transmitted over HTTPS (HTTP over TLS), with the exception of Service Bus messages (which use Advanced Message Queuing Protocol (AMQP)), and Bot Framework communication with the bot front-end (which uses secure web sockets).

Webchat Widget "Handshake"

The webchat widget requires a JWT token in order to communicate with the Bot Framework. This token is obtained via a "handshake" between the webchat widget and the bot web service. This ensures that the webchat widget running in the user's browser never has access to the bot secret (which is only ever stored on the "server" in the Bot Framework). The handshake process is visualised below:

Handshake

Steps followed for the handshake:

  1. The web page that contains the webchat widget loads. This immediately causes the webchat widget to send a GetNewToken request to the bot web service. No authentication is needed on this call since it's a new, unauthenticated user.
  2. The bot web service uses Bot Framework APIKey and Secret (which is never shared with webchat widget) to request a temporary JWT token from the Bot Framework's Directline channel.
  3. The temporary JWT token is returned to the webchat widget.
  4. The webchat widget uses the token when communicating with the Bot Framework.

The token expires after a few minutes, and the webchat widget calls the RefreshToken service to refresh the token. The refresh happens in the background, so the user is not impacted by the request. An expiring token system means that if a token is ever compromised (intercepted or stolen somehow from the user's machine) that the window for use by a nefarious party is as small as possible.

Service Desk Login

The following diagram from Microsoft (https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-implicit-grant-flow ) illustrates how the login handshake between the Service Desk ("browser") and Service Desk web services ("Web API") works:

Consultants may access the Service Desk by signing into a client-specific Azure Active Directory (AD) tenant. Atura typically creates a new Azure AD tenant for each client, but we also have the flexibility to use an existing tenant if the client has one. For example, we can configure Azure AD Connect to synchronise Service Desk users with a client's existing on premise Active Directory instance. If a new tenant is created, it is managed by Atura.

Authentication is performed from the front end, using the Microsoft ADAL JavaScript library. This library uses the OAuth implicit grant type flow.

References

Single Page App login flow with OAuth implicit grant: https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-implicit-grant-flow

ADAL login library source code: https://github.com/AzureAD/azure-activedirectory-library-for-js

Azure AD Connect: https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnectsync-whatis

Data Encryption

Messages are always encrypted in transit, as shown in Figure 1.

  • ··Azure Table Store - conversation data is encrypted at rest (on disk) with 256 bit AES encryption, and in transit over HTTPS with HTTPS encryption.
  • ··Cosmos DB - data is encrypted at rest (on disk) and in transit.

References

Table Store encryption at rest: https://docs.microsoft.com/en-us/azure/storage/common/storage-service-encryption

Cosmos DB encryption at rest and in transit: https://docs.microsoft.com/en-us/azure/cosmos-db/database-encryption-at-rest

End User Login

It is possible to allow end users to log in to client systems via the chat interface. For example, this would be necessary when an end user uses an AI assistant to log in to the fictional business "BankX" using the BankX-App on their smart phone. Logging in allows the user to complete financial transactions using their bank accounts via the AI assistant. Many approaches to facilitate this are possible, depending on how the client system stores user information and what method they use for authentication. A typical approach is shown below:

End user login

Steps followed to log in:

  1. User requests a login to the client's back-end system. The login request arrives at the bot.
  2. The bot starts the login process by calling a /startLogin web service on the client's Login API. The bot receives a polling token to use in step 4.
  3. The client Login API sends an authentication request to the app on the end-user's mobile phone. This is driven purely by the client's API code, not Atura or AI assistant code.

If the user approves the login request, a client system authentication token is returned to the Client Login API.

This step can be performed in several ways, depending on the client's preference and existing system requirements. Possible login mechanisms include:

  • Login on the end-user's mobile phone with USSD ("Accept" / "Deny" prompts).
  • Login with OTP from the end-user's mobile phone, email address or Google authenticator.

Please note that we discourage sending a username and password through the AI assistant, as Atura and the Microsoft Bot Framework will then have access to the user's credentials in plain text.

  1. The AI assistant polls the Client Login API using the polling token until the API returns the client system authentication token (or fails or times out, in which case the bot either refreshes the token or requests that the user log in again, depending on the API's requirements).

  2. The client system authentication token is returned to the AI assistant and is encrypted and stored in memory. The token is never transmitted to the Bot Framework or the front-end chat widget.

Azure Security

Since Atura runs on the Microsoft Azure platform, our clients benefit from Microsoft's stringent security standards. This means that any AI assistant we build complies with international security standards and will automatically incorporate the latest advances in security technology.

You can access the following page for more information about security on Microsoft's cloud platform:

https://docs.microsoft.com/en-us/azure/security/

Or visit Microsoft's Trust Centre for the official Azure security compliance certifications: https://www.microsoft.com/en-us/trustcenter/compliance/complianceofferings