Overview#
Depending on where a data source is used, the configuration system will determine if the selected data source supports the operations. For example, the LDAP data source can be used to lookup accounts and credentials, but cannot be used to store tokens. Attempting to configure it as a token store will be aborted by the Curity Identity Server.
The following table maps what each data source supports
| 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 |
| MongoDB | 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.
Dynamic Clients refer to Dynamic Client Registration , while Database Clients refer to Database Clients Management .
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, and throttlers’ metadata |
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 |
| MongoDB | x | x | x | x | x | x | x | x | x |
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 |
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.