6.16. Best practice - policy example

Here is an example to give you an idea about the policies.

Think about a scenario, where there is an administrator “superadmin”, who is allowed to do anything within LinOTP. Then there is an administrator “issuer”, who is allowed to enroll and manage tokens. Finally there is the user help desk “uhd”, who is allowed to solve problems of the users.

The users are allowed to enroll Google Authenticators in the Selfservice Portal.

Now lets take a look at the policies.

6.16.1. Administrators

The policies for the “superadmin” look like this:

[policy1]
scope = admin
action = *
user = superadmin
realm = *

[license1]
scope = license
user = superadmin
action = setlicense

According to policy policy1 and license1 the “superadmin” is allowed to do all administrative tasks in all realms and also to set the license.

There need to be policies for the other administrators:

[policy2]
scope = admin
action = initHMAC, resync, setOTPPIN, userlist, assign, unassign, remove, reset, set, import
user = issuer
realm = *

[policy3]
scope = admin
action = reset, setOTPPIN, losttoken, resync, enable, disable
user = uhd
realm=*

The administrator “issuer” is allowed to initialize tokens, set PINs, assign and import tokens. So roughly all token managing tasks. He is not allowed to enroll any other tokens than HMAC tokens and he is not allowed to move tokens between realms (missing action manageToken).

According to policy policy3 the administrator “uhd” is only allowed to reset the fail counter of a token, to set the PIN or enable or disable the token. The user help desk is not allowed to enroll new tokens or remove tokens.

6.16.2. System

To avoid the changing of policies and also other system settings, we need to define some system policies:

[syspol1]
scope = system
action = read, write
user = superadmin

Only the “superadmin” is allowed to read the system configuration and also change the system configuration. All other administrators can not see or change the system config. i.e. they also can not see the policies.

6.16.3. Selfservice

It is now completely up to you which kind of selfservice policies you want to define. But given, that the users should be able to enroll a Google Authenticator on their own, this could look like this:

[selfpol1]
scope = selfservice
realm = realm1
action = webprovisionGOOGLE, reset, resync, setOTPPIN, disable

[enroll1]
scope = enrollment
realm = realm1
action = maxtroken = 2

The policy selfpol1 defines, that the user is allowed to enroll a Google Authenticator and that he can set the PIN and reset the fail counter in the Selfservice Portal. He would be also able to disable his token - which could only be enabled by the user help desk again. The policy enroll1 limits the allowed number of tokens of a user to a maximum of 2.