MongoDB¶

The MongoDB data source uses the MongoDB service to store and retrieve information.

Collections management¶

The Curity Identity Server is shipped with an initialization script for MongoDB. It contains the collection definitions and indexes needed for a standard Curity Identity Server setup.

The collection definitions are found in the installation at <IDSVR>/etc/mongo-create_database.js. Even if MongoDB allows on the fly creation of databases and collections, to benefit from indexes and optimized query performance, make sure it is executed on the target database before starting to use the data-source (plugin).

Multi-Tenancy¶

Multi-tenancy is supported out of the box for MongoDB, there is nothing to configure at data source level. Read more about multi-tenancy and how to configure it at authentication profile level.

Database maintenance¶

The Curity Identity Server relies on external maintenance. Therefore it is important to setup janitor procedures before going into production. However, the following collections are automatically maintained and cleaned up thanks to MongoDB builtin data expiration mechanism.

Collections	Data Lifetime
delegations	Long lived. Each entry is set to expire when Refresh Token expires. See configuration.
tokens	Mixed. Refresh tokens may live long but access tokens shorter.
nonces	Short. Usually valid in the range of minutes.
sessions	Short. Usually valid in the range of hours.
devices	Long lived. Device attributes can be created with an expiry date.

Each item in these collections includes a deletableAt field containing the timestamp after which the item can be deleted. Its value is set to the item’s expiration timestamp, added with a retain duration. This retain duration is configurable per collection and defines the amount of time, in seconds, that an item should be kept in the database after it is considered expired (e.g. for audit purposes). Therefore, it can be used with the MongoDB TTL indexes feature, which automatically deletes items that are no longer needed. Note that this automatic removal mechanism is automatically enabled by Curity Identity Server, a default configured for each item type.

Credential Data Access¶

The MongoDB data source manages account and credential as two separate entities, which means that the data source can be used for standalone credential storage.

By default, the query used to retrieve credential data checks the account status, and no data is returned for inactive accounts. In such cases, the credential verification done by the Curity Identity Server always fails.

Configuration¶

The MongoDB data source configuration model defines the following operation aspects:

Connectivity:
- Connection String to define the connection between the Curity MongoDB client and the MongoDB database.
  - set at least the host, port and database name
  - add query string options, especially to define MongoDB client’s pool size, timeouts, causal consistency and write concerns
- Client Authentication Mechanism, which can be defined as:
  - Password Credential using MongoDB SCRAM-1 or SCRAM-256 user’s name/password authentication mechanism;
  - or, Mutual TLS by referencing a Client SSL Key previously added to the Curity Identity Server configuration in Facilities > Keys and Cryptography > TLS > Client SSL Keys
- Server trust store: The MongoDB server certificate to trust. Setting a trusted server certificate will automatically enable TLS on the MongoDB client. The certificate must be previously added to the Curity Identity Server configuration in Facilities > Keys and Cryptography > Server Trust Stores
Account Additional Attributes: a MongoDB collection storing additional account attributes by subject. This collection allows to enrich accounts with your own custom data. Set the collection name and the field storing the account’s subject.
TTL support:
- Per collection, additional item retain duration.

Causal Consistency and Write Concerns¶

MongoDB uses causally consistent client sessions, In order for the Curity Identity Server to behave correctly, it needs the four guarantees provided by MongoDB: Read own writes, Monotonic reads, Monotonic writes, Writes follow reads.

For that reason, it is highly recommended that the MongoDB data source is configured with Read and Write concerns set to majority. This can be done by adding query string options to the Connection String as follow:

mongodb://localhost:27047/curity?w=majority&readConcernLevel=majority