Making the change to remote work?
We're happy to help you stay connected

Learn more
, , ,

Intermedia AppID’s security architecture: What makes our SSO solution so secure?

Many customers ask me why we’re so confident about the security of our single sign-on solution, Intermedia AppID. As well they should. After all it’s best practice to thoroughly vet any cloud solution. And ultimately it’s your business and your data.  You need to ensure it’s protected.

General security features of AppID

The AppID solution has two key elements: the AppID server and the AppID browser extensions. The fundamental architecture, with a component in the browser, enables us to embed enterprise-grade security in a service that is relevant and accessible to SMEs. The security used in AppID is far greater than that used in consumer password managers that often store passwords on the end device itself.

Key details of AppID’s security architecture include:

  • Multiple layers of encryption are used to protect data in transit. Server and client use a combination of 2048-bit asymmetric encryption (RSA) for communication and 256-bit symmetric encryption (AES) for sensitive data.
  • All communication is over HTTPS secured by TLS, and is locked to a specific session. A configurable time-out destroys the session, after which the user is required to re-authenticate.
  • AppID usernames and passwords are never stored on the client.
  • The plug-in password is stored server-side, hashed and salted, using an adaptive function with multiple rekeying rounds.
  • When a user authenticates to the plug-in, a universally unique ID (UUID) is generated for each cloud application.
  • UUIDs are encrypted, sent to the plug-in, and held in memory.
  • When the user visits a login page, the UUID is used to retrieve credentials that are then injected into the page. Credentials are never kept on the client in memory or persisted to disk.

How AppID secures tenant data access

Access requests to data on the AppID server are secured using a wide range of different techniques and methods. All requests occur over HTTPS with session validation and are locked to a specific tenant by adding elements to the underlying Java thread.

Database access takes place through an access layer requiring validation of the tenant’s primary key. Any requests that do not have the key are terminated. All data returned is validated as belonging to the tenant. At the end of the request, the tenant data is removed from the Java thread.

Protecting tenant data

Here’s how tenant data is protected on AppID servers:

  • All communication with the server is encrypted using the strongest encryption algorithm available to the end-user’s browser. In most cases, this is symmetric 128-bit AES, with key exchange over RSA using a 2048-bit key.
  • Communication of the underlying data to the tenant’s extensions uses either a tenant-specific or per-user AES 256-bit encryption key. Data from one tenant cannot be decrypted by a user in a different tenant.
  • All authentication credentials are encrypted using a tenant-specific AES 256-bit encryption key, used specifically for storage (data at rest). This key is different than that used for communication.

Use two-factor authentication for extra protection

Intermedia AppID includes two-factor authentication that can be enabled to further protect access to sensitive applications for all employees, or just a subset of them. A session timeout period can also be set, so you can control how often users have to re-enter their Intermedia AppID login credentials.

If you have any questions about these security measures, please call us at 1-800-379-7729. Or learn more about the benefits of Single Sign-On (SSO) technology and Intermedia AppID.

About Carles Cabre

Carles Cabre is Intermedia's head of product marketing for SecuriSync and our Analyst Relations manager.