Overview

The following table maps what each data source support

Data Source Sessions Nonces Tokens Devices Credentials Accounts Attribute Enrichment Dynamic Clients Database Clients Buckets Multi-Tenancy
JDBC x x x x x x x x x x x
LDAP         x x x        
SCIM 1.1       x* x x          
SCIM 2.0       x* x x x        
JSON / REST         x   x     x x
DynamoDB x x x x x x x x x x x

* Scim 1.1 and 2.0 support devices if they are stored on the User Account object. The Devices is not used.

Note

Dynamic Clients refer to Dynamic Client Registration, while Database Clients refer to Database Client Management.

Note

Multi-tenancy refers to Authentication Profile Multi-Tenancy

Configuration Strategy

Data Sources are general facilities that are referenced throughout the system. A good configuration pattern is to name the Data Source based on usage rather than type. For systems with many different data source this helps when migrating between environments. The only update needed to the data-source configuration during migration is in the facilities section with url, and credentials for the backend.

Good naming examples:

  • DefaultDataSource - everything is stored in a single DB
  • UserDataSource - Users and Credentials
  • SessionDataSource - Tokens, sessions etc

Bad naming examples:

  • MicrosoftSqlServerDataSource - too specific, might change
  • StageDataSource
  • ProdDB

When naming the data source after environment, then all references in the configuration needs to be updated which is a more cumbersome migration.

Data Source Usage

The Data Sources are used differently depending on what purpose Curity is used with. Common patterns are described below.

Authentication Service

The authentication service uses the data source for session tracking and for user data retrieval and updates.

Type of data Frequency Description
Sessions high Used on every authentication to track the user flow
Nonces high Used on every authentication to track the user flow
Devices low Used when authenticating with 3rd party devices such as Encap
Credentials medium Used when authenticating using Username and Password
Accounts low Used to lookup account data such as Email or Phone number (sms auth or email auth)
Attribute Enrichment - Used by transformers to add more data to logged in user object
Buckets - Used by events or transformers to store arbitrary data

Note

Session data is heavy on both read and write. It is a single table with simple data.

Account and Credential Management

Depending on datasource type the Account Management and Credential Management features can differ. This section creates an overview of the supported features.

Data Source Create Account Activate Account Link Account List Links Resolve Links Verify Credentials Update Password Credential attributes 1 Delete Credential
JDBC x x x x x x x x 3 x 3
LDAP x x x x x x x   4
SCIM 1.1 x x x x   x x   4
SCIM 2.0 x x x x x 2 x x   4
JSON / REST           x x    
DynamoDB x x x x x x x x 4

1 When credential policies are enabled the Curity Identity Server needs to store additional attributes with credentials. If the data source used for credentials does not support this feature, a bucket data source needs to be configured on the credential manager to be able to use credential policies.

2 Resolve links in Scim 2.0 works if the SCIM backend supports filter queries on the externalIds attribute. This is a non-standard element.

3 Requires standard credential mode.

4 Account and credential data is managed as a whole, so when an account is deleted, this is reflected in Credential Management. Deleting credential data only is not supported.

The ‘Resolve Links’ operation does a lookup on the linked account to find the original account. This is not available in some backends due to how the account is structured in the data source.

Token Service

The token service issues new tokens and introspects tokens. This means a mix of reads and writes, but commonly heavy on the writes.

Type of data Frequency Description
Tokens high Every issued access token and refresh token is written. Read on introspect and refresh
Nonces (tokens) medium Every code flow starts with a Nonce, it is updated to be marked as expired after use
Delegation (tokens) medium Every new grant creates a delegation. Refresh does not, it reuses delegation
Clients medium Writes on new clients, read on token issuance to verify credentials.
Accounts low Used by UserInfo or custom token procedures
Attribute Enrichment - Used by token procedures if configured
Buckets - Used by token procedures if configured

User Management Service

User management is a different service in that it is normally not used in the regular flows. It provides user information to systems needing it on demand. Therefore, it cannot be said in general what database load the User Management service produces.

The user management service acts as a SCIM proxy on top of an existing data source. If the underlying data-source is not optimized for the queries that the SCIM service receives, the system may perform poorly. Therefore, always analyze the requests coming in to the SCIM server and make sure the underlying data is indexed properly.

Type of data Frequency Description
Delegation (tokens) low Depends on usage of the /Delegations route.
Accounts high Main lookup, both read and write from the /Users route
Tokens high Every request presents a token that needs to be introspected (read only)
Attribute Enrichment - May be used if added, read only from /Users route

Important

SCIM provides a powerful filter query language. Curity support a large number of these queries. If queries are made against un-indexed elements in the data source frequently it is strongly recommended to index that element. Consult your data base documentation for more details.

Caching Service

Ephemeral data which has a very short life, such as Sessions and Nonces, can be stored via the Caching Service.

Currently, any data source that supports both Sessions and Nonces can be used as a Caching Service.