Data Concepts

This article describes data sources that the Curity Identity Server manages or connects to. We will describe various categories of data, services, configuration, secrets, and logs.

User Accounts and Credentials

You can configure the Identity Server to retrieve user accounts and credentials from a number of different data sources:

• The most popular SQL databases
• Various NoSQL databases
• LDAP data sources
• REST APIs as JSON data sources

User data is sensitive, since it may contain Personally Identifiable Information (PII) such as name, email, and address. It is recommended to let the Identity Server store this data and audit changes to it, and to receive the data in your own systems via tokens.

User Management via SCIM

We provide SCIM 2.0 Endpoints as a standards-based REST API solution for managing users and credentials. This can be used to migrate users in bulk when required and manage them incrementally afterward.

Account Linking Data

When a user signs in via different authenticators, it may be necessary to store user attributes in the linked_accounts table to ensure that your apps receive a consistent identity for the user.

Application Security State

Token data and authenticated session data are both stored in a database, which can be separated from user accounts if required. This security state is queried when a reverse proxy performs token introspection to convert opaque tokens into JWTs that can be forwarded to APIs.

Multi-Tenant Data

The Curity Identity Server can be deployed in advanced ways to support Multi-tenancy. In these setups, data can be stored in either independent data stores or shared data stores with a prefix. This ensures no conflicts between tenants and applies to all types of storage.

Data Events

Events are a general mechanism used to notify your applications of certain occurrences. One data related use case is to notify your own APIs when a user is added or deactivated, via an Event Listener.

Audit Data

Audit data is usually also routed to a database so that who, when and what values are recorded. This enables events such as the following to be queried:

• Authentication events for logins, authenticators used, and logout operations
• Tokens issued, for which clients and users, and with which privileges
• User management events such as new, changed or deactivated users

Configuration Data

Configuration drives the behavior of the Curity Identity Server and also represents your applications as OAuth clients. There is rich support for managing configuration over time via the following methods:

• The Admin UI provides visualization
• The RESTCONF API is commonly used for automation
• The Command Line Interface can be used for live troubleshooting

Where possible, configuration is validated before saving, preventing many types of potential errors. Configuration updates are managed in a transactional manner, enabling the data to be quickly rolled back or forward.

Certificates and Keys

The Identity Server manages secrets such as Client Certificates for Mutual TLS connections to other companies. These are encrypted and backed up in the Configuration XML. They are easily renewed via the Admin UI, RESTCONF API, or CLI.

Technical Logs

The Identity Server uses the popular Log4j 2 open-source toolkit. This outputs various types of logs that can be useful if you need to troubleshoot an issue:

• System logs
• Request logs
• Audit logs

The log levels and log destinations (appenders) are easily customizable. Some or all of these logs can be automatically aggregated from your cluster to a queryable log store such as Elastic Search.

Conclusion

The Curity Identity Server is designed to store User Data and Credentials to externalize such records from business applications. Various other resources are also used for OAuth features to work correctly, and so that access to data is audited.

The next article will cover Deployment Concepts and discuss some real world use cases.