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.
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
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
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.
To avoid the changing of policies and also other system settings, we need to define some
[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.
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
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.
enroll1 limits the allowed number of tokens of a user to a maximum of 2.