Page tree
Important notice! This documentation is out of date and refers to Soffid version 2

Soffid 3 documentation is available https://bookstack.soffid.com

Skip to end of metadata
Go to start of metadata


In order to adapt identities to the particularities and requirements of each user repository, the following items are available:

  • User domains

  • Password domains

  • User types

  • Password policies




User domain

A user domain defines how account names will be created based on user name and related attributes. So, a user named jsmith can be identified as jsmith on Soffid and ActiveDirectory, john.smith on Lotus Notes and jsmith@soffid.com on the mail server. There are three types of user domains:

  • “Main user name” domains, the account name will be the same as the user name.

  • For “scripted” user names, a bsh script based on the user information can be specified. For details, look at the Account naming rules script page

  • If needed, developers can add new complex procedures to assign account names. Once they are uploaded as addons, they are available to be assigned to any user domain.

Password domain

Is a logical way of grouping managed systems that are sharing the same password for each user. If administrator chooses to have the same password for every system, only one password domain should exist. If administrator chooses to assign different password for each system, then a password domain should be created for each managed system.

User type

In order to use different password policies we will use different user types. For example, internal user (automatically created) are different from external ones. On this way, the policy for external user can be less restrictive because this kind of users have less risk.

Password policy

For each password domain is possible to create different password policies depending on the user types.

There are two kind of password policies. The first ones is for user selected passwords. This is the default behaviour. The second ones are system generated passwords. These policies are useful for shared accounts when using Enterprise Single Sign-on.

A password policy will also define how often the password needs to be changed and how many days are allowed to change it.

Regarding password complexity, you can specify minimum and maximum number of lowercase letters, uppercase letters, numbers and symbols, as well as password length.

Administrator can define a regular expression that must match each password. This can be used, for example. to ensure that the first password is not numeric.

More and more, administrator can create a list o forbidden words that cannot be used as password.


  • No labels