7.5. Enrollment policies¶
The scope enrollment defines what happens during enrollment either by an administrator or during the user self enrollment.
Enrollment policies take the realms, the client (see Policies) and the user settings into account.
Technically enrollment policies control the use of the REST API Token endpoints and specially the init and assign-methods.
Technically the decorators in API Policies are used.
The following actions are available in the scope enrollment:
7.5.1. max_token_per_realm¶
type: int
This is the maximum allowed number of tokens in the specified realm.
Note
If you have several realms with realm admins and you imported a pool of hardware tokens you can thus limit the consumed hardware tokens per realm.
7.5.2. max_token_per_user¶
type: int
Limit the maximum number of tokens per user in this realm.
Note
If you do not set this action, a user may have unlimited tokens assigned.
7.5.3. tokenlabel¶
type: string
This sets the label for a newly enrolled Google Authenticator. Possible tags to be replaces are <u> for user, <r> for realm an <s> for the serial number.
The default behaviour is to use the serial number.
Note
This is useful to identify the token in the Authenticator App.
Warning
If you are only using <u> as tokenlabel and you enroll the token without a user, this will result in an invalid QR code, since it will have an empty label. You should rather use a label like “user: <u>”, which would result in “user: ”.
7.5.4. autoassignment¶
type: string
allowed values: any_pin, userstore
Users can assign a token just by using this token. The user can take a token from a pool of unassigned tokens. When this policy is set, and the user has no token assigned, autoassignment will be done: The user authenticates with a new PIN or his userstore password and an OTP value from the token. If the OTP value is correct the token gets assigned to the user and the given PIN is set as the OTP PIN.
Note
Requirements are:
- The user must have no other tokens assigned.
- The token must be not assigned to any user.
- The token must be located in the realm of the authenticating user.
- (The user needs to enter the correct userstore password)
Warning
If you set the policy to any_pin the token will be assigned to the user no matter what pin he enters. In this case assigning the token is only a one-factor-authentication: the possession of the token.
7.5.5. otp_pin_random¶
type: int
Generates a random OTP PIN of the given length during enrollment. Thus the user is forced to set a certain OTP PIN.
Note
To use the random PIN, you also need to define a pinhandling policy.
7.5.6. pinhandling¶
type: string
If the otp_pin_random
policy is defined, you can use this policy to
define, what should happen with the random pin.
The action value take the class of a PinHandler like
privacyidea.lib.pinhandling.base.PinHandler
.
The base PinHandler just logs the PIN to the log file. You can add classes to
send the PIN via EMail or print it in a letter.
For more information see the base class PinHandler.
7.5.7. otp_pin_encrypt¶
type: bool
If set the OTP PIN of a token will be encrypted. The default behaviour is to hash the OTP PIN, which is safer.
7.5.8. lostTokenPWLen¶
type: int
This is the length of the generated password for the lost token process.
7.5.9. lostTokenPWContents¶
type: string
This is the contents that a generated password for the lost token process should have. You can use
- c: for lowercase letters
- n: for digits
- s: for special characters (!#$%&()*+,-./:;<=>?@[]^_)
- C: for uppercase letters
Example:
The action lostTokenPWLen=10, lostTokenPWContents=Cns could generate a password like AC#!49MK)).
7.5.10. lostTokenValid¶
type: int
This is how many days the replacement token for the lost token should be valid. After this many days the replacement can not be used anymore.