.. _policy_best_practice:

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.

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.

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.

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.