.. _self_service_policies: Selfservice policies -------------------- If you want to define policies for users accessing the Selfservice Portal, you need to enter: * *Policy name* : "your policy name" * *Scope* : “selfservice” * *User* : "\*, username, regex" for details show :ref:`users_in_policies` * *Realm* : "\*, realmname" You need to put a realm name into the realm field. Then this policy will work for all users within this realm logging in to the Selfservice Portal. You can also put a `*` into the realm field, thus the policy will be valid for all realms. * *Client* : "FQDN, IP-Addr, Network" You may add clients in this policy so that you can define a different behaviour within the Selfservice Portal depending on from where the user will log in to the Selfservice Portal. For details show :ref:`clients_in_policies`. * *Time* : Empty means any time You can now add actions to the resulting users from the realms. Valid *actions* are: ``mfa_login`` Starting with LinOTP 2.10 the login to the Selfservice Portal can be protected with a second factor. This requires the user to have at least one working token for the log in. If the user have multiple tokens a selection menu is displayed. Auto Assignment of tokens works for the log in to the Selfservice Portal :ref:`policy_autoassignment`. ``mfa_3_fields`` This options alters the MFA Selfservice Portal login dialog to show 3 fields (username, password, OTP). The action can only be used as extension to **mfa_login**. ``mfa_passOnNoToken`` If the user does not have a token, this action allows the login without OTP. If the user has a token assigned, the OTP of the token is required. ``enrollPUSH`` The user is allowed to self enroll a KeyIdentity Push token (new in version 2.9.1). To use the token, the activation is necessary. ``activate_PushToken`` The user is allowed to activate his Push Token. ``enroll_QR`` The user is allowed to self enroll a KeyIdentity QR Token (new in version 2.9). To use the token, the activation is necessary. ``activate_QRToken`` The user is allowed to activate his QR token. ``enrollEMAIL`` The user is allowed to self enroll an email token (new in version 2.8). ``edit_email=<0|1>`` Set to '1' to allow the user to set their own mail address for a self enrolled email token (this is the default). If set to '0', the address is received from the UserIdResolver. ``enrollSMS`` The user is allowed to self enroll a SMS token (new in version 2.8). ``edit_sms=<0|1>`` Set to '1' to allow the user to set the mobile number for a self enrolled SMS token (this is the default). If set to '0', the number is received from the UserIdResolver. ``enrollHMAC`` The user is allowed to self enroll a HMAC token. ``hmac_hashlib=`` The hashlib is an integer... ``hmac_otplen=`` The otplen is an integer value for the number of characters in the otp ``max_count_hotp=`` User may retrieve future OTP values of HOTP/HMAC tokens. Please refer to `Retrieving OTP values`_ for details. ``enrollMOTP`` The user is allowed to self enroll a mOTP token. ``setMOTPPIN`` The user is allowed to reset/set the mOTP PIN of his mOTP tokens. ``enrollOCRA2`` The user is allowed to self enroll an OCRA2 token. To use the OCRA2 token, the activation is necessary. ``activateOCRA2`` The user is ahllowed to activate his OCRA2 token. ``activateQR`` The user is allowed to activate his OCRA token. ``enrollTOTP`` The user is allowed to self enroll a TOTP token. ``totp_hashlib=`` The hashlib is an integer... ``totp_timestep=`` The timestep is an integer... ``max_count_totp=`` User may retrieve future OTP values of TOTP tokens. Please refer to `Retrieving OTP values`_ for details. ``enrollU2F`` The user is allowed to self enroll a U2F token (new in version 2.8). ``enrollYUBICO`` The user is allowed to self enroll a YUBICO token. ``max_count_dpw=`` User may retrieve future OTP values of Tagespasswort tokens. Please refer to `Retrieving OTP values`_ for details. ``webprovisionGOOGLE`` The user is allowed to enroll a HMAC Google authenticator token via web provisioning. [#ssoath]_ ``webprovisionGOOGLEtime`` The user is allowed to enroll a TOTP Google authenticator token via web provisioning. [#ssgoogle]_ ``assign`` The user is allowed to assign an already imported token to himself. ``unassign`` The user is allowed to unassign his own tokens. ``enable`` The user is allowed to enable his disabled tokens. ``disable`` The user is allowed to disable his own tokens. ``delete`` The user is allowed to delete his own token. This token will be removed completely from the database, but will remain in the audit trail. ``reset`` The user is allowed to reset the failure counter of his tokens. ``resync`` The user is allowed to resynchronize his HMAC tokens. ``getserial`` If this action is active, the token can be assigned by entering the OTP value. You also need to specify the action ``assign``. On the assign tab an additional entry for the OTP value will be displayed. ``getotp`` The getotp tab will be displayed. Additionally the linotp.ini file needs to be adapted and a policy max_count for the token type needs to be defined. ``setOTPPIN`` The user is allowed to reset/set the OTP PINs of his tokens. ``otp_pin_minlength`` Configures the minimal length of the PIN set by the user. For further details see `OTP PIN policies`_. ``otp_pin_maxlength`` Configures the maximal length of the PIN set by the user. For further details see `OTP PIN policies`_. ``otp_pin_contents`` Configures allowed characters for the PIN. For further details see `OTP PIN policies`_. ``show_landing_page`` this action displays a landing page after the successful login of a user in to the selfservice portal. The content of this page can be customized as described here: :ref:`customization`. ``history`` If this action is active, the user will see a tab with a list (like :ref:`audit_trail`) of all actions he did or all the actions an administrator performed on his tokens. Starting with LinOTP 2.5.2 you can also put users or resolvers in the `user` field. For an explanation on this take a look at :ref:`users_in_policies`. OTP PIN policies ~~~~~~~~~~~~~~~~~ Policies on how the OTP PIN should look like can be defined for the self service portal. Thus the administrator can assure, that the user chooses a OTP PIN that is secure enough to his opinion. OTP PIN policies will be checked whenever a user tries to reset an OTP PIN in the Selfservice Portal. The policies are defined like this:: scope = selfservice ``realm`` A list of comma separated realms, the policy should apply to. ``action`` Allowed actions are followed by a number or character codes. The actions can be comma separated. * otp_pin_maxlength=12 This action would define that the user is only allowed to set OTP PIN with a maximum length of 12 characters. * otp_pin_minlength=4 This action would define that the user needs to set an OTP PIN that is at least 4 characters long. * otp_pin_contents=cnso This action defines, what characters need to be contained in the OTP PIN: - c: Only OTP PINs containing at least one letter character will be accepted. - n: Only OTP PINs containing at least one digit character will be accepted. - s: Only OTP PINs containing at least one special character will be accepted. - o: Only OTP PINs containing at least one special character, that is not contained in the other character groups, will be accepted. Example: So if you want your users to choose OTP PINs, that contain letters and number and that should be between 6 and 8 characters long, you should define an action like this: otp_pin_maxlength=8, otp_pin_minlength=6, otp_pin_contents=cn Character groups ................ The character groups are defined like this. The default for characters (letters) “c” is the regular expression:: [a-zA-Z] The default for digits “n” is the regular expression:: [0-9] The default for special characters “s” is the regular expression:: [.:,;-_<>+*!/()=?$§%&#~^] The character group “o” contains all characters, that are not contained in one of the above groups. Changing the character group definition ....................................... These regular expressions can be changed in the linotp.ini file using these parameters:: linotpPolicy.pin_c = [a-ZA-Z] linotpPolicy.pin_n = [0-9] linotpPolicy.pin_s = [.:,;-_<>+*!/()=?$§%&#~\^] .. note:: Some characters need to be escaped using the “\\”. So if you want the OTP PIN to have an upper letter at any cost, you may change the linotpPolicy.pin_c = [A-Z] and an otp_pin_contents = c. Then setting the PIN will complain, if it does not contain an upper letter. Reversing the OTP PIN logic ........................... The default logic is that the OTP PIN must at least contain the specified characters and may contain any more characters, digits or signs that are not required. There are two prefixes to change this logic * -: The minus sign will require to contain the specified character groups, but will require, that the characters not specified are not used in the OTP PIN. Examples: - -cn: This will require the OTP PIN to contain at least a letter and a digit. But as soon as the OTP PIN contains a special character or any other character the OTP PIN will not be valid. A PIN like “a12” or “b12” would be OK, but a PIN like “abc” or “test!” would not be valid. - -s: The OTP PIN may only contain the specified special characters, not any digits, letters or other characters. * +: The plus sign will combine the specified character groups. It will require, that characters from any of the character groups are contained in the PIN, but characters not in the character groups must not be contained in the PIN. Example: - +cn: The PIN needs to contain letters or digits, but must not contain any special characters. A PIN like “123”, “abc”, “a12” would be OK. Example: If you want to have the user always use PINs that are exactly 4 digits long, you can set: otp_pin_maxlength=4, opt_pin_minlength=4, otp_pin_contents=-n Retrieving OTP values ~~~~~~~~~~~~~~~~~~~~~ In the scope=selfservice you can define the following actions: * max_count_dpw= for retrieving OTP values of Tagespasswort tokens. * max_count_hotp= for retrieving OTP values of HOTP/HMAC tokens. * max_count_totp= for retrieving OTP values of TOTP tokens. These actions are the equivalent to the gettoken actions (see :ref:`gettokenpolicies`). When these actions are defined, the user in such a realm is allowed to retrieve future OTP values of his own OTP tokens. You need to also specify the policy scope=selfservice, action=getotp and edit the linotp.ini file to enable OTP retrieval. .. [#ssoath] See this OATH token: http://code.google.com/p/oathtoken/ .. [#ssgoogle] See the Google Authenticator: http://code.google.com/p/google-authenticator/