# Access rules #### Contents * [What access rules are?](https://trustelem-doc.wallix.com/books/trustelem-administration/page/access-rules#bkmrk-what-access-rules-ar-0) * [Priorities](https://trustelem-doc.wallix.com/books/trustelem-administration/page/access-rules#bkmrk-priorities) * [Web authentication - Apps SAML, OpendID Connect, and No SSO](https://trustelem-doc.wallix.com/books/trustelem-administration/page/access-rules#bkmrk-web-authentication--) * [LDAP authentication](https://trustelem-doc.wallix.com/books/trustelem-administration/page/access-rules#bkmrk-ldap-authentication) * [Radius authentication](https://trustelem-doc.wallix.com/books/trustelem-administration/page/access-rules#bkmrk-radius-authenticatio) #### What access rules are? * Permissions help define how users can access which apps. * They can ask for simple authentications (login + password), multi factors authentications (login + password + 2nd factor) or deny an access * They can be managed using the tab **Access rules** of Trustelem admin page. * They can be managed using the API * They are some default access rules defined on **Security settings** / **General** / **Default authentication level for users** which allow to control multiple applications access rules with one setting. * For web authentication, you can have a rule depending on the user public IP. If the IP is known the rule **internal** applies, if not the rule **external** applies. **If possible, an access rule should always apply to a group**. Doing that you only have to add users to the right groups to manage the access. It is also a way to have a limited number of access rules and a better visibility. Of course you can still search for a user in the **Access rules** tab to see which permissions are applied, even if they are related to a group. #### Priorities When a user / group is affected by more than one access rule for a single application, the following priorities apply: * 1/ A user access rule wins over a group access rule, whether it is more restrictive or not * 2/ The most restrictive access rule wins In summary: **Access forbidden (user)** > **2 factors (user)** > **1 factor (user) > Access forbidden (group)** > **2 factors (group)** > **1 factor (group)** ##### Example John Doe is in groups "Customer Success" and "Support" and he wants to authenticate on salesforce. Permissions defined: * Subscription default: internal -> 1 factor | external -> 2 factors * Customer Success for salesforce: internal -> 1 factor | external -> 2 factors * Support for salesforce: internal -> 2 factors | external -> forbidden * John Doe for salesforce: internal -> no rule | external -> 2 factors No permission is set to the **default** value, so this setting doesn't apply. For **internal** zone we have 1 factor (customer success) and 2 factors (support) for groups and no rule specified for his account --> the authentication will use 2 factors For external zone we have 2 factors (customer success) and forbidden (support) for groups and 2 factors for his account --> the authentication will use 2 factors again. --> John needs 2 factors to access salesforce for both internal and external zone. #### Web authentication - Apps SAML, OpendID Connect, and No SSO Permissions for this apps may depend on the user's public IP address. In this case, the internal IPs must be defined on **Security settings** / **General** / **Internal network**. Internal IPs are usually the public IPs of the company offices. If the user has a known public IP, the access rule for **internal zone** applies, if not the access rule for **external zone** applies Possible values: * **no rule**: does not apply any rule, so other permissions can remain active *For instance, if you want to overload an existing **external zone** permission, and not a **internal zone** permission, you can set the **internal zone** permission to **no rule*** * **Default**: apply the default rule defined in **Security settings** / **General** / **Default authentication level for users** * **1 factor**: only one authentication factor is needed to access the application (login + password OR certificate OR Kerberos) * **2 factors**: two authentication factors are needed to access the application * **Forbidden**: the user can’t access the application #### LDAP authentication LDAP applications do not provide users public IP, so there are no **internal** and **external** permissions. 1 factor or 2 factors LDAP permissions allow the application to: * source users --> **LDAP search** * authenticate users with permission --> **LDAP bind** **If a user doesn't have a LDAP 1 or 2 factors permission, the application can't find him with a search request** Possible values: * **no rule**: does not apply any rule, so users can't be sourced and can't be authenticated * **1 factor**: users can be sourced, and only one authentication factor is needed to access the application * **2 factors**: users can be sourced, and two authentication factors are needed to access the application. LDAP is not designed for MFA, so if you use this permission: * If the user provides login + password and have WALLIX Authenticator, Trustelem will only answer after the validation of a push notification (**only possible if the app have a timeout long enought) * If the user provides login + password and doesn't have WALLIX Authenticator, the authentication will failed * The user can provides his login + password and TOTP code sticked together (for instance: mypasswordTOTP) * **Forbidden**: the user can’t access the application and can't be sourced #### Radius authentication Radius applications do not provide users public IP, so there are no **internal** and **external** permissions. Possible values: * **no rule**: does not apply any rule, so users can't be authenticated * **Always allow**: accept the authentication if the login is known, without any verification on the password/2nd factor *This permission is used in specific scenarios, when you defined a radius authentication in addition to another authentication (AD usually) and you want some users to authenticate using 2nd factors, and some users using only 1 factor.* * **2nd factor only**: only the second factor are needed to access the application. *This permission is used when you have a radius authentication in addition to another authentication (AD usually).* * **2 factors**: two authentication factors are needed to access the application. *If the application supports Radius in 2 steps (Access Request then Challenge request) you can provide login + password then MFA If the application doesn't support Radius in 2 steps, you can provide login + password and code sticked together* * **Forbidden**: the user can’t access the application