Autonomous Identity 2022.11.12

Security controls overview

PingOne Autonomous Identity uses a number of security protocols as summarized below.

Security Controls Summary

Security

Description

Encryption Protocol

TLSv1.2

Encryption: External Data in Transit

All data in transit from PingOne Autonomous Identity to the outside world is encrypted. SSL certificates must be configured with the load balancer. By default, PingOne Autonomous Identity configures self-signed certificates used by Nginx. Customers can also use their own certificates during deployment.

Encryption: Internal Data in Transit

Within the PingOne Autonomous Identity secure server network, most data in transit between the PingOne Autonomous Identity services is encrypted, but not all. The exception is any non-encrypted communication between PingOne Autonomous Identity servers. You can protect this communication via network firewalls.


It is also recommended to disable access on network and firewall ports for services like Spark and Livy that are meant for internal access only. The rest of the services are SSL/TLS-protected including all Nginx-protected services, MongoDB, Cassandra, and Opensearch nodes.

Encryption: Data at Rest

MongoDB is not encrypted natively in PingOne Autonomous Identity, but can be encrypted via third-party disk encryption or using the MongoDB enterprise version. If encryption at rest is required, please confirm with the MongoDB vendors how this is handled in existing MongoDB clusters.


Likewise, Cassandra is not natively encrypted, but can be supported through its enterprise versions.

Authentication

PingOne Autonomous Identity uses various authentication methods within its systems, such as the following:

  • Local Authentication. User credentials (user/groups) are stored in Opensearch. Users can log in with a username and password. This is mostly used for development or QA scenarios.

  • OpenID Connect. PingOne Autonomous Identity can use Single Sign-On (SSO) by integrating SSO providers like Azure AD and ForgeRock® Access Management (AM).

The API service and Java API Service (JAS) are protected by authentication handlers that support token-based access. JAS also supports certificate-based authentication, which is only used by internal services that require elevated access.