Overview

The following table maps what each data source support

Data Source Sessions Tokens Devices Credentials Accounts Attribute Enrichment Dynamic Clients Buckets
JDBC 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    

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

Configuration Strategy

Data Sources are general facilities that are referenced through out 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 purpuse 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
Devices low Usen 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
JDBC x x x x x x x
LDAP x x x x x x x
SCIM 1.1 x x x x   x x
SCIM 2.0 x x x x x* x x
JSON / REST           x x

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

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 refersh 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
Dynamic 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 recieves, 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 Frequence 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 frequenly it is strongly recommended to index that element. Consult your data base documentation for more details.