--- title: Working with User Authentication slug: ps/help/en_us/nsa/22x/nsa-zta/ag/1005 docTags: createdAt: 2026-07-22T14:00:50.742Z --- - [Introduction](docId\:NJOnS_n7fVj7YPwBgqwRy) - [Viewing User Authentication Methods](docId\:NJOnS_n7fVj7YPwBgqwRy) - [Viewing User Authentication Policies](docId\:NJOnS_n7fVj7YPwBgqwRy) - [Creating User Rules and User Groups](docId\:NJOnS_n7fVj7YPwBgqwRy) - [Role-based Access Control for Admin Users](docId\:NJOnS_n7fVj7YPwBgqwRy) - [Workflow: Creating a Local Authentication Policy](docId\:NJOnS_n7fVj7YPwBgqwRy) - [Workflow: Creating a SAML Authentication Policy With Azure AD](docId\:NJOnS_n7fVj7YPwBgqwRy) - [Workflow: Creating an Authentication Policy for On-Premises ICS SAML](docId\:NJOnS_n7fVj7YPwBgqwRy) - [Workflow: Creating a SAML Authentication Policy for Okta](docId\:NJOnS_n7fVj7YPwBgqwRy) - [Workflow: Creating a SAML Authentication Policy for Ping Identity](docId\:NJOnS_n7fVj7YPwBgqwRy) - [Workflow: Adding TOTP to an Authentication Policy](docId\:NJOnS_n7fVj7YPwBgqwRy) ## Introduction After you have logged into the *Controller* for the first time (see [Logging in as a Tenant Administrator](docId\:qAQLPFWfOt_GYC0QQw64z)), you can create **authentication methods** and apply them to the **authentication policies** you define in your *Ivanti Neurons for Zero Trust Access* (*nZTA*) deployment. You then apply an authentication policy, together with **user rules**, to a **user group**. A user group forms part of a *Secure Access Policy*. :::hint{type="info" indent="1"} To learn more about secure access policies, see [Creating/Editing Secure Access Policies](docId\:ndGVDPLKGsRFI6krD7rok). ::: To view user authentication methods currently defined on the *Controller*, see [Viewing User Authentication Methods](docId\:NJOnS_n7fVj7YPwBgqwRy). To view user authentication policies, see [Viewing User Authentication Policies](docId\:NJOnS_n7fVj7YPwBgqwRy). This chapter includes workflows for configuring user authentication according to each supported authentication type. *nZTA* supports the following types: - **Local authentication**: An authentication system that is internal to the *Controller*. You must create all users manually on the *Controller*, and update any required authentication policies. see [Workflow: Creating a Local Authentication Policy](docId\:NJOnS_n7fVj7YPwBgqwRy). - **Azure AD SAML authentication**: An existing remote SAML authentication system based on an Azure AD server. See [Workflow: Creating a SAML Authentication Policy With Azure AD](docId\:NJOnS_n7fVj7YPwBgqwRy). - **On-premICSSAML authentication**: An existing remote SAML authentication system based on an on-premises *ICS* server. See [Workflow: Creating an Authentication Policy for On-Premises ICS SAML](docId\:NJOnS_n7fVj7YPwBgqwRy). - **Okta SAML authentication**: An existing remote SAML authentication system based on Okta. See [Workflow: Creating a SAML Authentication Policy for Okta](docId\:NJOnS_n7fVj7YPwBgqwRy). - **PingID SAML authentication**: An existing remote SAML authentication system based on PingID. See [Workflow: Creating a SAML Authentication Policy for Ping Identity](docId\:NJOnS_n7fVj7YPwBgqwRy). - **TOTP authentication**: Time-based One Time Password (TOTP) authentication as a secondary mechanism in *Multi-Factor Authentication* deployments. See [Workflow: Adding TOTP to an Authentication Policy](docId\:NJOnS_n7fVj7YPwBgqwRy). After you have created the required authentication methods and updated your user authentication policies, you create user rules and user groups, see [Creating User Rules and User Groups](docId\:NJOnS_n7fVj7YPwBgqwRy). Optionally, you can associate each user group with an *admin role*, see [Associating User Groups with Admin Roles](docId\:NJOnS_n7fVj7YPwBgqwRy). ## Viewing User Authentication Methods To view the user authentication methods defined on the *Controller*, select the **Secure Access** icon in the *nZTA* menu, then select **Manage Users > Authentication Servers**. The *Authentication Servers* page appears, showing all user authentication methods: ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/JG5DXNUi5d4ABiF1lk_sb_usermethodsstart.png" position="flex-start" size="80" width="1045" height="625" initialPath="img/user_methods_start.png" githubPath="img/user_methods_start.png" showCaption="false"} :::Paragraph{indent="1"} User Authentication Methods ::: From this page, you can: - Add a new authentication method by selecting **Create Authentication Server**. - Edit an existing authentication method by selecting the adjacent check box, then selecting **Actions > Edit**. Make any required updates and save the changes. - Delete an unused authentication method by selecting the adjacent check box, then selecting **Actions > Delete**. You must confirm the deletion. - View the configured attributes for a SAML authentication method, where that method is configured for use with an authentication policy. To do this, select the arrow indicator to the left of the method name, where shown. ## Viewing User Authentication Policies To view the user authentication policies defined on the *Controller*, select the **Secure Access** icon in the *nZTA* menu, then select **Manage Users > User Policies**. The *User Policies* page appears, showing all user authentication policies. ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/cSoGaqZPVBr9OTuyk94aq_userpoliciesstart.png" position="flex-start" size="80" width="997" height="607" initialPath="img/user_policies_start.png" githubPath="img/user_policies_start.png" showCaption="false"} :::Paragraph{indent="1"} User Authentication Policies ::: *nZTA* provides following default/built-in authentication policies, indicated by a tick in the **Default** column, suitable for the primary use-cases of administrative sign-in, user enrollment, and user sign-in: - *Admin SignIn*. This policy is used whenever admin users log in. That is, for connection requests to the *\*/login/admin/* URL. It is referenced by the *ALLADMINUSERS* user rule, which associates it with the *ADMINISTRATORS* user rule group. - *User SignIn*. This policy can be used as the primary connection endpoint for all user device sign-in and enrollment requests. That is, for connection requests to the *\*/login/* URL. It is referenced by the *ALLUSERS* user rule, which associates it with the *USERS* user rule group.a These policies are fixed and cannot be deleted. However, you can edit them to reference specific authentication methods. Furthermore, you can create additional custom authentication policies to enable bespoke authentication for specific groups of users or parts of your organization. Each policy should contain a unique access URL to which your users connect, and each should then be configured to link to authentication methods applicable for that purpose (for more information, see [Adding Custom Authentication Policies](docId\:NJOnS_n7fVj7YPwBgqwRy)). To learn more about how user authentication policies are used in a *nZTA* service, see [Defining User Authentication](docId\:NJOnS_n7fVj7YPwBgqwRy). From this page, you can: - (For SAML authentication) Download policy metadata files that are required for external SAML enrollment or sign-in apps. To do this, select the check box for the required policy and select **Download**. Save the file to your local workstation. - View the configured attributes for a SAML-authenticated policy, where that policy is configured with a valid SAML authentication method. To do this, select the arrow indicator to the left of the policy name, where shown. - Add an authentication policy by selecting **Create User Policy**. - Edit an existing authentication policy by selecting the adjacent check box, then selecting **Actions > Edit**. Make any required updates and save the changes. - Delete an unused authentication policy by selecting the adjacent check box, then selecting **Actions > Delete**. You must confirm the deletion. ## Creating User Rules and User Groups After your authentication method is established and associated with an authentication policy, you can set up any required *user rules* and *user groups*. A user rule identifies one or more users based on a test against a selected attribute present in a user credential or profile, checked against either a local authentication record or from a SAML authentication service. For information about creating user rules, see [Creating User Rules](docId\:NJOnS_n7fVj7YPwBgqwRy). ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/LKSC4LW3w-gyhCRph0fST_usergroup.png" position="flex-start" size="80" width="1857" height="1062" initialPath="img/user_group.png" githubPath="img/user_group.png" showCaption="false"} :::Paragraph{indent="1"} Performing authentication through a User Group ::: You associate one or more user rules with an *authentication policy* to form a *user group* (see [Creating User Groups](docId\:NJOnS_n7fVj7YPwBgqwRy)). Users requesting authorization for a service controlled by a Secure Access Policy must pass all the rules contained in the User Group attached to the policy. A user group is required when defining a *secure access policy*. The user group identifies the users and the authentication policy to which a secure access policy applies, see [Creating/Editing Secure Access Policies](docId\:ndGVDPLKGsRFI6krD7rok). Optionally, you can associate each user group with an admin role, see [Associating User Groups with Admin Roles](docId\:NJOnS_n7fVj7YPwBgqwRy). ### Creating User Rules Through user rules, an admin can construct a test to provide authorization to only those users of a particular name, role, group, or some other stored attribute. In the rule configuration, you select the user attribute on which you want a test to be performed. *nZTA* includes following default user rules: - *ALLADMINUSERS*. This matches all users, and is referenced by the default *ADMINISTRATORS* user group, which associates it with the built-in *Admin Signin* authentication policy. - *ALLUSERS*. This matches all users, and is referenced by the default *USERS* user group, which associates it with the built-in *User Signin* authentication policy. :::hint{type="info" indent="1"} To read more about default user groups, see [Creating User Groups](docId\:NJOnS_n7fVj7YPwBgqwRy). To read more about built-in authentication policies, see [Viewing User Authentication Policies](docId\:NJOnS_n7fVj7YPwBgqwRy). ::: This preset configuration of rules, groups, and policies is suitable for typical use cases involving whole-organization authorization needs. In other words, where you require only a single user authorization path that matches all users. For scenarios where you require more specific user authorization checks, you can create additional rules to match specific types of users. When you create a rule, you select the user attribute with which you want this rule to test. *nZTA* provides the following rule attribute types: - **username**: For local authentication methods, choose this attribute type to match against locally-defined user names. - **SAML (Azure AD)**: For SAML authentication methods, choose this attribute type to match against user names or groups provided by the SAML service. - **Custom**: For SAML authentication methods, choose this attribute type to match against a custom SAML attribute expression. To create a user rule: 1. From the *nZTA* menu, select the **Secure Access** icon, then select **Manage Users > User Rules**. The *User Rules* page appears. This page lists all user rules. 2. Click **Create User Rule**. The *Create User Rule* form appears. ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/wGehfm5UDUB4ux50Y_wJJ_adduserrulesstart.png" alt="Create User Rule" position="flex-start" size="80" width="933" height="559" initialPath="img/add_user_rules_start.png" githubPath="img/add_user_rules_start.png" showCaption="false" indent="1"} :::Paragraph{indent="1"} Create User Rule ::: :::hint{type="info"} At any point during this process, you can reset the form data by clicking **Reset Fields**. ::: 3. Enter a **Rule Name**. 4. Select **Select Attribute Type** and select one of the available options: - *Username*: Matches user names in a local authentication method. When you select this option, you must then: - Select an **Expression** type, either *Matching* or *Not Matching*. - For the **User** value, enter a match expression for the selected **Expression** type. For the value: - A comma-separated list of items is supported where required. - Wildcard matches are supported. - Special characters are supported. - Single and double quotes are not supported. :::hint{type="info" indent="1"} *Ivanti* recommends that a basic asterisk wildcard is not used when you intend to associate admin roles with user groups. Instead, a more-specific wildcard that only includes admin users is required in this case to prevent all users having total access rights. ::: :::Paragraph{listStyleType="disc" indent="2"} *SAML (Azure AD)*: Matches user names or groups in a SAML authentication method. When you select this option, you must then: ::: :::Paragraph{listStyleType="disc" indent="3"} Select a **SAML Attribute Type**, either *Username* or *Group*. ::: :::Paragraph{listStyleType="disc" indent="3"} For **Attribute Value**, enter a single-value match expression for the selected **SAML Attribute Type** as a SAML expression. For matches against *username*, \*-wildcard values are accepted. For matches against *Group*, specify either a Group Name or GroupID based on the configuration in your Azure AD service. ::: :::hint{type="info" indent="3"} If you select an attribute type of *Group*, an authenticated user must be a part of only the matching group. If the user is a part of multiple groups, authentication will fail. ::: :::Paragraph{listStyleType="disc" indent="2"} *Custom*. Matches against a custom SAML attribute expression. When you select this option, use the **Type or Create an Expression** property to enter an attribute expression. Supported formats include: ::: :::Paragraph{listStyleType="disc" indent="3"} For simple user attribute key-value matching, use the syntax `userAttr. [=|!=] `. For example: ::: ```javascript - userAttr.memberOf = "CN=sales,DC=example,DC=com" - userAttr.mail = "user1@example.com" - userAttr.realm = "Users" - userAttr.department != "example_department" ``` :::Paragraph{listStyleType="disc" indent="3"} To match against attributes that can have multiple values associated with a single attribute key, use the syntax `samlMultiValAttr. [=|!=] ()`. For example: ::: ```javascript - samlMultiValAttr.memberOf = ("CN=Employee,CN=Users,DC=example_demo,DC=com") - samlMultiValAttr.memberOf = ("CN=Users,DC=example_demo,DC=com") ``` :::Paragraph{listStyleType="disc" indent="3"} Use brackets and AND/OR operators to construct logical compound expressions: ::: ```javascript - userAttr.groups = ("Group1" or "Group2") - userAttr.realm = ("ztaqa") and samlMultiValAttr.memberOf = ("CN=sales,DC=uisdp,DC=com") - userAttr.realm = ("ztaqa") or samlMultiValAttr.memberOf = ("CN=sales,DC=uisdp,DC=com") - userAttr.realm != ("ztaqa") and samlMultiValAttr.memberOf = ("CN=sales,DC=uisdp,DC=com") ``` :::hint{type="info" indent="3"} For *samlMultiValAttr* expressions containing multiple groups (for example, `samlMultiValAttr.groups = ("Group1" or "Group2")`), your matching users must be a part of both groups in the expression to obtain authorization. ::: 5. To create the user rule with the displayed settings, click **Create User Rule**. The new user rule is added to the list of user rules. 6. Repeat steps 3-6 for each required user rule. 7. (Optional) Edit an existing user rule by selecting the adjacent check box, and then selecting **Actions > Edit**. Make any required updates and save the changes. 8. (Optional) Delete an unused user rule by selecting the adjacent check box, and then selecting **Actions > Delete**. You must confirm the deletion. After you have created all required user rules, you can create user groups, see [Creating User Groups](docId\:NJOnS_n7fVj7YPwBgqwRy). ### Creating User Groups After you have created user rules (see [Creating User Rules](docId\:NJOnS_n7fVj7YPwBgqwRy)), you associate one or more user rules with an authentication policy to form a user group. :::hint{type="info" indent="1"} User groups are one of the four dimensions of a Secure Access Policy, see [Creating/Editing Secure Access Policies](docId\:ndGVDPLKGsRFI6krD7rok). ::: *nZTA* includes following default user groups: - *ADMINISTRATORS*. This user group associates the default *ALLADMINUSERS* user rule with the built-in *Admin Signin* authentication policy. - *USERS*. This user group associates the default *ALLUSERS* user rule with the built-in *User Signin* authentication policy. :::hint{type="info" indent="1"} To read more about built-in authentication policies, see [Viewing User Authentication Policies](docId\:NJOnS_n7fVj7YPwBgqwRy). ::: This preset configuration of rules, groups, and policies is suitable for typical use cases involving whole-organization authorization needs. In other words, where you require only a single user authorization path that matches all users. For scenarios where you require more specific user authorization checks, you can create additional user groups to make different associations of user rules and custom authentication policies. To create a user group: 1. From the *nZTA* menu, select the **Secure Access** icon, then select **Manage Users > User Groups**. The *User Groups* page appears. This page lists all user groups. 2. Click **Create User Group**. A form appears to enable you to create the user group. ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/Ct6sOgc0reeonr0WxAc3O_addusergroupsstart.png" alt="Create User Groups" position="flex-start" size="80" width="937" height="564" initialPath="img/add_user_groups_start.png" githubPath="img/add_user_groups_start.png" showCaption="false" indent="1"} :::Paragraph{indent="1"} Create User Groups ::: 3. Enter a **User Group Name** and an optional **Description**, then click **Next**. 4. Select each of the listed **User Rules** that are required in the user group, then click **Next**. :::hint{type="info"} User rules should be different for enrollment and user sign-in groups ::: 1. Select required authentication policy from the list, then click **Next**. 2. Review the summary and click **Create**. The new user group appears in the **User Groups** list. 3. Repeat steps 2-7 to create all required user groups. 4. (Optional) To edit a listed user group, select the adjacent check box, then select **Actions > Edit** and make any required updates. 5. (Optional) To delete an *unused* user group, select the adjacent check box, then select **Actions > Delete** and confirm the deletion. After you have created user groups, you can optionally assign the user group to an admin role, see [Associating User Groups with Admin Roles](docId\:NJOnS_n7fVj7YPwBgqwRy). ### Associating User Groups with Admin Roles An admin role defines the elements of the user interface that an associated user group can access. The current user can only access an individual user interface page/workflow if their user group is associated with an admin role that permits it. The tasks they can perform within that displayed element depends on the permissions set within the admin role. :::hint{type="info"} When you are using admin roles, *Ivanti* recommends that any user rules for administrators does not use a basic asterisk wildcard, see [Creating User Rules](docId\:NJOnS_n7fVj7YPwBgqwRy). Instead, a more-specific wildcard that only includes admin users is required in this case to prevent all users having total access rights. ::: :::hint{type="info"} The default admin roles are not created by the tenant admin using the *nZTA* user interface. Rather, they are set up by the *Ivanti* DevOps team. ::: For example, the DevOps team might define the following admin roles: - The *.Administrators* admin role has access to all user interface elements (full read, create, update, delete rights). - The *.Read-Only Administrators* admin role has access to all user interface elements except workflows (read only). - The *.Network Administrators* admin role has access to *nZTA Gateway*s and Insights (read only). - The *.CxOs* admin role has access to Insights only (read only). :::hint{type="info" indent="1"} For more information about your assigned admin roles, please contact *Ivanti* DevOps. ::: The Tenant Admin can view admin roles in the **Administration > Admin Roles** page, and associate each role with a single user group. To associate a user group with an admin role: 1. Log into the *Controller* as a Tenant Admin, see [Logging in as a Tenant Administrator](docId\:qAQLPFWfOt_GYC0QQw64z). 2. From the *nZTA* menu, select **Administration**, then select **Admin Roles**. :::Paragraph{indent="1"} A list of Admin Roles appears. This includes default admin roles and custom admin roles (RBAC). For example: ::: ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/gHMo7z2pkTAmnwF15FU71_adminroleempty.png" alt="Admin Roles" position="flex-start" size="80" width="1033" height="541" initialPath="img/admin_role_empty.png" githubPath="img/admin_role_empty.png" showCaption="false" indent="2"} :::Paragraph{indent="2"} Admin Roles ::: 3. Select the check box adjacent to the role you want to update, then select **Actions > Edit**. :::Paragraph{indent="1"} A dialog appears. For example: ::: ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/u2kdgVOVMM_krSrnN_N6t_adminroleedit.png" alt="Edit Admin Roles" position="flex-start" size="75" width="750" height="634" initialPath="img/admin_role_edit.png" githubPath="img/admin_role_edit.png" showCaption="false" indent="2"} :::Paragraph{indent="2"} Edit Admin Roles ::: 4. Under **Choose group**, select the user group that you want the admin group to be associated with. 5. Select **Save Changes**. 6. (Optional) Repeat steps 3 to 5 for each admin role. ## Role-based Access Control for Admin Users With Role-based access control (RBAC), organizations can easily add admins and assign them specific roles, with differing levels of access to the nSA Admin Portal. In addition to an existing set of default roles, Administrators can now create custom granular roles for specific functions within the nSA admin portal. The following examples illustrate how an organization can leverage role-based administration for a variety of scenarios. To create a custom admin role: 1. Log into the *Controller* as a Tenant Admin, see [Logging in as a Tenant Administrator](docId\:qAQLPFWfOt_GYC0QQw64z). 2. From the *nZTA* menu, select **Administration**, then select **Admin Roles**. 3. In the Admin Roles page, click **Create Role**. The Create Admin Role page appears. ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/XCMS6JCFHBZMileYDYNxo_adminrolecreate.png" alt="admin_role_create" position="flex-start" size="73" width="730" height="640" initialPath="img/admin_role_create.png" githubPath="img/admin_role_create.png" showCaption="false" indent="1"} :::Paragraph{indent="1"} Create Admin Role ::: 4. Enter a unique name for the role. 5. From the drop-down list, select the User Group that you want to associate with this role. For details, see [Associating User Groups with Admin Roles](docId\:NJOnS_n7fVj7YPwBgqwRy). 6. Optionally, enter a **Description**. 7. From the drop-down list, select an existing role that suits your requirements. 8. Under Permission Settings, the *Controller* Permissions list shows the list of resources. The resources specific to nZTA are tagged with **nZTA** and resources specific to nSA are tagged with **ICS**. ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/edSCLiIf1B3tRdmWK22Dl_adminrolectrperm.png" position="flex-start" size="56" width="556" height="655" initialPath="img/admin_role_ctrperm.png" githubPath="img/admin_role_ctrperm.png" showCaption="false" indent="1"} :::Paragraph{indent="1"} *Controller* Permissions ::: 9. Select the Hide, View only, or Modify permissions for each resource and its attributes. This determines which pages to show and which actions to allow. 10. Under Permission Settings, the ICS Gateway Configuration list shows the list of ICS Gateway resources. ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/lYemAtOUbmLRPVT_lCVLT_adminroleicsgwperm.png" position="flex-start" size="56" width="564" height="649" initialPath="img/admin_role_icsgwperm.png" githubPath="img/admin_role_icsgwperm.png" showCaption="false" indent="1"} :::Paragraph{indent="1"} ICS Gateway Permissions ::: 11. Click **Select Gateways**. In the Select Gateways dialog, select one or more Gateways / Clusters from the list and click **Apply**. ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/hDPB0iuFXE5Kg3WE4qluH_adminroleselgw.png" position="flex-start" size="80" width="958" height="318" initialPath="img/admin_role_selgw.png" githubPath="img/admin_role_selgw.png" showCaption="false" indent="1"} :::Paragraph{indent="1"} Select Gateways/Clusters ::: 12. Select the Hide, View only, or Modify permissions for each resource and its attributes. This determines which pages to show and which actions to allow. 13. Click **Create**. The newly created custom admin role is displayed in the Admin Roles page. 14. (Optional) Edit an existing admin role by selecting the check box adjacent to the role and then clicking **Actions > Edit**. Make any required updates and save the changes. 15. (Optional) Delete an unused custom admin rule by selecting the check box adjacent to the role and then clicking **Actions > Delete**. You must confirm the deletion. :::hint{type="info"} New pages added as part of Controller/Gateway updates are visible to Super Admins by default, but hidden for custom admin roles. Super Admins can modify the permissions for the new pages added based on the custom roles created. ::: ## Workflow: Creating a Local Authentication Policy This process involves creating a local user authentication *method* and defining within it all user credentials necessary to identify and authenticate your end-users. You then configure this method as the primary authentication method in your *authentication policies*. If you are configuring Multi-Factor Authentication (MFA) in your deployment, you can configure local user authentication as either the primary or secondary authentication method. Before you begin, make sure you have all user details (name and password) ready. To configure a *new* local authentication method: 1. Log into the *Controller* as a Tenant Admin, see [Logging in as a Tenant Administrator](docId\:qAQLPFWfOt_GYC0QQw64z). 2. From the *nZTA* menu, select the **Secure Access** icon, then select **Manage Users > Authentication Servers**. The **Authentication Servers** page appears. This page lists all existing user authentication methods. For example: ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/JG5DXNUi5d4ABiF1lk_sb_usermethodsstart.png" alt="User Authentication Methods" position="flex-start" size="80" width="1045" height="625" initialPath="img/user_methods_start.png" githubPath="img/user_methods_start.png" showCaption="false"} User Authentication Methods 3. Select **Create Authentication Server**. A form appears that enables you to define the authentication method. ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/CrHWDlqAuQYpUChz-Y01k_wizusermethodsstart.png" alt="Adding a new local user authentication method" position="flex-start" size="80" width="895" height="918" initialPath="img/wiz_user_methods_start.png" githubPath="img/wiz_user_methods_start.png" showCaption="false"} Adding a new local user authentication method :::hint{type="info"} At any point during this process, you can reset the form data by selecting **Reset Fields**. ::: 4. Under **Choose name and type**: - Specify an **Authentication Server Name**. - Select the **Authorization Type** of *Local*. 5. Configure the password options. This is applicable to default Admin Auth and default User Auth. | Settings | Guidelines | | -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Minimum length | Specify a number of characters. The valid range is 6-128. 6 is the default. | | Maximum length | Specify a number of characters. The valid range is 6-128. 128 is the default. The maximum length cannot be less than the minimum length. | | Minimum digits | Specify the number of digits required in a password. Do not require more digits than the value of the maximum length option. | | Minimum letters | Specify the number of letters required in a password. Do not require more letters than the value of the maximum length option. If you enable the previous option, the combined total of the two options cannot exceed that of the value specified in the maximum length option. | | Uppercase and lowercase required | Select this option if you want all passwords to contain a mixture of uppercase and lowercase letters.
Require passwords to contain at least two letters if you also require a mix of uppercase and lowercase letters. | | | | | Special Characters | Select this option if you want password should contain any special characters | | Different from current password | Select this option if the password must not be same as the current password. | | Different from username | Select this option if the password must not be same as the username. | | Different from previous password | Select this option and then select the number from drop-down if a new password must not be same as the previous number of passwords. | | Force password change | Select this option to specify the number of days after which a password expires. The default is 180 days. | | Allow users to change passwords | Select this option if you want users to be able to change their passwords.
In addition to selecting local authentication password management options, you must select the Enable Password Management option for the associated realm authentication policy. | | Prompt users to change password | Select this option to specify when to prompt the user to change passwords. | 6. Click **Create User**. The *Create Local User* dialog appears to show additional local authentication settings: ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/FbWZekZvhEd8BVZsr6CYx_wizusermethodslocalusers.png" alt="Adding local users to a new authentication method" position="flex-start" size="80" width="916" height="451" initialPath="img/wiz_user_methods_localusers.png" githubPath="img/wiz_user_methods_localusers.png" showCaption="false"} Adding local users to a new authentication method 7. Enter the following settings: - Specify a **User Name**, **Full Name**, and **Email** for the user. - Specify a **Password** and **Confirm Password** for the user. - (Optional) Select the **Temporary Password** check box if you want the user to change their password when they first log in. - Click **Create User**. The user is added to the list of users. 8. Repeat the previous step for each required user. 9. Click **Create Authentication Server**. :::Paragraph{indent="1"} The new local user authentication method is added to the list of methods and the process is complete. ::: After you have created your local authentication method, create or update your authentication policies with the new authentication method. *nZTA* provides built-in policies to cover both basic cases. In addition, *nZTA* allows for the definition of custom policies to facilitate separate authentication endpoints for specific groups of users. To learn more, see [Using User Authentication Policies](docId\:NJOnS_n7fVj7YPwBgqwRy). Repeat the following steps for each policy, starting with enrollment: 1. From the *nZTA* menu, select the **Secure Access** icon, then select **Manage Users > User Policies**. The **User Policies** page appears. This page lists all existing user authentication policies. ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/cSoGaqZPVBr9OTuyk94aq_userpoliciesstart.png" alt="User Authentication Policies" position="flex-start" size="80" width="997" height="607" initialPath="img/user_policies_start.png" githubPath="img/user_policies_start.png" showCaption="false"} User Authentication Policies To learn more about the policies on this page, see [Viewing User Authentication Policies](docId\:NJOnS_n7fVj7YPwBgqwRy). From this page, either create a new custom policy or edit an existing policy. 2. To add a new custom policy, click **Create User Policy**. The **Create Authentication Policy** form appears. ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/97lDbU6p1D5VPiey1vLec_adduserpolicystart.png" position="flex-start" size="80" width="901" height="703" initialPath="img/add_user_policy_start.png" githubPath="img/add_user_policy_start.png" showCaption="false"} Create Authentication Policy :::hint{type="info"} To learn more about how custom policies are used for user login and enrollment, see [Adding Custom Authentication Policies](docId\:NJOnS_n7fVj7YPwBgqwRy). ::: 3. Enter a **Policy Name**. 4. Enter a **Login URL** using the format *\*/login/\/*. The URL must start with "*\*/login/*" and cannot contain any special characters. \ should be set to a unique value reflecting the endpoint URL you want to define for this authentication policy (appended with a backslash): - In the case of user sign-in policies, this is the URL endpoint (appended to the tenant FQDN) to which new users are invited to connect to enroll or sign-in a device with the *Controller*. Example value: "*\*/login/saleslogin/*". - In the case of user enrollment policies, this endpoint identifies the enrollment URL to which users are redirected if they attempt to connect to the equivalent sign-in policy with an un-enrolled device. In most cases, you do not advertise this endpoint to your users. Example value: "*\*/login/salesenroll/*". :::hint{type="info"} In some enrollment circumstances, such as when using a device pre-installed with an older version of *Ivanti Secure Access Client*, you connect directly to the enrollment policy endpoint to enroll the device. For more details, see [Using User Authentication Policies](docId\:NJOnS_n7fVj7YPwBgqwRy). ::: 1. (Optional) Enter a description for the authentication policy. 2. Select a **User Type** based on the intended authentication activity for this policy. Choose from: - **Users**: Select this option to define the user sign-in endpoint for enrolled devices. This is the endpoint that you provide to your users to access the service (regardless of enrollment status). - **Administrators**: Select this option to define the authentication endpoint for administrator-level sign-in. This endpoint is used for administrator login to the *Controller* only. 3. (for policies with a **User Type** of "Users" only): Select an **Enroll Device Policy** from the drop-down list to be linked to this sign-in policy (as indicated): ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/8YZR7bxf-cDgYHmD86P30_authpolicyusertype.png" position="flex-start" size="80" width="805" height="400" initialPath="img/auth_policy_user_type.png" githubPath="img/auth_policy_user_type.png" showCaption="false"} Linking an enrollment policy to a user sign-in policy This is the enrollment policy to which a user is redirected if it is determined that the device is not yet enrolled. To learn more, see [Using User Authentication Policies](docId\:NJOnS_n7fVj7YPwBgqwRy). 8. Under **Policy Server Details**, select **Primary Auth Server** from the drop-down list: ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/e1o3T_FjCr2Gbadx6rxyb_authpolicyauthserver.png" alt="Selecting a primary authentication method for this policy" position="flex-start" size="80" width="976" height="447" initialPath="img/auth_policy_auth_server.png" githubPath="img/auth_policy_auth_server.png" showCaption="false"} Selecting a primary authentication method for this policy 9. (Optional) Where a secondary method is required for Multi-Factor Authentication, select **Secondary Auth Server** from the drop-down list. :::hint{type="info"} Secondary authentication methods do not apply to *Enrollment User* type policies. The relevant field is hidden in this case. ::: 1. Click **Create User Policy** to create the new policy. :::Paragraph{indent="1"} The new policy is added to the list of authentication policies. ::: If you instead elect to update an existing custom or built-in policy: 1. Select the check box adjacent to the relevant policy, then select **Actions > Edit**. The **Edit authentication policy** form appears. :::hint{type="info"} For built-in authentication policies, all properties except **Primary Auth Server** and **Secondary Auth Server** (where applicable) are read-only. ::: 1. Configure the primary and/or secondary authentication methods, as required: - Set the **Primary Auth Server** to be the new local user authentication method (indicated): ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/WdkayFlnlTGclk4Dq51SU_editauthpolicyserverdetails.png" alt="Editing the primary auth server" position="flex-start" size="80" width="889" height="628" initialPath="img/edit_auth_policy_server_details.png" githubPath="img/edit_auth_policy_server_details.png" showCaption="false"} :::Paragraph{indent="2"} Editing the primary auth server ::: :::Paragraph{listStyleType="disc" indent="2"} If you are configuring a policy for MFA, set the **Secondary Auth Server** to be the new local user authentication method (indicated): ::: :::hint{type="info" indent="3"} If you configure a secondary authentication method in a policy that is currently in use, any active user sessions must be disconnected and reconnected for the changes to take effect. ::: 3. Click **Update User Policy**. The list of authentication policies updates. 4. Repeat until all required authentication policies are updated. To ensure that your users can access the authentication mechanism defined in the policies you configure through this process, make sure your *Secure Access Policies* are configured with a **User Group** in which these authentication policies are defined. To learn more, see [Creating/Editing Secure Access Policies](docId\:ndGVDPLKGsRFI6krD7rok). ## Workflow: Creating a SAML Authentication Policy With Azure AD *nZTA* supports the use of a cloud-based Active Directory (AD) SAML service to provide authentication for your users. If you choose to use AD as a SAML Identity Provider (IdP), you do not create any users locally on the *Controller*. All users will already be present in your remote SAML service. Configuring *nZTA* to use SAML authentication requires you to create separate SAML apps on the Azure AD platform for the following primary activities: - User sign-in - User enrollment As part of hardening custom sign-in policies and login URLs, the following changes are implemented: 1. Instead of requiring administrators to configure enrollment policies, administrators will only need to configure user policies. As a default, all configured user policies support enrollment. 2. Single SAML authentication server for user authentication and enrollment. The *Controller* includes built-in default authentication policies for each of these purposes, and also includes the ability to create your own custom policies for separate authentication of specific user groups. You create an authentication method referencing one of the Azure AD SAML apps described above and then assign the method to an authentication policy of the same type (either the built-in policy, or one you create). ### Configuring *nZTA* to Use SAML Authentication :::hint{type="info"} You must keep the SAML metadata up-to-date, especially after renewing certificates. This is essential for a secure and successful SaaS Apps SAML SSO flow. Regularly updating configurations in both the Identity Provider and Service Providers helps prevent authentication failures and ensures the security of the authentication process. ::: Configure *nZTA* by performing the following steps: 1. Log into the *Controller* as a Tenant Admin, see [Logging in as a Tenant Administrator](docId\:qAQLPFWfOt_GYC0QQw64z). 2. From the *nZTA* menu, select the **Secure Access** icon, then select **Manage Users > Authentication Servers**. The *Authentication Servers* page appears. This page lists all existing user authentication methods: ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/JG5DXNUi5d4ABiF1lk_sb_usermethodsstart.png" alt="User Authentication Methods" position="flex-start" size="80" width="1045" height="625" initialPath="img/user_methods_start.png" githubPath="img/user_methods_start.png" showCaption="false"} User Authentication Methods 3. Click **Create Authentication Server**. A form appears that enables you to define the authentication method: ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/CrHWDlqAuQYpUChz-Y01k_wizusermethodsstart.png" alt="Adding a user authentication method" position="flex-start" size="80" width="895" height="918" initialPath="img/wiz_user_methods_start.png" githubPath="img/wiz_user_methods_start.png" showCaption="false"} Adding a user authentication method :::hint{type="info"} At any point during this process, you can reset the form data by selecting **Reset Fields**. ::: 4. Under **Choose Server Name and Authentication Type**: - Select the **Authentication Type** as *SAML (Azure AD)*. The form expands to show additional settings. ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/dI27GK0rTlGa9bNeG4YVq_wizusermethodssaml.png" alt="Configuring SAML (Azure AD) authentication settings" position="flex-start" size="80" width="906" height="754" initialPath="img/wiz_user_methods_saml.png" githubPath="img/wiz_user_methods_saml.png" showCaption="false"} :::Paragraph{indent="2"} Configuring SAML (Azure AD) authentication settings ::: :::Paragraph{listStyleType="disc" indent="2"} Specify an **Authentication Server Name**. ::: 2. To provide your SAML IdP settings, select one of the following: - Select **Upload SAML Auth metadata file** if not selected already. This is selected by default. The **Download Auth Service Provider Metadata for IDP** link is enabled. 1. (Optional) Specify a **Single Logout URL**. For more information, see [Using SAML Single Logout to Force User Authentication](docId\:NJOnS_n7fVj7YPwBgqwRy). :::hint{type="info"} By default, the *Controller* expects a signed metadata definition file. To allow an unsigned metadata file, select **Allow Unsigned Metadata**. ::: :::Paragraph{indent="3"} Click the **Download Auth Service Provider Metadata for IDP** link. Retain the downloaded file for later use. ::: :::Paragraph{listStyleType="disc" indent="2"} Select **Enter SAML Auth metada details manually** to manually enter the required IdP SAML settings. Use this option in scenarios where a SAML federation metadata file is not available or incomplete. Then, enter the following details: ::: ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/R0z4b7hmWmnx5TG6KVDUQ_wizusermethodssamlmanual.png" alt="Configuring SAML (Azure AD) IdP settings manually" position="flex-start" size="80" width="913" height="511" initialPath="img/wiz_user_methods_saml_manual.png" githubPath="img/wiz_user_methods_saml_manual.png" showCaption="false" indent="3"} :::Paragraph{indent="2"} Configuring SAML (Azure AD) IdP settings manually The following minimum settings are required for your SAML authentication service to function correctly. Each setting relates to a value configured in the SAML application on your IdP. Contact your IdP administrator to obtain the relevant details: ::: :::Paragraph{listStyleType="disc" indent="3"} **IDP Entity ID**: The entity ID is sent as the Issuer value in the SAML assertion generated by the IdP. Specify the Issuer value in assertions generated by the SAML identity provider. ::: :::Paragraph{listStyleType="disc" indent="3"} **IDP SSO URL**: A URL provisioned by the SAML IdP to support service-provider-initiated Single Sign-On. Use the format `https://`. ::: :::Paragraph{listStyleType="disc" indent="3"} **IDP SLO Service**: (Optional) A URL to specify the Single Log-Out/sign out endpoint if you want to force re-authentication for increased security. Use the format `https://`. For more information, see [Using SAML Single Logout to Force User Authentication](docId\:NJOnS_n7fVj7YPwBgqwRy). ::: :::Paragraph{listStyleType="disc" indent="3"} **User Name Template**: Specify how the system is to derive the username from the SAML assertion. The default value can be used, or replaced with an alternative specifier that the *Controller* uses from the incoming assertion. For example: ``, the NameID value where *ICS* is the IdP, the UID from X509SubjectName, ``, attr from AttributeStatement attributes. ::: :::Paragraph{listStyleType="disc" indent="3"} **IDP Signing Certificate**: The signing certificate to be used with the SAML app on the IdP. Type or paste in the contents of your Base-64 encoded public key. ::: 6. If this Auth server is used with User Policy of type “User”, then click **Enable Enrollment**. ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/pdFSWHJ64iPYJUeeV-hIE_samlenableenroll.png" alt="Enable Enrollment" position="flex-start" size="44" width="439" height="369" initialPath="img/saml_enable_enroll.png" githubPath="img/saml_enable_enroll.png" showCaption="false"} Enable Enrollment 7. To provide your SAML IdP settings, select one of the following: - Select **Upload SAML Enroll metadata file** if not selected already. This is selected by default. 1. (Optional) Specify a **Single Logout URL**. For more information, see [Using SAML Single Logout to Force User Authentication](docId\:NJOnS_n7fVj7YPwBgqwRy). :::hint{type="info"} By default, the *Controller* expects a signed metadata definition file. To allow an unsigned metadata file, select **Allow Unsigned Metadata**. ::: :::Paragraph{indent="3"} Click the **Download Enroll Service Provider Metadata for IDP** link. ::: :::Paragraph{listStyleType="disc" indent="2"} Select **Enter SAML Enroll metada details manually** to manually enter the required IdP SAML settings. Use this option in scenarios where a SAML federation metadata file is not available or incomplete. Then, enter the following details: ::: ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/ucGbC9hA4wENAQz2RbdUa_samlenrollmanually.png" alt="Configuring SAML (Azure AD) IdP settings manually" position="flex-start" size="72" width="715" height="346" initialPath="img/saml_enroll_manually.png" githubPath="img/saml_enroll_manually.png" showCaption="false" indent="3"} :::Paragraph{indent="2"} Configuring SAML (Azure AD) IdP settings manually The following minimum settings are required for your SAML authentication service to function correctly. Each setting relates to a value configured in the SAML application on your IdP. Contact your IdP administrator to obtain the relevant details: ::: :::Paragraph{listStyleType="disc" indent="3"} **IDP Entity ID**: The entity ID is sent as the Issuer value in the SAML assertion generated by the IdP. Specify the Issuer value in assertions generated by the SAML identity provider. ::: :::Paragraph{listStyleType="disc" indent="3"} **IDP SSO URL**: A URL provisioned by the SAML IdP to support service-provider-initiated Single Sign-On. Use the format `https://`. ::: :::Paragraph{listStyleType="disc" indent="3"} **IDP SLO Service**: (Optional) A URL to specify the Single Log-Out/sign out endpoint if you want to force re-authentication for increased security. Use the format `https://`. For more information, see [Using SAML Single Logout to Force User Authentication](docId\:NJOnS_n7fVj7YPwBgqwRy). ::: :::Paragraph{listStyleType="disc" indent="3"} **User Name Template**: Specify how the system is to derive the username from the SAML assertion. The default value can be used, or replaced with an alternative specifier that the *Controller* uses from the incoming assertion. For example: ``, the NameID value where *ICS* is the IdP, the UID from X509SubjectName, ``, attr from AttributeStatement attributes. ::: :::Paragraph{listStyleType="disc" indent="3"} **IDP Signing Certificate**: The signing certificate to be used with the SAML app on the IdP. Type or paste in the contents of your Base-64 encoded public key. ::: :::hint{type="info"} \- When editing an existing SAML Auth server, the 'Enable Enrollment' option can be enabled or disabled if the SAML Auth server is not being used in any ‘User Policy’. If the SAML Auth server is being used in a ‘User Policy’, then Enable Enrollment button will be grayed out. \- If 'Enable Enrollment' is not selected, then while creation of 'User Policy' of type 'User', the server you have created (without Enable Enrollment) will not be listed. \- When Enrollment is disabled, the enrollment SAML configuration will be deleted. To enable enrollment, you have to again provide enroll SAML auth server configuration. ::: 1. Use the downloaded User Authentication and Enrollment SP Metadata files to create Sign-In and Enrollment SAML Apps in Azure AD. For details, see [Creating Enrollment/Sign-in SAML App in Azure AD](docId\:NJOnS_n7fVj7YPwBgqwRy). 2. Browse and upload the digitally-signed (or unsigned) federation metadata XML definition files downloaded from Azure AD. 3. Confirm that your settings are correct, then select **Create Authentication Server** to create the authentication method. :::Paragraph{indent="1"} The new SAML user authentication method is added to the list of methods displayed in the **User Authentication** page, and the process completes. ::: (Optional) To edit a listed authentication method, select the adjacent check box, then select **Actions > Edit**. Make any required updates and confirm. 12. (Optional) To delete one (or more) an *unused* authentication methods, select the check box for each, then select **Actions > Delete**. You must confirm the deletion. ### Creating Enrollment/Sign-in SAML App in Azure AD Perform the following steps in Azure AD: 1. Create a SAML app for the required activity (sign-in or enrollment). 2. Click **Upload Metadata File** and select the file from your download. This defines at least the following **Basic SAML Configuration fields**: - **Identifier (Entity ID)**. This is the URL of the SAML endpoint on the *Controller*. This is the audience of the SAML response for IdP-initiated SSO. This cannot be left blank. - **Reply URL (Assertion Consumer Service URL)**. This is the URL of the SAML consumer on the *Controller*. This is the destination URL in the SAML response for IdP-initiated SSO. This cannot be left blank. ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/BRMqamIOTtorzpQcTjnk4_azurecreatenongallapps.png" alt="Setting Basic SAML Configuration in Azure AD applications" position="flex-start" size="80" width="892" height="682" initialPath="img/azure_createnongallapps.png" githubPath="img/azure_createnongallapps.png" showCaption="false"} Setting *Basic SAML Configuration* in Azure AD applications 3. Download the Federation metadata XML definition for the SAML app to your local workstation. Retain this file for later use. ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/xF3P6EyPtsMdm-ihT0-Oe_azuredownloadmetadata.png" alt="Downloading Federation Metadata XML files for user enrollment and user sign-in SAML applications" position="flex-start" size="70" width="701" height="222" initialPath="img/azure_downloadmetadata.png" githubPath="img/azure_downloadmetadata.png" showCaption="false"} Downloading Federation Metadata XML files for user enrollment and user sign-in SAML applications 4. Repeat these steps for each activity. :::hint{type="info" indent="1"} For details on how to create SAML apps in Azure AD, see the Azure AD SAML documentation. ::: ### Creating/Updating Authentication Policies After you have created your SAML authentication method, create or update your authentication policies with the new authentication method. 1. From the *nZTA* menu, select the **Secure Access** icon, then select **Manage Users > User Policies**. The **User Policies** page appears. This page lists all existing user authentication policies. ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/cSoGaqZPVBr9OTuyk94aq_userpoliciesstart.png" alt="User Authentication Policies" position="flex-start" size="80" width="997" height="607" initialPath="img/user_policies_start.png" githubPath="img/user_policies_start.png" showCaption="false"} User Authentication Policies To learn more about the policies on this page, see [Viewing User Authentication Policies](docId\:NJOnS_n7fVj7YPwBgqwRy). From this page, either create a new custom policy or edit an existing policy. 2. To add a new custom policy, select **Create User Policy**. The **Create Authentication Policy** form appears. ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/97lDbU6p1D5VPiey1vLec_adduserpolicystart.png" alt="Add User Authentication" position="flex-start" size="80" width="901" height="703" initialPath="img/add_user_policy_start.png" githubPath="img/add_user_policy_start.png" showCaption="false"} Create Authentication Policy :::hint{type="info"} At any point during this process, you can reset the form data by selecting **Reset Fields**. ::: :::hint{type="info"} To learn more about how custom policies are used for user login and enrollment, see [Adding Custom Authentication Policies](docId\:NJOnS_n7fVj7YPwBgqwRy). ::: 3. Enter a **Policy Name**. 4. Enter a **Login URL** using the format *\*/login/\/*. The URL must start with "*\*/login/*" and cannot contain any special characters. \ should be set to a unique value reflecting the endpoint URL you want to define for this authentication policy (appended with a backslash): - In the case of user sign-in policies, this is the URL endpoint (appended to the tenant FQDN) to which new users are invited to connect to enroll or sign-in a device with the *Controller*. Example value: "*\*/login/saleslogin/*". - In the case of user enrollment policies, this endpoint identifies the enrollment URL to which users are redirected if they attempt to connect to the equivalent sign-in policy with an un-enrolled device. In most cases, you do not advertise this endpoint to your users. Example value: "*\*/login/salesenroll/*". :::hint{type="info"} In some enrollment circumstances, such as when using a device pre-installed with an older version of *Ivanti Secure Access Client*, you connect directly to the enrollment policy endpoint to enroll the device. For more details, see [Using User Authentication Policies](docId\:NJOnS_n7fVj7YPwBgqwRy). ::: 1. (Optional) Enter a description for the authentication policy. 2. Select a **User Type** based on the intended authentication activity for this policy. Choose from: - **Users**: Select this option to define the user sign-in endpoint for enrolled devices. This is the endpoint that you provide to your users to access the service (regardless of enrollment status). - **Administrators**: Select this option to define the authentication endpoint for administrator-level sign-in. This endpoint is used for administrator login to the *Controller* only. 3. From the **Device Policy** list, select a device policy. 4. (for policies with a **User Type** of "Users" only): Select an **Enroll Device Policy** from the drop-down list to be linked to this sign-in policy (as indicated): This is the enrollment policy to which a user is redirected if it is determined that the device is not yet enrolled. To learn more, see [Using User Authentication Policies](docId\:NJOnS_n7fVj7YPwBgqwRy). 5. Under **Auth Servers**, select **Primary Auth Server** and choose the required authentication method from the drop-down list. Only Local and SAML servers will be available for selection as a Primary Auth Server. 6. (Optional) Where a secondary method is required for Multi-Factor Authentication, select **Secondary Auth Server** and choose the required authentication method from the drop-down list. Only Local and TOTP servers will be available for selection as a Secondary Auth Server. 7. Click **Create User Policy** to create the new policy. :::Paragraph{indent="1"} The new policy is added to the list of authentication policies. ::: ### Existing User Policies - For existing default user policies, admin can select either existing or new SAML or Local Auth Server. **Note**: The Auth Server for enrollment will be added automatically. - For existing custom user policies, user can update existing SAML Auth Server. If you intend to update an existing custom or built-in policy: 1. Select the check box adjacent to the relevant policy, then select **Actions > Edit**. The **Update Authentication Policy** form appears. :::hint{type="info"} For built-in authentication policies, all properties except **Primary Auth Server** and **Secondary Auth Server** (where applicable) are read-only. ::: 1. Set the **Primary Auth Server** to be the new SAML user authentication method (indicated): ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/WdkayFlnlTGclk4Dq51SU_editauthpolicyserverdetails.png" alt="Editing the primary auth server" position="flex-start" size="80" width="889" height="628" initialPath="img/edit_auth_policy_server_details.png" githubPath="img/edit_auth_policy_server_details.png" showCaption="false"} Editing the primary auth server :::hint{type="info"} SAML authentication can be used only as a Primary Auth Server. If you are using MFA, specify either a *local authentiction* or *TOTP* method as the **Secondary Auth Server**. ::: :::hint{type="info"} If you configure a secondary authentication method in a policy that is currently in use, any active user sessions must be disconnected and reconnected for the changes to take effect. ::: 3. Select **Update User Policy**. The list of authentication policies updates. 4. Repeat until all required authentication policies are updated. At this point, the *Controller* uses the uploaded Federation Metadata to contact the SAML service. After this process completes, a **Download** function becomes available for each relevant policy. This metadata file is required to configure trusted communication with the remote SAML service. 1. Refresh your browser until the **Download** action is visible for the relevant policies. 2. Select the check box for the policy metadata you want to download and clear all other check boxes. 3. Select **Download** and save the metadata file. :::hint{type="info" indent="1"} As mentioned previously, make sure you repeat this procedure for each required SAML app on your Azure AD platform. That is, you require separate XML metadata files for the enrollment authentication policy and the login authentication policy. ::: After the **User Authentication** workflow is complete, you can configure the Azure AD platform with the XML configuration of the *Controller*. For details on how to configure Azure AD, see [Configuring Azure AD with Service Provider Metadata from the Controller](docId\:NJOnS_n7fVj7YPwBgqwRy). Finally, to ensure that your users can access the authentication mechanism defined in the policies you configure through this process, make sure your *Secure Access Policies* are configured with a **User Group** in which these authentication policies are defined. To learn more, see [Creating/Editing Secure Access Policies](docId\:ndGVDPLKGsRFI6krD7rok). ### Configuring MFA with Azure AD (Optional) :::hint{type="info" indent="1"} This section describes an optional configuration activity for SAML User Authentication on Azure AD. ::: Multi-Factor Authentication (MFA) is an authentication method by which a user is granted access only after successfully presenting two (or more) pieces of evidence (or factors) to an authentication mechanism. The Azure AD platform supports MFA internally, and this can be configured so that two authentication factors are required by users for a single user authentication method. After you have configured the Azure AD platform for SAML User Authentication, you can optionally add MFA support. :::hint{type="info" indent="1"} For full details of this activity, consult the Azure AD documentation for *Azure AD Conditional Access* and *Multi-Factor Authentication*. ::: An overview of the general process is given below: 1. On Azure AD, locate the **Azure AD Conditional Access** page. 2. Create a **New Policy** with the following details: - Add a **Name** for the policy. - Under **Assignments > Users and Groups**: - Select **Select Users and Groups**. - Check the **Users and Groups** option, and select the required users and groups from the list. - Select **Done**. - Under **Assignments > Cloud Apps and Actions**: - Select **Select apps**. - Select (for example) the *zta-enroll* and *zta-auth* apps. - Select **Done**. - Under **Access Controls > Grant**: - Select **Require multi-factor authentication**. - Under **Enable Policy**: - Turn the policy **On**. - Select **Create**. 3. Locate the **Multi-Factor Authentication** page. 4. On the right-side panel, under **Configure**: - Select the **Additional cloud-based MFA settings**. :::Paragraph{indent="1"} A new tab appears. ::: :::Paragraph{listStyleType="disc" indent="2"} Enable the following MFA methods as per the requirement. ::: :::Paragraph{listStyleType="disc" indent="3"} *Call to phone*. ::: :::Paragraph{listStyleType="disc" indent="3"} *Text message to phone*. ::: :::Paragraph{listStyleType="disc" indent="2"} Select **Save**. ::: Configuration of MFA on Azure AD is complete. Mobile end users will be asked for secondary authentication information from their next login. You can then create user rules and user groups, see [Creating User Rules and User Groups](docId\:NJOnS_n7fVj7YPwBgqwRy). ### Configuring *nZTA* to use Azure AD Security Groups (Optional) :::hint{type="info" indent="1"} This section describes an optional configuration activity for SAML User Authentication on Azure AD. ::: You can configure *nZTA* to retrieve Azure AD-based user security group information through SAML attributes applied to your *User Rules*. You can create users and security groups directly in Azure AD portal. This means that Azure AD group information can be retrieved by the *Controller* through SAML attributes containing only the group’s Object ID. To instead retrieve Azure AD group information via the `sAMAccountName` attribute, create an Azure AD group in the local Active Directory and synchronize it to the cloud using *Azure AD Connect*. To create users and groups directly in the Azure AD portal: :::hint{type="info" indent="1"} This process is applicable only if you are creating users or groups directly in Azure AD. For scenarios that involve synchronizing local Active Directory users or groups to the cloud, continue to the procedure that follows this. ::: 1. Log in to the Azure AD portal 2. Navigate to your SAML SSO application, and select the **Users** page. 3. Add a new user for your organization by selecting **Create User**: ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/enuQDsGQCZlDYbsJ3glh5_azureadduser.png" alt="Adding a new user" position="flex-start" size="80" width="847" height="939" initialPath="img/azure_add_user.png" githubPath="img/azure_add_user.png" showCaption="false"} Adding a new user Enter the following details: :::Paragraph{listStyleType="disc" indent="2"} **User name**: Enter a username for the new user, appended by the domain applicable to your organization. ::: :::Paragraph{listStyleType="disc" indent="2"} **Name**: Enter the user's full display name. ::: :::Paragraph{listStyleType="disc" indent="2"} (Optional) **First Name**: Enter the user's first name. ::: :::Paragraph{listStyleType="disc" indent="2"} (Optional) **Last Name**: Enter the user's last name. ::: :::Paragraph{listStyleType="disc" indent="2"} **Password**: Select either an auto-generated or admin supplied password. ::: To create the user, select **Create**. 4. Add a new security group for your organization by navigating to the **Groups** page and selecting **New Group**: ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/V3mpjnJRR_VVhJRkMwr8j_azureaddsecgrp.png" alt="Adding a new security group" position="flex-start" size="80" width="824" height="873" initialPath="img/azure_add_secgrp.png" githubPath="img/azure_add_secgrp.png" showCaption="false"} Adding a new security group Enter the following details: :::Paragraph{listStyleType="disc" indent="2"} **Group type**: Select *Security*. ::: :::Paragraph{listStyleType="disc" indent="2"} **Group name**: Enter a name for the new security group. ::: :::Paragraph{listStyleType="disc" indent="2"} (Optional) **Group description**: Enter a description for the group. ::: :::Paragraph{listStyleType="disc" indent="2"} (Optional) **Azure AD roles can be assigned to the group**: Use the default setting. ::: :::Paragraph{listStyleType="disc" indent="2"} **Membership type**: Select *Assigned*. ::: To create the group, select **Create**. 5. In the list of groups, make a note of the **Object ID** for the newly created group: ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/LOnvwHzN4hgsNGUReJ6mW_azurelistgroups.png" alt="Viewing the Object ID for the new group" position="flex-start" size="80" width="999" height="115" initialPath="img/azure_listgroups.png" githubPath="img/azure_listgroups.png" showCaption="false"} Viewing the **Object ID** for the new group You use the **Object ID** property when configuring your *nZTAUser Rules*. 6. Assign the new user to your new security group: ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/xx4blGa_6XA6t51CrINT-_azureassignuser.png" position="flex-start" size="80" width="1301" height="311" initialPath="img/azure_assignuser.png" githubPath="img/azure_assignuser.png" showCaption="false" indent="1"} :::Paragraph{indent="1"} Assigning the new user to your new security group ::: To create Azure AD applications that facilitate retrieval of Security Group information: 1. Create two non-gallery applications under *Enterprise applications*, one for user enrollment and another for user sign-in, and configure Single Sign-On. Then, for each application, obtain the Federation Metadata XML file. For more details on this procedure, see [Workflow: Creating a SAML Authentication Policy With Azure AD](docId\:NJOnS_n7fVj7YPwBgqwRy) or follow the Azure AD user documentation. 2. Assign your applications to the required users or security groups: ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/fQLkTiI7-APtb_PcqDhlo_azureassignapps.png" alt="Assigning applications to users and security groups" position="flex-start" size="80" width="1099" height="677" initialPath="img/azure_assignapps.png" githubPath="img/azure_assignapps.png" showCaption="false"} Assigning applications to users and security groups 3. Create two new *SAML (Azure AD)* user authentication methods (user enrollment and user sign-in) in the *nZTA* Tenant Admin portal that correspond to the SAML applications created in the Azure AD portal. Upload the Federation Metadata XML file from each application to the matching method. 4. Create corresponding authentication policies and assign each Azure AD authentication method as the **Primary Auth Server**. 5. Obtain the IdP metadata files for both authentication policies and upload this data to the Azure AD portal under the respective applications. For more details, see [Configuring Azure AD with Service Provider Metadata from the Controller](docId\:NJOnS_n7fVj7YPwBgqwRy). 6. For each Azure AD application, in the *User Attributes and Claims* section, select **Edit**. ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/gwHWC9Nvhv8eqEU7J8XQs_azureeditattsclaims.png" alt="Editing the user attributes and claims for an Azure AD application" position="flex-start" size="80" width="1031" height="784" initialPath="img/azure_editattsclaims.png" githubPath="img/azure_editattsclaims.png" showCaption="false"} Editing the user attributes and claims for an Azure AD application 7. Add a new group claim to your application by selecting **Add a group claim**: ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/KQ184EICOQPzkZjSV8N5F_azureaddgrpclaim.png" alt="Adding a new group claim to your Azure AD application" position="flex-start" size="80" width="1336" height="783" initialPath="img/azure_addgrpclaim.png" githubPath="img/azure_addgrpclaim.png" showCaption="false"} Adding a new group claim to your Azure AD application In the *Group Claims* panel, enter the following details: :::Paragraph{listStyleType="disc" indent="2"} **Which groups associated with the user should be returned in the claim?**: Select "Security groups". ::: :::Paragraph{listStyleType="disc" indent="2"} **Source attribute**: ::: :::Paragraph{listStyleType="disc" indent="3"} To retrieve Azure AD security group details based on the group object ID, select "Group ID". ::: :::Paragraph{listStyleType="disc" indent="3"} To retrieve Azure AD security group details based on the group name, select "sAMAccountName". This option is available only for groups synchronized from Active Directory. ::: :::Paragraph{indent="2"} ::: :::Paragraph{indent="1"} To specify a different claim type for group claims, select **Customize the name of the group claim** and specify the claim type in the **Name** field. For example, if you specify "ADgroup", the group claim is emitted as `userAttr.ADgroup` or `samlMultiValAttr.ADgroup`. ::: ```javascript userAttr.http://schemas.microsoft.com/ws/2008/06/identity/claims/groups samlMultiVarAttr.http://schemas.microsoft.com/ws/2008/06/identity/claims/groups ``` :::Paragraph{indent="1"} By default, Azure AD populates SAML attributes for group claims in the format: ::: To add the new group claim, select **Save**. 8. Return to the *nZTA* Tenant Admin portal and navigate to the **Secure Access > Manage Users > User Groups and Rules > User Rules** page. Create a new user rule to access the Azure AD group attribute. Configure the following settings: - **Rule name**: Enter a descriptive name for the rule - **Select Attribute Type**: Select "SAML (Azure AD)". - **SAML Attribute Type**: Select "Group". - **Attribute value**: Use one of the following options: - If you created the security group in Azure AD, use the group *Object ID* as noted earlier in the process: ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/lViCCmE4xovAaTSZw1BCT_azureuserruleoid.png" alt="Specifying an Object ID as the group attribute value" position="flex-start" size="80" width="2042" height="1174" initialPath="img/azure_userrule_oid.png" githubPath="img/azure_userrule_oid.png" showCaption="false"} :::Paragraph{indent="3"} Specifying an Object ID as the group attribute value ::: :::Paragraph{listStyleType="disc" indent="3"} If you synchronized your security group to Azure AD from a local Active Directory, use the *Group Name*. ::: ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/EIQWYQFxqmZGJF1apP6Ss_azureuserruleobjnm.png" alt="Specifying an Object Name as the group attribute value" position="flex-start" size="80" width="2042" height="1178" initialPath="img/azure_userrule_objnm.png" githubPath="img/azure_userrule_objnm.png" showCaption="false" indent="4"} :::Paragraph{indent="3"} Specifying an Object Name as the group attribute value ::: The following expressions are examples of Azure AD group attribute values: :::Paragraph{listStyleType="disc" indent="2"} Users that are members of only the identified group: ::: ```javascript userAttr.{http://schemas.microsoft.com/ws/2008/06/identity/claims/groups} = "" ``` :::Paragraph{listStyleType="disc" indent="2"} Users that are members of only the named group (for AD groups synchronized from a local Active Directory): ::: ```javascript userAttr.{http://schemas\.microsoft\.com/ws/2008/06/identity/claims/groups} = "" ``` :::Paragraph{listStyleType="disc" indent="2"} Users that are members of only the identified group: ::: ```javascript userAttr. = "" ``` :::Paragraph{listStyleType="disc" indent="2"} Users that are members of only the named group (for AD groups synchronized from a local Active Directory): ::: ```javascript userAttr. = "" ``` :::hint{type="info"} To add SAML multi-valued attributes (`samlMultiValAttr.`) in Azure AD User Rules, you must set **Select Attribute Type** to "SAML (Custom)". This applies to the following examples: ::: :::Paragraph{listStyleType="disc" indent="2"} Users that are members of either identified group: ::: ```javascript samlMultiValAttr.{http://schemas\.microsoft\.com/ws/2008/06/identity/claims/groups} = ("" or "") ``` :::Paragraph{listStyleType="disc" indent="2"} Users that are members of both identified groups: ::: ```javascript samlMultiValAttr.{http://schemas\.microsoft\.com/ws/2008/06/identity/claims/groups} = ("" and "") ``` :::Paragraph{listStyleType="disc" indent="2"} Users that are members of either named group (for AD groups synchronized from a local Active Directory): ::: ```javascript samlMultiValAttr.{http://schemas\.microsoft\.com/ws/2008/06/identity/claims/groups} = ("" or "") ``` :::Paragraph{listStyleType="disc" indent="2"} Users that are members of both named groups (for AD groups synchronized from a local Active Directory): ::: ```javascript samlMultiValAttr.{http://schemas\.microsoft\.com/ws/2008/06/identity/claims/groups} = ("" and "") ``` :::Paragraph{listStyleType="disc" indent="2"} Users that are members of either named group (for AD groups synchronized from a local Active Directory): ::: ```javascript samlMultiValAttr. = ("" or "") ``` :::Paragraph{listStyleType="disc" indent="2"} Users that are members of both named groups (for AD groups synchronized from a local Active Directory): ::: ```javascript samlMultiValAttr. = ("" and "") ``` 9. To create the User Rule, select **Create**. 10. Create a new **User Rule Group** and select the User Authentication Policy (Enrollment or Sign-in) that is applicable to this service. Then, in the list of *User Rules*, select the rule you created in the previous step: ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/-RHnCR45-BM8VkNY2FFqg_azureaddrulegrp.png" alt="Configuring a User Rule Group with a User Authentication Policy and User Rule" position="flex-start" size="80" width="2058" height="1326" initialPath="img/azure_addrulegrp.png" githubPath="img/azure_addrulegrp.png" showCaption="false"} Configuring a User Rule Group with a User Authentication Policy and User Rule 11. To create the User Rule Group, select **Create**. 12. Proceed to create your **Secure Access Policy**, selecting the applicable *Application*, *Gateway*, *Device Policy* and the *User Rule Group* created during this procedure. ## Workflow: Creating an Authentication Policy for On-Premises *ICS* SAML You can choose to use a configured *ICS* server (either remote or local) as an on-premises SAML AD authentication server for your *Controller*. :::hint{type="info" indent="1"} If you choose to use SAML authentication on your *Controller*, you do not create any users manually. All users will already be present on your remote SAML server. ::: Configuring *nZTA* to use SAML authentication requires you to create separate SAML apps on the on-premises *ICS* server for the following primary activities: - User enrollment - User sign-in The *Controller* includes built-in default authentication policies for each of these purposes and includes the ability to create your own custom policies for separate authentication of specific groups. You create an authentication method referencing one of the SAML apps described above and then assign the method to an authentication policy of the same type (either the built-in policy, or one you create). Begin with enrollment, and then repeat the process for user sign-in. To configure *nZTA* to use SAML authentication through *ICS*, perform the following steps: 1. Configure your on-premises *ICS* to act as a SAML AD authentication server: - Optionally, [Configuring Secondary Authentication for On-Premises ICS (Optional)](docId\:NJOnS_n7fVj7YPwBgqwRy). - [Configuring a SAML Identity Provider in Ivanti Connect Secure](docId\:NJOnS_n7fVj7YPwBgqwRy). - [Configuring a Metadata Provider in Ivanti Connect Secure](docId\:NJOnS_n7fVj7YPwBgqwRy). 2. Define an on-premises SAML authentication method, see [Defining an On-Premises SAML Authentication Method](docId\:NJOnS_n7fVj7YPwBgqwRy). 3. Configure an on-premises SAML authentication policy, see [Defining Authentication Policies for On-Premises SAML Authentication](docId\:NJOnS_n7fVj7YPwBgqwRy). 4. After you complete the User Authentication workflow, configure the SAML apps on the on-premises *ICS* server with the XML metadata configuration from the matching *nZTA* authentication policy, see [Configuring ICS with Controller Metadata](docId\:NJOnS_n7fVj7YPwBgqwRy). :::hint{type="info" indent="1"} You will need to repeat this process for each required SAML app on your *ICS* server. ::: To ensure that your users can access the authentication mechanism defined in the policies you configure through this process, make sure your *Secure Access Policies* are configured with a **User Group** in which these authentication policies are defined. To learn more, see [Creating/Editing Secure Access Policies](docId\:ndGVDPLKGsRFI6krD7rok). ### Configuring Secondary Authentication for On-Premises *ICS* (Optional) :::hint{type="info" indent="1"} This section describes an optional configuration activity for SAML User Authentication on an on-premises *ICS* server. ::: Multi-Factor Authentication (MFA) is an authentication method by which a computer user is granted access only after successfully presenting two (or more) pieces of evidence (or factors) to an authentication mechanism. The ICS platform supports a number of secondary authentication solutions, and can be configured so that two authentication factors are required by users using a single nZTA user authentication method. Before you configure the on-premises ICS server and Controller for SAML User Authentication, you can choose to configure MFA (secondary) support to ICS. :::hint{type="info" indent="1"} Before you start this procedure, you must have fully configured a secondary authentication server. For example, *Google OTP (One Time Password)* or *NAS OTP*. For the purposes of this example, an existing local *Google OTP* server is used, but different established secondary authentication methods are also supported. ::: To configure *ICS* for secondary authentication: 1. Log in to the on-premises *Ivanti Connect Secure* server. 2. On the **Authentication** menu, select **Auth. Servers**. The **Authentication Servers** page appears. 3. Under **New**, select the required authentication server type. For example, select *Time based One Time Password (TOTP) Server*. 4. Select **New Server**. The **New Time based One Time Password (TOTP) Server** page appears. 5. Enter the following parameters for the new server: - Add a **Name** for the server, for example *Google OTP*. - Select the **Allow Auto Unlock** check box, and set **Auto unlock period**. For example, 10 minutes. - Select the **Allow new TOTP user registration to happen via External Port** check box. - Select the **Allow TOTP authentication from Remote Pulse Secure Devices** check box. - Leave all other parameters as their default settings. 6. Select **Save Changes**. The new server (Google OTP) is added to the list of **Authentication Servers**. 7. You must now add a new user to the local system. To do this: - In the **Authentication Servers** list, select the hyperlink for the *System Local* entry. - The **Settings** page for *System Local* appears. - Select the **Users** tab. - Select **New** to create a user. - The **New Local User** page appears. - Enter details for the user, and ensure that the **Enabled** check box is selected, and that other check boxes are clear. - Select **Save Changes** to create the user. 8. Select the **Users** menu, then select **User Realms**. The **User Authentication Realms** page appears. 9. You must now enable secondary authentication. To do this: - In the **User Authentication Realms** list, select the hyperlink for the *Users* entry. :::Paragraph{indent="1"} The **General** page for the *Users* realm appears. ::: :::Paragraph{listStyleType="disc" indent="2"} Under **Additional authentication server**, select the **Enable additional authentication server** check box. ::: :::Paragraph{listStyleType="disc" indent="2"} Set **Authentication #2** to *Google OTP*. ::: :::Paragraph{listStyleType="disc" indent="2"} At the bottom of the page, select **Save Changes**. ::: You can now configure an Identity Provider in *ICS*, see [Configuring a SAML Identity Provider in Ivanti Connect Secure](docId\:NJOnS_n7fVj7YPwBgqwRy). ### Configuring a SAML Identity Provider in *Ivanti Connect Secure* This section describes the steps to configure a SAML Identity Provider (IdP) on an on-premises *Ivanti Connect Secure* (*ICS*) server. The metadata for the IdP is required by each SAML user method on *nZTA*. To configure SAML IdP on the *Ivanti Connect Secure* server: 1. Log in to the on-premises *Ivanti Connect Secure* server that is identified as an Identity Provider. 2. Navigate to **System > Configuration > SAML > Settings**. 3. Configure the following Metadata Server Configuration: - **Timeout value for metadata fetch request** to 300. - **Host FQDN for SAML** to the Fully Qualified Domain Name, noting the host FQDN guidance below. The host FQDN specified here is used in the SAML entity ID, used by browsers to connect to *ICS*, and used in the URLs for SAML services. Typically: :::Paragraph{listStyleType="disc" indent="2"} If the *ICS* is standalone, the FQDN should resolve to the IP address of the external interface / internal interface, whichever is chosen. ::: :::Paragraph{listStyleType="disc" indent="2"} If the *ICS* is an Active-Passive cluster, the FQDN should resolve to the external VIP / Internal VIP, whichever is chosen. ::: :::Paragraph{listStyleType="disc" indent="2"} If the *ICS* is an Active-Active cluster behind an in-line load balancer, the FQDN should resolve to the load balancer's external VIP / Internal VIP, whichever is chosen. ::: 4. Select **Save Changes**. 5. Select **Update Entity IDs** and confirm this action on the warning page by selecting **Update Entity IDs**. 6. Navigate to **System > Configuration > Certificates > Device Certificate**, create a new CSR, and import certificate and keys. Skip this step if the *ICS* external interface / internal interface (whichever is chosen) already provides a certificate that matches the host’s Fully Qualified Domain Name. 7. Navigate to **Authentication > Signing In > Sign In SAML > Identity Provider**. 8. Locate the the **Basic Identity Provider (IdP) Configuration** section. 9. Under **Protocol Binding to use for SAML Response**: - Select the **Post** check box. - Clear the **Artifact** check box. - Select the required **Signing Certificate**. 10. Under Other Configurations: - Select the **Accept unsigned AuthnRequest** check box. - Select **sha-256** for Signature Algorithm, if ICS is using 22.x version onwards. 11. Under Service-Provider-related IDP Configuration: - For **SignIn Policy**, select the *\*/* policy. 12. Under **User Identity**: - For **Subject Name Format**, select Email Address. - For **Subject Name**, enter \. - At the bottom of the page, select **Save Changes**. You can now configure a Metadata Provider in *ICS*, see [Configuring a Metadata Provider in Ivanti Connect Secure](docId\:NJOnS_n7fVj7YPwBgqwRy). ### Configuring a Metadata Provider in *Ivanti Connect Secure* This section describes the steps to configure *Ivanti Connect Secure* to be a Metadata Provider, and to download metadata for use on the *Controller*. To configure a Metadata Provider in the on-premises *ICS* server: 1. Log in to *Ivanti Connect Secure* server. 2. Navigate to **Authentication > Signing-In > Sign In SAML > Metadata Provider**. The SAML Metadata Provider Entity Id property is pre-populated. It is generated by the system, based on the value for the Host FQDN for SAML setting on the **System > Configuration > SAML > Settings** page. 3. Set **Metadata Validity** to 365 days. 4. Clear the **Do Not Publish IdP in Metadata** check box. 5. Select **Save Metadata Provider**. 6. Select **Download Metadata** and save the file to your computer. :::Paragraph{indent="1"} This definition file is required to enable on-premises SAML apps on the *Controller*. ::: You can then configure the *Controller* to use an on-premises SAML Server, see [Defining an On-Premises SAML Authentication Method](docId\:NJOnS_n7fVj7YPwBgqwRy). ### Defining an On-Premises SAML Authentication Method A minimum of two authentication methods are required: - An authentication method for a SAML enrollment sign-in app. - An authentication method for a SAML user sign-in app. To create an on-premises SAML server authentication method for a specific activity, for example, device enrollment: 1. Log into the *Controller* as a Tenant Admin, see [Logging in as a Tenant Administrator](docId\:qAQLPFWfOt_GYC0QQw64z). 2. From the *nZTA* menu, select the **Secure Access** icon, then select **Manage Users > Authentication Servers**. The *Authentication Servers* page appears. This page lists all existing user authentication methods: ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/JG5DXNUi5d4ABiF1lk_sb_usermethodsstart.png" alt="User Authentication Methods" position="flex-start" size="80" width="1045" height="625" initialPath="img/user_methods_start.png" githubPath="img/user_methods_start.png" showCaption="false"} User Authentication Methods 3. Select **Create Authentication Server**. A form appears that enables you to define the authentication method: ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/CrHWDlqAuQYpUChz-Y01k_wizusermethodsstart.png" alt="Creating a user authentication method" position="flex-start" size="80" width="895" height="918" initialPath="img/wiz_user_methods_start.png" githubPath="img/wiz_user_methods_start.png" showCaption="false"} Creating a user authentication method :::hint{type="info"} At any point during this process, you can reset the form data by selecting **Reset Vields**. ::: 4. Under **Choose Server Name and Authentication Type**: - Select the **Authentication Type** of *SAML (Custom)*. The form expands to show additional settings: ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/Qt3llHPBFv34RZQ1k71kh_wizusermethodssamlcustom.png" alt="Configuring SAML (Custom) authentication settings" position="flex-start" size="80" width="1168" height="751" initialPath="img/wiz_user_methods_samlcustom.png" githubPath="img/wiz_user_methods_samlcustom.png" showCaption="false"} :::Paragraph{indent="2"} Configuring SAML (Custom) authentication settings ::: Specify an **Authentication Server Name**. For example: *Enrollment* or *SignIn*. 1. To provide your SAML IdP settings, select one of the following: - Select **Upload SAML Auth metadata file** if not selected already. This is selected by default. The **Download Auth Service Provider Metadata for IDP** link is enabled. 1. (Optional) Specify a **Single Logout URL**. For more information, see [Using SAML Single Logout to Force User Authentication](docId\:NJOnS_n7fVj7YPwBgqwRy). :::hint{type="info"} By default, the *Controller* expects a signed metadata definition file. To allow an unsigned metadata file, select **Allow Unsigned Metadata**. ::: :::Paragraph{indent="3"} Click the **Download Auth Service Provider Metadata for IDP** link. Retain the downloaded file for later use. ::: :::Paragraph{listStyleType="disc" indent="2"} Select **Enter SAML Auth metada details manually** to manually enter the required IdP SAML settings. Use this option in scenarios where a SAML federation metadata file is not available or incomplete. Then, enter the following details: ::: ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/R0z4b7hmWmnx5TG6KVDUQ_wizusermethodssamlmanual.png" alt="Configuring SAML (Azure AD) IdP settings manually" position="flex-start" size="80" width="913" height="511" initialPath="img/wiz_user_methods_saml_manual.png" githubPath="img/wiz_user_methods_saml_manual.png" showCaption="false" indent="3"} :::Paragraph{indent="2"} Configuring SAML (Azure AD) IdP settings manually The following minimum settings are required for your SAML authentication service to function correctly. Each setting relates to a value configured in the SAML application on your IdP. Contact your IdP administrator to obtain the relevant details: ::: :::Paragraph{listStyleType="disc" indent="3"} **IDP Entity ID**: The entity ID is sent as the Issuer value in the SAML assertion generated by the IdP. Specify the Issuer value in assertions generated by the SAML identity provider. ::: :::Paragraph{listStyleType="disc" indent="3"} **IDP SSO URL**: A URL provisioned by the SAML IdP to support service-provider-initiated Single Sign-On. Use the format `https://`. ::: :::Paragraph{listStyleType="disc" indent="3"} **IDP SLO Service**: (Optional) A URL to specify the Single Log-Out/sign out endpoint if you want to force re-authentication for increased security. Use the format `https://`. For more information, see [Using SAML Single Logout to Force User Authentication](docId\:NJOnS_n7fVj7YPwBgqwRy). ::: :::Paragraph{listStyleType="disc" indent="3"} **User Name Template**: Specify how the system is to derive the username from the SAML assertion. The default value can be used, or replaced with an alternative specifier that the *Controller* uses from the incoming assertion. For example: ``, the NameID value where *ICS* is the IdP, the UID from X509SubjectName, ``, attr from AttributeStatement attributes. ::: :::Paragraph{listStyleType="disc" indent="3"} **IDP Signing Certificate**: The signing certificate to be used with the SAML app on the IdP. Type or paste in the contents of your Base-64 encoded public key. ::: :::hint{type="info"} \- When editing an existing SAML Auth server, the 'Enable Enrollment' option can be enabled or disabled if the SAML Auth server is not being used in any ‘User Policy’. If the SAML Auth server is being used in a ‘User Policy’, then Enable Enrollment button will be grayed out. \- If 'Enable Enrollment' is not selected, then while creation of 'User Policy' of type 'User', the server you have created (without Enable Enrollment) will not be listed. \- When Enrollment is disabled, the enrollment SAML configuration will be deleted. To enable enrollment, you have to again provide enroll SAML auth server configuration. ::: 1. Confirm that your settings are correct, then select **Create Authentication Server** to create the authentication method. The new SAML authentication method is added to the list of methods and the process is complete. 2. (Optional) To edit a listed authentication method, select the adjacent check box, then select **Actions > Edit**. Make any required updates and confirm. 3. (Optional) To delete one (or more) an *unused* authentication methods, select the check box for each, then select **Actions > Delete**. You must confirm the deletion. You can now proceed to update the required authentication policy, see [Defining Authentication Policies for On-Premises SAML Authentication](docId\:NJOnS_n7fVj7YPwBgqwRy). ### Defining Authentication Policies for On-Premises SAML Authentication After you have created your SAML authentication method, create or update your authentication policies with the new authentication method. From the *nZTA* menu, select the **Secure Access** icon, then select **Manage Users > User Policies**. The **User Policies** page appears. This page lists all existing user authentication policies. ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/cSoGaqZPVBr9OTuyk94aq_userpoliciesstart.png" position="flex-start" size="80" width="997" height="607" initialPath="img/user_policies_start.png" githubPath="img/user_policies_start.png" showCaption="false"} :::Paragraph{indent="1"} User Authentication Policies ::: To learn more about the policies on this page, see [Viewing User Authentication Policies](docId\:NJOnS_n7fVj7YPwBgqwRy). From this page, either create a new custom policy or edit an existing policy. To add a new custom policy: 1. Select **Create User Policy**. The **Create Authentication Policy** form appears. ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/97lDbU6p1D5VPiey1vLec_adduserpolicystart.png" alt="Add User Authentication" position="flex-start" size="80" width="901" height="703" initialPath="img/add_user_policy_start.png" githubPath="img/add_user_policy_start.png" showCaption="false"} Add User Authentication :::hint{type="info"} At any point during this process, you can reset the form data by selecting **Reset Fields**. ::: :::hint{type="info"} To learn more about how custom policies are used for user login and enrollment, see [Adding Custom Authentication Policies](docId\:NJOnS_n7fVj7YPwBgqwRy). ::: 2. Enter a **Policy Name**. 3. Enter a **Login URL** using the format *\*/login/\/*. The URL must start with "*\*/login/*" and cannot contain any special characters. \ should be set to a unique value reflecting the endpoint URL you want to define for this authentication policy (appended with a backslash): - In the case of user sign-in policies, this is the URL endpoint (appended to the tenant FQDN) to which new users are invited to connect to enroll or sign-in a device with the *Controller*. Example value: "*\*/login/saleslogin/*". - In the case of user enrollment policies, this endpoint identifies the enrollment URL to which users are redirected if they attempt to connect to the equivalent sign-in policy with an un-enrolled device. In most cases, you do not advertise this endpoint to your users. Example value: "*\*/login/salesenroll/*". :::hint{type="info"} In some enrollment circumstances, such as when using a device pre-installed with an older version of *Ivanti Secure Access Client*, you connect directly to the enrollment policy endpoint to enroll the device. For more details, see [Using User Authentication Policies](docId\:NJOnS_n7fVj7YPwBgqwRy). ::: 1. (Optional) Enter a description for the authentication policy. 2. Select a **User Type** based on the intended authentication activity for this policy. Choose from: - **Users**: Select this option to define the user sign-in endpoint for enrolled devices. This is the endpoint that you provide to your users to access the service (regardless of enrollment status). - **Administrators**: Select this option to define the authentication endpoint for administrator-level sign-in. This endpoint is used for administrator login to the *Controller* only. 3. (for policies with a **User Type** of "Users" only): Select an **Enroll Device Policy** from the drop-down list to be linked to this sign-in policy (as indicated): ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/8YZR7bxf-cDgYHmD86P30_authpolicyusertype.png" alt="Linking an enrollment policy to a user sign-in policy" position="flex-start" size="80" width="805" height="400" initialPath="img/auth_policy_user_type.png" githubPath="img/auth_policy_user_type.png" showCaption="false"} Linking an enrollment policy to a user sign-in policy This is the enrollment policy to which a user is redirected if it is determined that the device is not yet enrolled. To learn more, see [Using User Authentication Policies](docId\:NJOnS_n7fVj7YPwBgqwRy). 7. Under **Policy Server Details**, select **Primary Auth Server** and choose the required authentication method from the drop-down list: ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/e1o3T_FjCr2Gbadx6rxyb_authpolicyauthserver.png" alt="Selecting a primary authentication method for this policy" position="flex-start" size="80" width="976" height="447" initialPath="img/auth_policy_auth_server.png" githubPath="img/auth_policy_auth_server.png" showCaption="false"} Selecting a primary authentication method for this policy Alternatively, select *Create Authentication Server* and create a new authentication method as per the steps described earlier in this section. 8. (Optional) Where a secondary method is required for Multi-Factor Authentication, repeat the previous step for **Secondary Auth Server**. :::hint{type="info"} Secondary authentication methods do not apply to *Enrollment User* type policies. The relevant field is hidden in this case. ::: 1. Select **Add** to create the new policy. :::Paragraph{indent="1"} The new policy is added to the list of authentication policies. ::: If you instead elect to update an existing custom or built-in policy: 1. Select the check box adjacent to the relevant policy, then select **Actions > Edit**. The **Edit authentication policy** form appears. :::hint{type="info"} For built-in authentication policies, all properties except **Primary Auth Server** and **Secondary Auth Server** (where applicable) are read-only. ::: 1. Set the **Primary Auth Server** to be the new SAML user authentication method (indicated): ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/WdkayFlnlTGclk4Dq51SU_editauthpolicyserverdetails.png" alt="Editing the primary auth server" position="flex-start" size="80" width="889" height="628" initialPath="img/edit_auth_policy_server_details.png" githubPath="img/edit_auth_policy_server_details.png" showCaption="false"} Editing the primary auth server :::hint{type="info"} SAML authentication can be used only as a Primary Auth Server. If you are using MFA, specify either a *local authentication* or *TOTP* method as the **Secondary Auth Server**. ::: :::hint{type="info"} If you configure a secondary authentication method in a policy that is currently in use, any active user sessions must be disconnected and reconnected for the changes to take effect. ::: 3. Select **Update User Policy**. :::Paragraph{indent="1"} The list of authentication policies updates. ::: At this point, the *Controller* uses the uploaded metadata to contact the SAML service. After this process completes, a **Download** function becomes available for the policy. This metadata file is required to configure trusted communication with the remote SAML service. Perform the following steps: 1. Refresh your browser until the **Download** action is visible for the relevant policy. 2. Select the check box for the policy and clear all other check boxes. 3. Select **Download** and save the metadata file. :::hint{type="info" indent="1"} Repeat these procedures for each required SAML app on your On-Prem *ICS* server. That is, you require separate XML metadata files for your enrollment authentication policy and your sign-in authentication policy. ::: After you have configured a user authentication policy, you can configure your *ICS* SAML app with the SP Metadata configuration of the *Controller*, see [Configuring ICS with Controller Metadata](docId\:NJOnS_n7fVj7YPwBgqwRy). ### Configuring *ICS* with *Controller* Metadata Before the *Controller* can use a SAML server on an on-premises *ICS* server, you must enable communication between each separate SAML app on the *ICS* server and the *Controller*. To do this, you must configure the SAML apps on the on-premises *ICS* server with the XML metadata configuration file for the *Controller*. There are a minimum of two SAML apps: - A SAML app for user enrollment. For example, called *Enrollment*. - A SAML app during user sign-in. For example, called *Signin*. :::hint{type="info" indent="1"} You download the *Controller* XML configuration file when you selected an authentication policy. Alternatively, select the policy, then select **Download** on the **User authentication policies** page, see [Viewing User Authentication Policies](docId\:NJOnS_n7fVj7YPwBgqwRy). ::: To configure a SAML app on *ICS* with XML from the *Controller*: 1. Log into your *ICS* platform. 2. Navigate to **System > Configuration > SAML**. 3. Select **New Metadata Provider**. 4. Enter a **Name** for the metadata provider. 5. Under **Metadata Provider Location Configuration**: - For **Location**, select *Local*. - For **Upload Metadata File**, select **Browse** and select the metadata that you saved on your computer in the previous process (see above). 6. Under **Metadata Provider Verification Configuration**: - Select the **Accept Unsigned Metadata** check box. 7. Under **Metadata Provider Filter Configuration**: - For **Roles**, select the Service Provider check box. 8. Select **Save Changes**. 9. Navigate to **Authentication > Signing In > Sign-In SAML > Identity Provider**. 10. In the **Configuration** section, select **Add SP**. The New Peer Service Provider page appears. 11. In the **Service Provider Configuration** and **Certificate Status Checking Configuration** sections, make the necessary service provider specific settings. For more details, refer to the "Configuring Sign-in SAML Identity Provider Settings" section in the "*Ivanti Connect Secure* Administration Guide". 12. In the **Customize IdP Behavior** section, select the **Override Default Configuration** check box. 13. Clear the **Reuse Existing NC (Pulse) Session** check box. 14. Select the **Accept unsigned AuthnRequest** check box. 15. At the bottom of the page, select **Save Changes**. After the on-premises *ICS* SAML service is configured to connect to the *Controller*, you can then create a user group to apply the newly created authentication policy to your secure applications, see [Creating User Rules and User Groups](docId\:NJOnS_n7fVj7YPwBgqwRy). ## Workflow: Creating a SAML Authentication Policy for Okta *nZTA* supports the use of Okta as a SAML service to provide authentication for your users. If you choose to use Okta as a SAML Identity Provider (IdP), you do not create any users locally on the *Controller*. All users will already be present in your remote SAML service. The process to configure Okta as a custom SAML authentication method within *nZTA* involves the following steps: 1. Create your Okta application and obtain the SAML IdP metadata, see [Creating an Okta SAML Application](docId\:NJOnS_n7fVj7YPwBgqwRy). 2. Define an Okta SAML authentication method in *nZTA* and associate it with your authentication policies, see [Defining and Applying Okta Authentication in nZTA](docId\:NJOnS_n7fVj7YPwBgqwRy). Configuring *nZTA* to use Okta SAML authentication requires configuration of two separate authentication policies on the *Controller*, *user enrollment* and *user sign-in*. The *Controller* includes built-in default authentication policies for each of these purposes, and also includes the ability to create your own custom policies should you require this authentication mechanism to apply only to a sub-set of your users. Therefore, complete the above steps for each of these policies in turn. Begin with enrollment, and then repeat the process for user sign-in. To ensure that your users can access the authentication mechanism defined in the policies you configure through this process, make sure your *Secure Access Policies* are configured with a **User Group** in which these authentication policies are defined. To learn more, see [Creating/Editing Secure Access Policies](docId\:ndGVDPLKGsRFI6krD7rok). Before you start, make sure you know the following information: - The default Assertion Consumer Service (ACS) URL: - For the user enrollment policy, the ACS URL uses the form: `https:///dana-na/auth/saml-consumer.cgi` (For example, `https://zta1.example.com/dana-na/auth/saml-consumer.cgi`) - For the user sign-in policy, the ACS URL uses the form: `https:///dana-na/auth/saml-consumer.cgi` (For example, `https://zta1.e.example.com/dana-na/auth/saml-consumer.cgi`) - The SP Entity ID of *nZTA* for your integration: - For the user enrollment policy, the SP Entity ID uses the form: `https:///dana-na/auth/saml-endpoint.cgi?p=sp1` (For example, `https://zta1.example.com/dana-na/auth/saml-endpoint.cgi?p=sp1`) - For the user sign-in policy, the SP Entity ID uses the form: `https:///dana-na/auth/saml-endpoint.cgi?p=sp2` (For example, `https://zta1.e.example.com/dana-na/auth/saml-endpoint.cgi?p=sp2`) ### Creating an Okta SAML Application :::hint{type="info" indent="1"} \- To fully configure Okta as a SAML authenticator in *nZTA*, complete these steps for each of your user enrollment and user sign-in policies in turn. \- For the latest configuration details, see Okta Documentation. ::: To create a new Okta application and obtain the SAML IdP Metadata file: 1. Log in to your Okta account and select *Classic UI* mode. 2. In the Admin Console, navigate to **Applications > Applications**. 3. Select **Add Application**. 4. Start the *Application Integration Wizard* by selecting **Create New App**. 5. For **Platform**, select "Web". 6. For **Sign-on method**, select "SAML 2.0". 7. Select **Create**. 8. In the *General Settings* tab, enter an application name. :::hint{type="info"} *Ivanti* advises using a descriptive name that relates to the user authentication policy this application is created for. ::: 1. (Optional) Upload a logo for the application. 2. In the *Configure SAML* tab, enter the following information corresponding to the authentication policy for which you are creating this application. - **Single sign on URL**: Enter your ACS URL - **Audience URI (SP Entity ID)**: Enter your *nZTA* Entity ID - **Name ID Format**: Select "Email Address" - **Application username**: Select "Okta username". - (Optional) If you want to use Okta group membership policies to categorize users, complete the **Fill in Group Attribute Statements** section to filter users by group membership in the SAML assertion. For example, to set a filter that returns all groups to which the user is assigned, you might enter the following details: - **Name**: ZTAGroups - **Filter**: Matches Regex - **Value**: .\* :::Paragraph{indent="2"} For more information, see [Using Okta Group Attribute Statements to Categorize Users](docId\:NJOnS_n7fVj7YPwBgqwRy). ::: :::Paragraph{listStyleType="disc" indent="2"} For all other fields, use the default values. ::: 11. Select **Next** to continue. 12. For **Are you a customer or partner?**, select the option that is most applicable. 13. Select **Finish**. The *Settings* page for your application appears. 14. In the *Sign On* tab, download the **Identity Provider metadata** file. Save this file to your local workstation. 15. In the *Applications* tab, select **Assign Applications**. Then select **Assign to People** or **Assign to Groups** as per your requirements. - For each user or group you want to assign to your application, select **Assign** against the respective item. - After you have completed your assignments, select **Done**. 16. Proceed to define a new authentication method in *nZTA*, see [Defining and Applying Okta Authentication in nZTA](docId\:NJOnS_n7fVj7YPwBgqwRy). ### Using Okta Group Attribute Statements to Categorize Users :::hint{type="info" indent="1"} This section is applicable only to scenarios where Okta SAML authentication is augmented with user categorization through group attribute policies. ::: To configure Okta with group membership policies, and to enable *nZTA* to query these policies when authenticating access requests, add *Group Attribute Statements* to your Okta user enrollment and user sign-in applications. Then, update your enrollment and sign-in *User Rules* within *nZTA* to use the corresponding *Custom* SAML attributes. The following table lists common Okta *Group Attribute Statements*, designed to return matching user groups in a SAML assertion: :::hint{type="info" indent="1"} The attribute name "ZTAGroups" is used here as an example. Use the attribute tag which corresponds to your Okta group configuration. ::: | Okta Group Attribute Name | Okta Group Attribute Filter | Groups Returned | | ------------------------- | --------------------------- | --------------------------------------------- | | ZTAGroups | Contains: ZTA | All groups containing "ZTA" (ignores case) | | ZTAGroups | StartsWith: ZTA | All groups starting with "ZTA" (ignores case) | | ZTAGroups | Equals: ZTAUsers | The "ZTAUsers" group only | | ZTAGroups | Matches regex: .\* | All groups to which the user is assigned | The following are examples of Okta custom SAML expressions for use within *nZTAUser Rules*: - Users that are members of only the named group: ```javascript userAttr.ZTAGroups = "ZTAGroup1" ``` - Users that are members of either named group: ```javascript userAttr.ZTAGroups = ("ZTAGroup1" or "ZTAGroup2") ``` - Users that are members of either named group, or both groups: ```javascript samlMultiValAttr.ZTAGroups = ("ZTAGroup1" or "ZTAGroup2") ``` - Users that are only members of both named groups: ```javascript samlMultiValAttr.ZTAGroups = ("ZTAGroup1" and "ZTAGroup2") ``` - Users that are members of "ZTAGroup1", but not members of "ZTAGroup2": ```javascript samlMultiValAttr.ZTAGroups = "ZTAGroup1" and samlMultiValAttr.ZTAGroups != "ZTAGroup2" ``` - Users that are members of either "ZTAGroup1" or "ZTAGroup2", or both groups, and also a member of "ZTAGroup3": ```bash samlMultiValAttr.ZTAGroups = ("ZTAGroup1" or "ZTAGroup2") and samlMultiValAttr.ZTAGroups = "ZTAGroup3" ``` To learn more about adding custom SAML user rules, see [Creating User Rules](docId\:NJOnS_n7fVj7YPwBgqwRy). ## Defining and Applying Okta Authentication in *nZTA* :::hint{type="info" indent="1"} To fully configure Okta as a SAML authenticator in *nZTA*, complete these steps for each of your user enrollment and user sign-in policies in turn. ::: To define a new authentication method using Okta as the SAML IdP: 1. Log into the *Controller* as a Tenant Admin, see [Logging in as a Tenant Administrator](docId\:qAQLPFWfOt_GYC0QQw64z). The **Network Overview** page appears. 2. From the *nZTA* menu, select the **Secure Access** icon, then select **Manage Users > Authentication Server**. The *Authentication Server* page appears. This page lists all existing user authentication methods. 3. To add a new custom SAML authentication method, select **Create Authentication Server**. The **Create Authentication Server** form appears: ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/CrHWDlqAuQYpUChz-Y01k_wizusermethodsstart.png" alt="Adding a user authentication method" position="flex-start" size="80" width="895" height="918" initialPath="img/wiz_user_methods_start.png" githubPath="img/wiz_user_methods_start.png" showCaption="false"} Creating an authentication server :::hint{type="info"} At any point during this process, you can reset the form data by selecting **Reset Fields**. ::: 4. Under **Choose Server Name and Authentication Type**: - Select the **Authentication Type** of *SAML (Custom)*. - The form expands to show additional settings: ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/u4sG9ehgxBeFR368z9iby_oktaaddauthmethod.png" alt="Configuring Okta SAML authentication settings" position="flex-start" size="80" width="895" height="750" initialPath="img/okta_addauthmethod.png" githubPath="img/okta_addauthmethod.png" showCaption="false"} :::Paragraph{indent="2"} Configuring Okta SAML authentication settings Specify an **Authentication Server Name**. For example: *SAML\_Okta\_Enroll* or *SAML\_Okta\_SignIn*. ::: 2. (Optional) Specify a **Single Logout URL**. For more information, see [Using SAML Single Logout to Force User Authentication](docId\:NJOnS_n7fVj7YPwBgqwRy). 3. To provide your SAML IdP settings, select one of the following: - Select **Upload SAML Auth metadata file** to upload a digitally-signed (or unsigned) Okta Identity Provider (IdP) metadata file, as obtained while creating a new Okta SAML application for this activity. That is, for either user enrollment or user sign-in. See [Creating an Okta SAML Application](docId\:NJOnS_n7fVj7YPwBgqwRy). The **Download Auth Service Provider Metadata for IDP** link is enabled. 1. (Optional) Specify a **Single Logout URL**. For more information, see [Using SAML Single Logout to Force User Authentication](docId\:NJOnS_n7fVj7YPwBgqwRy). :::hint{type="info"} By default, the *Controller* expects a signed metadata definition file. To allow an unsigned metadata file, select **Allow Unsigned Metadata**. ::: :::Paragraph{indent="3"} Click the **Download Auth Service Provider Metadata for IDP** link. Retain the downloaded file for later use. ::: :::Paragraph{listStyleType="disc" indent="2"} Select **Enter SAML Auth metada details manually** to manually enter the required IdP SAML settings. Use this option in scenarios where a SAML federation metadata file is not available or incomplete. Then, enter the following details: ::: ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/R0z4b7hmWmnx5TG6KVDUQ_wizusermethodssamlmanual.png" alt="Configuring SAML (Azure AD) IdP settings manually" position="flex-start" size="80" width="913" height="511" initialPath="img/wiz_user_methods_saml_manual.png" githubPath="img/wiz_user_methods_saml_manual.png" showCaption="false" indent="3"} :::Paragraph{indent="2"} Configuring SAML (Custom) IdP settings manually The following minimum settings are required for your SAML authentication service to function correctly. Each setting relates to a value configured in the SAML application on your IdP. Contact your IdP administrator to obtain the relevant details: ::: :::Paragraph{listStyleType="disc" indent="3"} **IDP Entity ID**: The entity ID is sent as the Issuer value in the SAML assertion generated by the IdP. Specify the Issuer value in assertions generated by the SAML identity provider. ::: :::Paragraph{listStyleType="disc" indent="3"} **IDP SSO URL**: A URL provisioned by the SAML IdP to support service-provider-initiated Single Sign-On. Use the format `https://`. ::: :::Paragraph{listStyleType="disc" indent="3"} **IDP SLO Service**: (Optional) A URL to specify the Single Log-Out/sign out endpoint if you want to force re-authentication for increased security. Use the format `https://`. For more information, see [Using SAML Single Logout to Force User Authentication](docId\:NJOnS_n7fVj7YPwBgqwRy). ::: :::Paragraph{listStyleType="disc" indent="3"} **User Name Template**: Specify how the system is to derive the username from the SAML assertion. The default value can be used, or replaced with an alternative specifier that the *Controller* uses from the incoming assertion. For example: ``, the NameID value where *ICS* is the IdP, the UID from X509SubjectName, ``, attr from AttributeStatement attributes. ::: :::Paragraph{listStyleType="disc" indent="3"} **IDP Signing Certificate**: The signing certificate to be used with the SAML app on the IdP. Type or paste in the contents of your Base-64 encoded public key. ::: :::hint{type="info"} If, at a later date, you need to replace the metadata definition file with a modified version, edit the authentication method through the *User Authentication* page and repeat this step. Either edit the existing metadata file and re-upload, or replace it completely with a new version. In both cases, however, make sure your metadata file is valid before uploading it through this process. ::: 1. If this Auth server is used with User Policy of type “User”, then click **Enable Enrollment**. Enable Enrollment 8. To provide your SAML IdP settings, select one of the following: - Select **Upload SAML Enroll metadata file** if not selected already. This is selected by default. 1. (Optional) Specify a **Single Logout URL**. For more information, see [Using SAML Single Logout to Force User Authentication](docId\:NJOnS_n7fVj7YPwBgqwRy). :::hint{type="info"} By default, the *Controller* expects a signed metadata definition file. To allow an unsigned metadata file, select **Allow Unsigned Metadata**. ::: :::Paragraph{indent="3"} Click the **Download Enroll Service Provider Metadata for IDP** link. ::: :::Paragraph{listStyleType="disc" indent="2"} Select **Enter SAML Enroll metada details manually** to manually enter the required IdP SAML settings. Use this option in scenarios where a SAML federation metadata file is not available or incomplete. Then, enter the following details: ::: :::Paragraph{indent="2"} Configuring SAML (Azure AD) IdP settings manually The following minimum settings are required for your SAML authentication service to function correctly. Each setting relates to a value configured in the SAML application on your IdP. Contact your IdP administrator to obtain the relevant details: ::: :::Paragraph{listStyleType="disc" indent="3"} **IDP Entity ID**: The entity ID is sent as the Issuer value in the SAML assertion generated by the IdP. Specify the Issuer value in assertions generated by the SAML identity provider. ::: :::Paragraph{listStyleType="disc" indent="3"} **IDP SSO URL**: A URL provisioned by the SAML IdP to support service-provider-initiated Single Sign-On. Use the format `https://`. ::: :::Paragraph{listStyleType="disc" indent="3"} **IDP SLO Service**: (Optional) A URL to specify the Single Log-Out/sign out endpoint if you want to force re-authentication for increased security. Use the format `https://`. For more information, see [Using SAML Single Logout to Force User Authentication](docId\:NJOnS_n7fVj7YPwBgqwRy). ::: :::Paragraph{listStyleType="disc" indent="3"} **User Name Template**: Specify how the system is to derive the username from the SAML assertion. The default value can be used, or replaced with an alternative specifier that the *Controller* uses from the incoming assertion. For example: ``, the NameID value where *ICS* is the IdP, the UID from X509SubjectName, ``, attr from AttributeStatement attributes. ::: :::Paragraph{listStyleType="disc" indent="3"} **IDP Signing Certificate**: The signing certificate to be used with the SAML app on the IdP. Type or paste in the contents of your Base-64 encoded public key. ::: :::hint{type="info"} \- When editing an existing SAML Auth server, the 'Enable Enrollment' option can be enabled or disabled if the SAML Auth server is not being used in any ‘User Policy’. If the SAML Auth server is being used in a ‘User Policy’, then Enable Enrollment button will be grayed out. \- If 'Enable Enrollment' is not selected, then while creation of 'User Policy' of type 'User', the server you have created (without Enable Enrollment) will not be listed. \- When Enrollment is disabled, the enrollment SAML configuration will be deleted. To enable enrollment, you have to again provide enroll SAML auth server configuration. ::: 1. Confirm that your settings are correct, then select **Create Authentication Server** to create the authentication method. :::Paragraph{indent="1"} The *Authentication Server* page lists the new Okta authentication method. ::: After you have created your Okta authentication method, create or update your authentication policies with the new authentication method: 1. From the *nZTA* menu, select the **Secure Access** icon, then select **Manage Users > User Policies**. The **User Policies** page appears. This page lists all existing user authentication policies. ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/cSoGaqZPVBr9OTuyk94aq_userpoliciesstart.png" alt="User Authentication Policies" position="flex-start" size="80" width="997" height="607" initialPath="img/user_policies_start.png" githubPath="img/user_policies_start.png" showCaption="false"} User Authentication Policies To learn more about the policies on this page, see [Viewing User Authentication Policies](docId\:NJOnS_n7fVj7YPwBgqwRy). From this page, either create a new custom policy or edit an existing policy. 2. To add a new custom policy, select **Create User Policy**. The **Create Authentication Policy** form appears. ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/97lDbU6p1D5VPiey1vLec_adduserpolicystart.png" alt="Add User Authentication" position="flex-start" size="80" width="901" height="703" initialPath="img/add_user_policy_start.png" githubPath="img/add_user_policy_start.png" showCaption="false"} Add User Authentication :::hint{type="info"} At any point during this process, you can reset the form data by selecting **Reset Fields**. ::: :::hint{type="info"} To learn more about how custom policies are used for user login and enrollment, see [Adding Custom Authentication Policies](docId\:NJOnS_n7fVj7YPwBgqwRy). ::: 3. Enter a **Policy Name**. 4. Enter a **Login URL** using the format *\*/login/\/*. The URL must start with "*\*/login/*" and cannot contain any special characters. \ should be set to a unique value reflecting the endpoint URL you want to define for this authentication policy (appended with a backslash): - In the case of user sign-in policies, this is the URL endpoint (appended to the tenant FQDN) to which new users are invited to connect to enroll or sign-in a device with the *Controller*. Example value: "*\*/login/saleslogin/*". - In the case of user enrollment policies, this endpoint identifies the enrollment URL to which users are redirected if they attempt to connect to the equivalent sign-in policy with an un-enrolled device. In most cases, you do not advertise this endpoint to your users. Example value: "*\*/login/salesenroll/*". :::hint{type="info"} In some enrollment circumstances, such as when using a device pre-installed with an older version of *Ivanti Secure Access Client*, you connect directly to the enrollment policy endpoint to enroll the device. For more details, see [Using User Authentication Policies](docId\:NJOnS_n7fVj7YPwBgqwRy). ::: 1. (Optional) Enter a description for the authentication policy. 2. Select a **User Type** based on the intended authentication activity for this policy. Choose from: - **Users**: Select this option to define the user sign-in endpoint for enrolled devices. This is the endpoint that you provide to your users to access the service (regardless of enrollment status). - **Administrators**: Select this option to define the authentication endpoint for administrator-level sign-in. This endpoint is used for administrator login to the *Controller* only. 3. (for policies with a **User Type** of "Users" only): Select an **Enroll Device Policy** from the drop-down list to be linked to this sign-in policy (as indicated): ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/8YZR7bxf-cDgYHmD86P30_authpolicyusertype.png" alt="Linking an enrollment policy to a user sign-in policy" position="flex-start" size="80" width="805" height="400" initialPath="img/auth_policy_user_type.png" githubPath="img/auth_policy_user_type.png" showCaption="false"} Linking an enrollment policy to a user sign-in policy This is the enrollment policy to which a user is redirected if it is determined that the device is not yet enrolled. To learn more, see [Using User Authentication Policies](docId\:NJOnS_n7fVj7YPwBgqwRy). 8. Under **Policy Server Details**, select **Primary Auth Server** and choose the required authentication method from the drop-down list: ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/e1o3T_FjCr2Gbadx6rxyb_authpolicyauthserver.png" position="flex-start" size="80" width="976" height="447" initialPath="img/auth_policy_auth_server.png" githubPath="img/auth_policy_auth_server.png" showCaption="false"} :::Paragraph{indent="1"} Alternatively, select *Add New Server* and create a new authentication method as per the steps described earlier in this section. ::: :::Paragraph{indent="1"} Selecting a primary authentication method for this policy ::: 9. (Optional) Where a secondary method is required for Multi-Factor Authentication, repeat the previous step for **Secondary Auth Server**. :::hint{type="info"} Secondary authentication methods do not apply to *Enrollment User* type policies. The relevant field is hidden in this case. ::: 1. Select **Add** to create the new policy. :::Paragraph{indent="1"} The new policy is added to the list of authentication policies. ::: If you instead elect to update an existing custom or built-in policy: 1. Select the check box adjacent to the relevant policy, then select **Actions > Edit**. The **Update Authentication Policy** form appears. :::hint{type="info"} For built-in authentication policies, all properties except **Primary Auth Server** are read-only. ::: 1. Set the **Primary Auth Server** to be the new Okta SAML user authentication method: :::hint{type="info"} SAML authentication can be used only as a Primary Auth Server. If you are using MFA, specify either a *local authentication* or *TOTP* method as the **Secondary Auth Server**. ::: :::hint{type="info"} If you configure a secondary authentication method in a policy that is currently in use, any active user sessions must be disconnected and reconnected for the changes to take effect. ::: 1. Select **Update User Policy**. :::Paragraph{indent="1"} The list of authentication policies updates. ::: Complete these steps for each of your user enrollment and user sign-in policies in turn. ## Workflow: Creating a SAML Authentication Policy for Ping Identity *nZTA* supports the use of Ping Identity (PingID) as a SAML service to provide authentication for your users. If you choose to use PingID as a SAML Identity Provider (IdP), you do not create any users locally on the *Controller*. All users will already be present in your remote SAML service. The process to configure PingID as a custom SAML authentication method within *nZTA* involves the following steps: 1. Create your PingID application and obtain the SAML IdP metadata, see [Creating a PingID SAML Application](docId\:NJOnS_n7fVj7YPwBgqwRy). 2. Define a PingID SAML authentication method in *nZTA* and associate it with your authentication policies, see [Defining and Applying PingID Authentication in nZTA](docId\:NJOnS_n7fVj7YPwBgqwRy). 3. Obtain the *nZTA* Service Provider (SP) metadata and upload it back to the PingID application, see [Updating Your PingID SAML Application with Your SP Metadata](docId\:NJOnS_n7fVj7YPwBgqwRy). Configuring *nZTA* to use PingID SAML authentication requires configuration of two separate authentication policies on the *Controller*, *user enrollment* and *user sign-in*. The *Controller* includes built-in default authentication policies for each of these purposes, and also includes the ability to create your own custom policies should you require this authentication mechanism to apply only to a sub-set of your users. Therefore, complete the above steps for each of these policies in turn. Begin with enrollment, and then repeat the process for user sign-in. To ensure that your users can access the authentication mechanism defined in the policies you configure through this process, make sure your *Secure Access Policies* are configured with a **User Group** in which these authentication policies are defined. To learn more, see [Creating/Editing Secure Access Policies](docId\:ndGVDPLKGsRFI6krD7rok). ### Creating a PingID SAML Application :::hint{type="info" indent="1"} \- To fully configure PingID as a SAML authenticator in *nZTA*, complete these steps for each of your user enrollment and user sign-in policies in turn. \- For the latest configuration details, see PingIdentity Documentation. ::: To create a new PingID application and obtain the SAML IdP Metadata file: 1. Log in to the *PingOne* web portal ([https://admin.pingone.com](https://admin.pingone.com)) and navigate to **My Applications**. 2. Select **Add Application > New SAML Application**: ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/bdpVSjotummliTSTwxFvi_pingidaddapp1.png" alt="Adding a PingID application" position="flex-start" size="80" width="1268" height="1065" initialPath="img/pingid_addapp1.png" githubPath="img/pingid_addapp1.png" showCaption="false"} Adding a PingID application 3. In the *Application Details* step, enter an **Application Name** and **Application Description** for the new application: ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/Zy8IcypT9s74G2gV2CZMM_pingidaddapp2.png" alt="Entering a name and description for your new PingID application" position="flex-start" size="80" width="1043" height="1189" initialPath="img/pingid_addapp2.png" githubPath="img/pingid_addapp2.png" showCaption="false"} Entering a name and description for your new PingID application :::hint{type="info"} *Ivanti* advises using a descriptive name that relates to the user authentication policy this application is created for. ::: 4. Select **Continue to Next Step**. 5. In the *Application Configuration* step, locate the **SAML Metadata** field and select the adjacent **Download** link to obtain the SAML metadata file. Save this file to your local workstation: ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/nh-cuw2GHk3RnP02CLbWF_pingidaddapp3.png" alt="Downloading the PingID application IdP metadata file" position="flex-start" size="80" width="1038" height="1184" initialPath="img/pingid_addapp3.png" githubPath="img/pingid_addapp3.png" showCaption="false"} Downloading the PingID application IdP metadata file 6. Keep this browser page open in order to finish creating the application after you have obtained the SP metadata file from *nZTA*. 7. Proceed to define a new authentication method in *nZTA*, see [Defining and Applying PingID Authentication in nZTA](docId\:NJOnS_n7fVj7YPwBgqwRy). ### Defining and Applying PingID Authentication in *nZTA* :::hint{type="info" indent="1"} To fully configure PingID as a SAML authenticator in *nZTA*, complete these steps for each of your user enrollment and user sign-in policies in turn. ::: To define a new authentication method using PingID as the SAML IdP: 1. Log into the *Controller* as a Tenant Admin, see [Logging in as a Tenant Administrator](docId\:qAQLPFWfOt_GYC0QQw64z). The *Network Overview* page appears. 2. From the *nZTA* menu, select the **Secure Access** icon, then select **Manage Users > Authentication Servers**. The *Authentication Servers* page appears. This page lists all existing user authentication methods. 3. To add a new custom SAML authentication method, select **Create Authentication Server**. The **Create Authentication Server** form appears: ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/CrHWDlqAuQYpUChz-Y01k_wizusermethodsstart.png" position="flex-start" size="80" width="895" height="918" initialPath="img/wiz_user_methods_start.png" githubPath="img/wiz_user_methods_start.png" showCaption="false"} Adding a user authentication method :::hint{type="info"} At any point during this process, you can reset the form data by selecting **Reset Fields**. ::: 4. Under **Choose Authentication Name and Type**: - Select the **Authentication Type** of *SAML (Custom)*. - The form expands to show additional settings: ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/Mf6VFdKLofIFReilUb7Me_pingidaddauthmethod.png" alt="Configuring PingID SAML authentication settings" position="flex-start" size="80" width="892" height="733" initialPath="img/pingid_addauthmethod.png" githubPath="img/pingid_addauthmethod.png" showCaption="false"} :::Paragraph{indent="2"} Configuring PingID SAML authentication settings Specify an **Authentication Server Name**. For example: *SAML\_Ping\_Enroll* or *SAML\_Ping\_SignIn*. ::: 2. To provide your SAML IdP settings, select one of the following: - Select **Upload SAML Auth metadata file** to upload a digitally-signed (or unsigned) PingID Identity Provider (IdP) metadata file, as obtained while creating a new PingID SAML application for this activity. That is, for either user enrollment or user sign-in. See [Creating a PingID SAML Application](docId\:NJOnS_n7fVj7YPwBgqwRy). The **Download Auth Service Provider Metadata for IDP** link is enabled. 1. (Optional) Specify a **Single Logout URL**. For more information, see [Using SAML Single Logout to Force User Authentication](docId\:NJOnS_n7fVj7YPwBgqwRy). :::hint{type="info"} By default, the *Controller* expects a signed metadata definition file. To allow an unsigned metadata file, select **Allow Unsigned Metadata**. ::: :::Paragraph{indent="3"} Click the **Download Auth Service Provider Metadata for IDP** link. Retain the downloaded file for later use. ::: :::Paragraph{listStyleType="disc" indent="2"} Select **Enter SAML Auth metada details manually** to manually enter the required IdP SAML settings. Use this option in scenarios where a SAML federation metadata file is not available or incomplete. Then, enter the following details: ::: ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/R0z4b7hmWmnx5TG6KVDUQ_wizusermethodssamlmanual.png" alt="Configuring SAML (Azure AD) IdP settings manually" position="flex-start" size="80" width="913" height="511" initialPath="img/wiz_user_methods_saml_manual.png" githubPath="img/wiz_user_methods_saml_manual.png" showCaption="false" indent="3"} :::Paragraph{indent="2"} Configuring SAML (Custom) IdP settings manually The following minimum settings are required for your SAML authentication service to function correctly. Each setting relates to a value configured in the SAML application on your IdP. Contact your IdP administrator to obtain the relevant details: ::: :::Paragraph{listStyleType="disc" indent="3"} **IDP Entity ID**: The entity ID is sent as the Issuer value in the SAML assertion generated by the IdP. Specify the Issuer value in assertions generated by the SAML identity provider. ::: :::Paragraph{listStyleType="disc" indent="3"} **IDP SSO URL**: A URL provisioned by the SAML IdP to support service-provider-initiated Single Sign-On. Use the format `https://`. ::: :::Paragraph{listStyleType="disc" indent="3"} **IDP SLO Service**: (Optional) A URL to specify the Single Log-Out/sign out endpoint if you want to force re-authentication for increased security. Use the format `https://`. For more information, see [Using SAML Single Logout to Force User Authentication](docId\:NJOnS_n7fVj7YPwBgqwRy). ::: :::Paragraph{listStyleType="disc" indent="3"} **User Name Template**: Specify how the system is to derive the username from the SAML assertion. The default value can be used, or replaced with an alternative specifier that the *Controller* uses from the incoming assertion. For example: ``, the NameID value where *ICS* is the IdP, the UID from X509SubjectName, ``, attr from AttributeStatement attributes. ::: :::Paragraph{listStyleType="disc" indent="3"} **IDP Signing Certificate**: The signing certificate to be used with the SAML app on the IdP. Type or paste in the contents of your Base-64 encoded public key. ::: :::hint{type="info"} If, at a later date, you need to replace the metadata definition file with a modified version, edit the authentication method through the *User Authentication* page and repeat this step. Either edit the existing metadata file and re-upload, or replace it completely with a new version. In both cases, however, make sure your metadata file is valid before uploading it through this process. ::: 1. If this Auth server is used with User Policy of type “User”, then click **Enable Enrollment**. 2. To provide your SAML IdP settings, select one of the following: - Select **Upload SAML Enroll metadata file** if not selected already. This is selected by default. 1. (Optional) Specify a **Single Logout URL**. For more information, see [Using SAML Single Logout to Force User Authentication](docId\:NJOnS_n7fVj7YPwBgqwRy). :::hint{type="info"} By default, the *Controller* expects a signed metadata definition file. To allow an unsigned metadata file, select **Allow Unsigned Metadata**. ::: :::Paragraph{indent="3"} Click the **Download Enroll Service Provider Metadata for IDP** link. ::: :::Paragraph{listStyleType="disc" indent="2"} Select **Enter SAML Enroll metada details manually** to manually enter the required IdP SAML settings. Use this option in scenarios where a SAML federation metadata file is not available or incomplete. The following minimum settings are required for your SAML authentication service to function correctly. Each setting relates to a value configured in the SAML application on your IdP. Contact your IdP administrator to obtain the relevant details: ::: :::Paragraph{listStyleType="disc" indent="3"} **IDP Entity ID**: The entity ID is sent as the Issuer value in the SAML assertion generated by the IdP. Specify the Issuer value in assertions generated by the SAML identity provider. ::: :::Paragraph{listStyleType="disc" indent="3"} **IDP SSO URL**: A URL provisioned by the SAML IdP to support service-provider-initiated Single Sign-On. Use the format `https://`. ::: :::Paragraph{listStyleType="disc" indent="3"} **IDP SLO Service**: (Optional) A URL to specify the Single Log-Out/sign out endpoint if you want to force re-authentication for increased security. Use the format `https://`. For more information, see [Using SAML Single Logout to Force User Authentication](docId\:NJOnS_n7fVj7YPwBgqwRy). ::: :::Paragraph{listStyleType="disc" indent="3"} **User Name Template**: Specify how the system is to derive the username from the SAML assertion. The default value can be used, or replaced with an alternative specifier that the *Controller* uses from the incoming assertion. For example: ``, the NameID value where *ICS* is the IdP, the UID from X509SubjectName, ``, attr from AttributeStatement attributes. ::: :::Paragraph{listStyleType="disc" indent="3"} **IDP Signing Certificate**: The signing certificate to be used with the SAML app on the IdP. Type or paste in the contents of your Base-64 encoded public key. ::: :::hint{type="info"} \- When editing an existing SAML Auth server, the 'Enable Enrollment' option can be enabled or disabled if the SAML Auth server is not being used in any ‘User Policy’. If the SAML Auth server is being used in a ‘User Policy’, then Enable Enrollment button will be grayed out. \- If 'Enable Enrollment' is not selected, then while creation of 'User Policy' of type 'User', the server you have created (without Enable Enrollment) will not be listed. \- When Enrollment is disabled, the enrollment SAML configuration will be deleted. To enable enrollment, you have to again provide enroll SAML auth server configuration. ::: 1. Confirm that your settings are correct, then select **Create Authentication Server** to create the authentication method. :::Paragraph{indent="1"} The *Authentication Server* page lists the new PingID authentication method. ::: After you have created your PingID authentication method, create or update your authentication policies with the new authentication method: 1. From the *nZTA* menu, select the **Secure Access** icon, then select **Manage Users > User Policies**. The **User Policies** page appears. This page lists all existing user authentication policies. ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/cSoGaqZPVBr9OTuyk94aq_userpoliciesstart.png" position="flex-start" size="80" width="997" height="607" initialPath="img/user_policies_start.png" githubPath="img/user_policies_start.png" showCaption="false"} To learn more about the policies on this page, see [Viewing User Authentication Policies](docId\:NJOnS_n7fVj7YPwBgqwRy). From this page, either create a new custom policy or edit an existing policy. :::Paragraph{indent="1"} User Authentication Policies ::: 2. To add a new custom policy, select **Create User Policy**. The **Create Authentication Policy** form appears. ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/97lDbU6p1D5VPiey1vLec_adduserpolicystart.png" position="flex-start" size="80" width="901" height="703" initialPath="img/add_user_policy_start.png" githubPath="img/add_user_policy_start.png" showCaption="false"} Create User Authentication :::hint{type="info"} At any point during this process, you can reset the form data by selecting **Reset Fields**. ::: :::hint{type="info" indent="1"} To learn more about how custom policies are used for user login and enrollment, see [Adding Custom Authentication Policies](docId\:NJOnS_n7fVj7YPwBgqwRy). ::: 3. Enter a **Policy Name**. 4. Enter a **Login URL** using the format *\*/login/\/*. The URL must start with "*\*/login/*" and cannot contain any special characters. \ should be set to a unique value reflecting the endpoint URL you want to define for this authentication policy (appended with a backslash): - In the case of user sign-in policies, this is the URL endpoint (appended to the tenant FQDN) to which new users are invited to connect to enroll or sign-in a device with the *Controller*. Example value: "*\*/login/saleslogin/*". - In the case of user enrollment policies, this endpoint identifies the enrollment URL to which users are redirected if they attempt to connect to the equivalent sign-in policy with an un-enrolled device. In most cases, you do not advertise this endpoint to your users. Example value: "*\*/login/salesenroll/*". :::hint{type="info" indent="1"} In some enrollment circumstances, such as when using a device pre-installed with an older version of *Ivanti Secure Access Client*, you connect directly to the enrollment policy endpoint to enroll the device. For more details, see [Using User Authentication Policies](docId\:NJOnS_n7fVj7YPwBgqwRy). ::: 5. (Optional) Enter a description for the authentication policy. 6. Select a **User Type** based on the intended authentication activity for this policy. Choose from: - **Users**: Select this option to define the user sign-in endpoint for enrolled devices. This is the endpoint that you provide to your users to access the service (regardless of enrollment status). - **Administrators**: Select this option to define the authentication endpoint for administrator-level sign-in. This endpoint is used for administrator login to the *Controller* only. 7. (for policies with a **User Type** of "Users" only): Select an **Enroll Device Policy** from the drop-down list to be linked to this sign-in policy (as indicated): ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/8YZR7bxf-cDgYHmD86P30_authpolicyusertype.png" position="flex-start" size="80" width="805" height="400" initialPath="img/auth_policy_user_type.png" githubPath="img/auth_policy_user_type.png" showCaption="false"} :::Paragraph{indent="1"} This is the enrollment policy to which a user is redirected if it is determined that the device is not yet enrolled. To learn more, see [Using User Authentication Policies](docId\:NJOnS_n7fVj7YPwBgqwRy). ::: :::Paragraph{indent="1"} Linking an enrollment policy to a user sign-in policy ::: 8. Under **Policy Server Details**, select **Primary Auth Server** and choose the required authentication method from the drop-down list: ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/e1o3T_FjCr2Gbadx6rxyb_authpolicyauthserver.png" position="flex-start" size="80" width="976" height="447" initialPath="img/auth_policy_auth_server.png" githubPath="img/auth_policy_auth_server.png" showCaption="false"} :::Paragraph{indent="1"} Alternatively, select *Create Authentication Server* and create a new authentication method as per the steps described earlier in this section. ::: :::Paragraph{indent="1"} Selecting a primary authentication method for this policy ::: 9. (Optional) Where a secondary method is required for Multi-Factor Authentication, repeat the previous step for **Secondary Auth Server**. :::hint{type="info" indent="1"} Secondary authentication methods do not apply to *Enrollment User* type policies. The relevant field is hidden in this case. ::: 10. Select **Create User Policy** to create the new policy. :::Paragraph{indent="1"} The new policy is added to the list of authentication policies. ::: If you instead elect to update an existing custom or built-in policy: 1. Select the check box adjacent to the relevant policy, then select **Actions > Edit**. :::Paragraph{indent="1"} The **Update Authentication Policy** form appears. ::: :::hint{type="info" indent="1"} For built-in authentication policies, all properties except **Primary Auth Server** are read-only. ::: 2. Set the **Primary Auth Server** to be the new PingID SAML user authentication method: ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/WdkayFlnlTGclk4Dq51SU_editauthpolicyserverdetails.png" position="flex-start" size="80" width="889" height="628" initialPath="img/edit_auth_policy_server_details.png" githubPath="img/edit_auth_policy_server_details.png" showCaption="false"} Editing an authentication policy :::hint{type="info"} SAML authentication can be used only as a Primary Auth Server. If you are using MFA, specify either a *local authentication* or *TOTP* method as the **Secondary Auth Server**. ::: :::hint{type="info" indent="1"} If you configure a secondary authentication method in a policy that is currently in use, any active user sessions must be disconnected and reconnected for the changes to take effect. ::: 3. Select **Update User Policy**. :::Paragraph{indent="1"} The list of authentication policies updates. ::: On the **Authentication Policies** page, select the authentication policy you just created (or updated), then select the corresponding **Download** link. Save the resulting SP metadata file to your local workstation. After you have completed this process for both enrollment and sign-in activities, you can proceed to finish configuring your PingID application using the SP metadata file downloaded during this workflow. See [Updating Your PingID SAML Application with Your SP Metadata](docId\:NJOnS_n7fVj7YPwBgqwRy). ### Updating Your PingID SAML Application with Your SP Metadata :::hint{type="info" indent="1"} To fully configure PingID as a SAML authenticator in *nZTA*, complete these steps for each of your user enrollment and user sign-in policies in turn. ::: After you have obtained the SP Metadata file from your *nZTA* Authentication Policy, update the PingID SAML application created in [Creating a PingID SAML Application](docId\:NJOnS_n7fVj7YPwBgqwRy). Make sure you use the application that corresponds to the policy. In other words, if you have obtained metadata for the enrollment policy, update the PingID enrollment application. To update the PingID application: 1. Return to the PingID application previously started through the PingOne portal ([https://admin.pingone.com](https://admin.pingone.com)): ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/lxsbXO9Et1OXYcJxKoqOY_pingidaddapp4.png" alt="Continuing the PingID application creation process" position="flex-start" size="80" width="1175" height="1051" initialPath="img/pingid_addapp4.png" githubPath="img/pingid_addapp4.png" showCaption="false"} Continuing the PingID application creation process 2. Locate the **Upload Metadata** field and select **Select File**. Upload your SP metadata file. 3. Make any further changes you require to the application configuration, then select **Next**. The **Group Access** section appears. ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/zv_CuS2909TNnxp9FOr41_pingidaddapp5.png" alt="Adding groups to your PingID application" position="flex-start" size="80" width="1140" height="995" initialPath="img/pingid_addapp5.png" githubPath="img/pingid_addapp5.png" showCaption="false"} Adding groups to your PingID application 4. Add to your application any required user groups. :::hint{type="info"} The user groups you require depend on your organization and might vary from those shown in this workflow. At least one user group is required. ::: 1. To review your application configuration, select **Continue to next step**. The **Review Setup** stage appears. ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/_1k04Sw2nv0-5dL8oGqur_pingidaddapp6.png" alt="Reviewing your application configuration" position="flex-start" size="80" width="1075" height="1199" initialPath="img/pingid_addapp6.png" githubPath="img/pingid_addapp6.png" showCaption="false"} Reviewing your application configuration 6. To complete configuration of your PingID application, select **Finish**. ## Workflow: Adding TOTP to an Authentication Policy :::hint{type="info" indent="1"} This feature is supported for client and gateway versions applicable to release 22.2R1 and later only. ::: *nZTA* supports the use of Time-based One Time Password (TOTP) as a secondary authentication method in *Multi-Factor Authentication* deployments. To use TOTP, first create a TOTP authentication method in *nZTA* and then associate it with your user sign-in authentication policies. To ensure that your users can access the authentication mechanism defined in the policies you configure through this process, make sure your *Secure Access Policies* are configured with a **User Group** in which these authentication policies are defined. To learn more, see [Creating/Editing Secure Access Policies](docId\:ndGVDPLKGsRFI6krD7rok). To configure a new TOTP authentication method: 1. Log into the *Controller* as a Tenant Admin, see [Logging in as a Tenant Administrator](docId\:qAQLPFWfOt_GYC0QQw64z). 2. From the *nZTA* menu, select the **Secure Access** icon, then select **Manage Users > Authentication Servers**. The **Authentication Servers** page appears. This page lists all existing user authentication methods. For example: ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/JG5DXNUi5d4ABiF1lk_sb_usermethodsstart.png" alt="User Authentication Methods" position="flex-start" size="80" width="1045" height="625" initialPath="img/user_methods_start.png" githubPath="img/user_methods_start.png" showCaption="false"} User Authentication Methods 3. Select **Create Authentication Server**. A form appears that enables you to define the authentication method. ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/CrHWDlqAuQYpUChz-Y01k_wizusermethodsstart.png" alt="Creating a new TOTP user authentication method" position="flex-start" size="80" width="895" height="918" initialPath="img/wiz_user_methods_start.png" githubPath="img/wiz_user_methods_start.png" showCaption="false"} Creating a new TOTP user authentication method :::hint{type="info"} At any point during this process, you can reset the form data by selecting **Reset Fields**. ::: 4. Under **Choose name and type**: - Specify an **Authentication Server Name**. - Select the **Authorization Type** of *TOTP*. The form expands to show additional TOTP authentication settings: ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/EuOvnYjW1OaFWDf4quQe8_wizusermethodstotp.png" alt="Adding TOTP authentication settings" position="flex-start" size="80" width="1176" height="927" initialPath="img/wiz_user_methods_totp.png" githubPath="img/wiz_user_methods_totp.png" showCaption="false"} Adding TOTP authentication settings 5. Enter the following settings: - **No of Attempts**: The maximum number of consecutive wrong attempts allowed before the account is locked (minimum: 1 attempt, maximum: 5 attempts). To view user attempts and to unlock locked accounts, see [Unlocking Locked User Accounts](docId\:NJOnS_n7fVj7YPwBgqwRy). - **Custom message for registration page**: A custom message to be shown on the new TOTP-user registration web page. - **Allow Auto Unlock**: When selected, a locked account is automatically unlocked after the specified period. (minimum: 10 minutes, maximum: 90 days). - **Display QR code during User Registration**: When selected, a QR code is displayed during user registration. - **Disable Generation of Backup Codes**: When selected, the *Controller* does not generate TOTP backup codes. 6. To create an authentication method based on these settings, select **Add**. :::Paragraph{indent="1"} The new TOTP user authentication method is added to the list of methods and the process is complete. ::: After you have created your TOTP authentication method, create or update your user sign-in authentication policies with the new method. *nZTA* supports using TOTP *only as secondary authentication*, so make sure you have previously configured a primary authentication method before continuing this process. To view workflows for all available authentication types, see [Introduction](docId\:NJOnS_n7fVj7YPwBgqwRy). :::hint{type="info" indent="1"} Secondary authentication methods do not apply to *Enrollment User* type policies. The relevant field is hidden in this case. ::: Complete the following steps for your user sign-in authentication policy: 1. From the *nZTA* menu, select the **Secure Access** icon, then select **Manage Users > User Policies**. The **User Policies** page appears. This page lists all existing user authentication policies. ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/cSoGaqZPVBr9OTuyk94aq_userpoliciesstart.png" alt="User Authentication Policies" position="flex-start" size="80" width="997" height="607" initialPath="img/user_policies_start.png" githubPath="img/user_policies_start.png" showCaption="false"} User Authentication Policies To learn more about the policies on this page, see [Viewing User Authentication Policies](docId\:NJOnS_n7fVj7YPwBgqwRy). 2. Select the check box adjacent to your desired user sign-in policy, then select **Actions > Edit**. The **Edit Authentication Policy** form appears. ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/TD7JjqwXLJFJFt7I1hPb1_editauthpolicytotp.png" alt="Selecting a secondary TOTP authentication method for this policy" position="flex-start" size="80" width="961" height="849" initialPath="img/edit_auth_policy_totp.png" githubPath="img/edit_auth_policy_totp.png" showCaption="false"} Selecting a secondary TOTP authentication method for this policy 3. For **Secondary Auth Server**, select your new TOTP authentication method from the drop-down list (as indicated). Alternatively, select *Add New Server* and create a new authentication method as per the steps described earlier in this section. 4. Select **Save** to update the policy. :::hint{type="info" indent="1"} If you configure a secondary authentication method in a policy that is currently in use, any active user sessions must be disconnected and reconnected for the changes to take effect. ::: ## Unlocking Locked User Accounts After you have created a TOTP authentication method and assigned it to an active user authentication policy, you can use the authentication method configuration page to view users that have attempted authentication through TOTP. This information enables you to unlock locked user accounts, if required. To access user attempt information, perform the following steps: 1. Select **Secure Access > Manage Users > Authentication Servers**. 2. Select the check box adjacent to your TOTP authentication method, then select **Actions > Edit**. At the bottom of the page, a Users table is presented: ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/XRqsxjdXn7wOUhhwHmFFq_totpmethodusers.png" alt="Viewing the list of users who attempted TOTP authentication through this method" position="flex-start" size="80" width="1138" height="205" initialPath="img/totp_method_users.png" githubPath="img/totp_method_users.png" showCaption="false"} Viewing the list of users who attempted TOTP authentication through this method This table lists each user who has attempted to authenticate a device through TOTP, including the last attempt and last successful login times. 3. (Optional) If a user account is locked through too many consecutive failed authentication attempts (that exceed the value configured in **No of Attempts**), unlock the account by selecting the checkbox adjacent to the user entry and selecting **UNLOCK**. The user is then free to re-attempt authentication using valid authentication codes. 4. (Optional) To remove a user from the list, select the checkbox adjacent to the user entry and select **RESET**. This means a user must then re-register their device with the TOTP policy. :::hint{type="info"} Reset and unlock operations of individual users are supported only when the TOTP authentication method is associated with a user authentication policy. To reset or unlock all users in a disassociated TOTP authentication method, delete the TOTP authentication method itself. :::