After you have logged into the Controller for the first time
(see Logging in as a Tenant Administrator), 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.
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.
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.
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:
User Authentication Methods
From this page, you can:
Add a new authentication method by selecting Create
Authentication Server.
Edit an existing authentication method by clicking the adjacent
three dots, then selecting Edit. Make any required
updates and save the changes.
Delete an unused authentication method by clicking the adjacent
three dots, then selecting 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.
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).
To learn more about how user authentication policies are used in a
nZTA service, see Defining User Authentication.
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 clicking the adjacent
three dots, then selecting Edit. Make any required
updates and save the changes.
Delete an unused authentication policy by clicking the adjacent
three dots, then selecting 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.
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). 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.
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.
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:
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.
Click Create User Rule.
The Create User Rule form appears.
Create User Rule
At any point during this process, you can reset the form data by
clicking Reset Fields.
Enter a Rule Name.
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.
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.
SAML (Azure AD): Matches user names or groups in a SAML
authentication method. When you select this option, you must then:
Select a SAML Attribute Type, either
Username or Group.
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.
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.
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:
For simple user attribute key-value matching, use the syntax
userAttr.<attr-key> [=|!=] <attr-value>. For
example:
To match against attributes that can have multiple values
associated with a single attribute key, use the syntax
samlMultiValAttr.<attr-key> [=|!=] (<list>).
For example:
Use brackets and AND/OR operators to construct logical compound
expressions:
- 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")
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.
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.
Repeat steps 3-6 for each required user rule.
(Optional) Edit an existing user rule by clicking the adjacent
three dots, and then selecting Edit. Make any required
updates and save the changes.
(Optional) Delete an unused user rule by clicking the adjacent
three dots, and then selecting Delete. You must confirm
the deletion.
After you have created all required user rules, you can create user
groups, see Creating User Groups.
Creating User Groups
After you have created user rules (see Creating User Rules), you associate one or more user
rules with an authentication policy to form a user group.
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:
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.
Click Create User Group.
A form appears to enable you to create the user group.
Create User Groups
Enter a User Group Name and an optional
Description, then click Next.
Select each of the listed User Rules that are
required in the user group, then click Next.
User rules should be different for enrollment and user sign-in groups
Select required authentication policy from the list, then click
Next.
Review the summary and click Create.
The new user group appears in the User Groups
list.
Repeat steps 2-7 to create all required user groups.
(Optional) To edit a listed user group, click the adjacent three
dots, then select Edit and make any required
updates.
(Optional) To delete an unused user group, click the
adjacent three dots, then select Delete and confirm the
deletion.
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.
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.
Instead, a more-specific wildcard that only includes admin users is
required in this case to prevent all users having total access
rights.
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 Gateways and Insights (read only).
The .CxOs admin role has access to Insights only (read
only).
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.
From the nZTA menu, select Administration, then select Admin
Roles.
A list of Admin Roles appears. This includes default admin roles and custom admin roles (RBAC). For example:
Admin Roles
Click the three dots adjacent to the role you want to update,
then select Edit Role.
A dialog appears. For example:
Edit Admin Roles
Under Choose group, select the user group that
you want the admin group to be associated with.
Select Save Changes.
(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.
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.
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.
ICS Gateway Permissions
11. Click Select Gateways. In the Select Gateways dialog, select one or more Gateways / Clusters from the list and click Apply.
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 clicking the adjacent three dots, and then selecting Edit. Make any required updates and save the changes.
15. (Optional) Delete an unused custom admin rule by clicking the adjacent three dots, and then selecting Delete. You must confirm the deletion.
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.
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:
User Authentication Methods
Select Create Authentication Server.
A form appears that enables you to define the authentication
method.
Adding a new local user authentication
method
At any point during this process, you can reset the form data by
selecting Reset Fields.
Under Choose name and type:
Specify an Authentication Server Name.
Select the Authorization Type of
Local.
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.
Click Create User. The Create Local
User dialog appears to show additional local authentication
settings:
Adding local users to a new
authentication method
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.
Repeat the previous step for each required user.
Click Create Authentication Server.
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.
Repeat the following steps for each policy, starting with
enrollment:
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.
Enter a Login URL using the format
*/login/<path>/.
The URL must start with "*/login/" and cannot contain any
special characters. <path> 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/".
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.
(Optional) Enter a description for the authentication
policy.
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.
(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):
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.
Under Policy Server Details, select
Primary Auth Server from the drop-down list:
Selecting a primary authentication method
for this policy
(Optional) Where a secondary method is required for Multi-Factor
Authentication, select Secondary Auth
Server from the drop-down list.
Secondary authentication methods do not apply to Enrollment
User type policies. The relevant field is hidden in this case.
Click Create User Policy to create the new
policy.
The new policy is added to the list of authentication policies.
If you instead elect to update an existing custom or built-in
policy:
Click the three dots adjacent to the relevant policy, then select
Edit.
The Edit authentication policy form appears.
For built-in authentication policies, all properties except
Primary Auth Server and Secondary Auth
Server (where applicable) are read-only.
Configure the primary and/or secondary authentication methods, as
required:
Set the Primary Auth Server to be the new local
user authentication method (indicated):
Editing the primary auth
server
If you are configuring a policy for MFA, set the
Secondary Auth Server to be the new local user
authentication method (indicated):
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.
Click Update User Policy.
The list of authentication policies updates.
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.
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:
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.
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
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.
By default, the Controller expects a signed metadata
definition file. To allow an unsigned metadata file, select
Allow Unsigned Metadata.
Click the Download Auth Service Provider Metadata for IDP link. Retain the downloaded file for later use.
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:
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:
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.
IDP SSO URL: A URL provisioned by the SAML IdP to
support service-provider-initiated Single Sign-On. Use the format
https://<FQDN>.
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://<FQDN>. For more information, see Using SAML Single Logout to Force User Authentication.
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:
<assertionNameDN.uid>, the NameID value where
ICS is the IdP, the UID from X509SubjectName,
<userAttr.attr>, attr from AttributeStatement
attributes.
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.
If this Auth server is used with User Policy of type “User”, then click Enable Enrollment.
Enable Enrollment
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.
By default, the Controller expects a signed metadata
definition file. To allow an unsigned metadata file, select
Allow Unsigned Metadata.
Click the Download Enroll Service Provider Metadata for IDP link.
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:
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:
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.
IDP SSO URL: A URL provisioned by the SAML IdP to
support service-provider-initiated Single Sign-On. Use the format
https://<FQDN>.
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://<FQDN>. For more information, see Using SAML Single Logout to Force User Authentication.
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:
<assertionNameDN.uid>, the NameID value where
ICS is the IdP, the UID from X509SubjectName,
<userAttr.attr>, attr from AttributeStatement
attributes.
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.
- 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.
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.
Browse and upload the digitally-signed (or unsigned) federation metadata XML definition files downloaded from Azure AD.
Confirm that your settings are correct, then select Create Authentication Server to create the authentication method.
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, click the
adjacent three dots, then select Edit. Make any
required updates and confirm.
(Optional) To delete one (or more) an unused
authentication methods, select the check box for each, then select
Delete. You must confirm the deletion.
Creating Enrollment/Sign-in SAML App in Azure AD
Perform the following steps in Azure AD:
Create a SAML app for the required activity (sign-in or enrollment).
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.
Setting Basic SAML Configuration
in Azure AD applications
Download the Federation metadata XML definition for the SAML app
to your local workstation. Retain this file for later use.
Downloading Federation Metadata XML files
for user enrollment and user sign-in SAML applications
Repeat these steps for each activity.
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.
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.
Enter a Login URL using the format
*/login/<path>/.
The URL must start with "*/login/" and cannot contain any
special characters. <path> 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/".
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.
(Optional) Enter a description for the authentication
policy.
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.
From the Device Policy list, select a device policy.
(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.
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.
(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.
Click Create User Policy to create the new
policy.
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:
Click the three dots adjacent to the relevant policy, then select
Edit.
The Update Authentication Policy form appears.
For built-in authentication policies, all properties except
Primary Auth Server and Secondary Auth
Server (where applicable) are read-only.
Set the Primary Auth Server to be the new SAML
user authentication method (indicated):
Editing the primary auth
server
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.
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.
Select Update User Policy.
The list of authentication policies updates.
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.
Refresh your browser until the Download action is
visible for the relevant policies.
Select the check box for the policy metadata you want to download
and clear all other check boxes.
Select Download and save the metadata file.
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.
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.
Configuring MFA with Azure AD (Optional)
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.
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:
On Azure AD, locate the Azure AD Conditional Access
page.
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.
Locate the Multi-Factor Authentication page.
On the right-side panel, under Configure:
Select the Additional cloud-based MFA
settings.
A new tab appears.
Enable the following MFA methods as per the requirement.
Call to phone.
Text message to phone.
Select Save.
Configuration of MFA on Azure AD is complete.
Mobile end users will be asked for secondary authentication
information from their next login.
Configuring nZTA to use Azure AD Security Groups (Optional)
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:
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.
Log in to the Azure AD portal
Navigate to your SAML SSO application, and select the
Users page.
Add a new user for your organization by selecting Create
User:
Adding a new user
Enter the following details:
User name: Enter a username for the new user,
appended by the domain applicable to your organization.
Name: Enter the user's full display name.
(Optional) First Name: Enter the user's first
name.
(Optional) Last Name: Enter the user's last
name.
Password: Select either an auto-generated or admin
supplied password.
To create the user, select Create.
Add a new security group for your organization by navigating to
the Groups page and selecting New
Group:
Adding a new security group
Enter the following details:
Group type: Select Security.
Group name: Enter a name for the new security
group.
(Optional) Group description: Enter a description
for the group.
(Optional) Azure AD roles can be assigned to the
group: Use the default setting.
Membership type: Select Assigned.
To create the group, select Create.
In the list of groups, make a note of the Object
ID for the newly created group:
Viewing the Object ID
for the new group
You use the Object ID property when configuring your
nZTAUser Rules.
Assign the new user to your new security group:
Assigning the new user to your new security group
To create Azure AD applications that facilitate retrieval of Security
Group information:
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.
Assign your applications to the required users or security
groups:
Assigning applications to users and
security groups
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.
Create corresponding authentication policies and assign each
Azure AD authentication method as the Primary Auth
Server.
For each Azure AD application, in the User Attributes and
Claims section, select Edit.
Editing the user attributes and claims
for an Azure AD application
Add a new group claim to your application by selecting
Add a group claim:
Adding a new group claim to your Azure AD
application
In the Group Claims panel, enter the following details:
Which groups associated with the user should be returned
in the claim?: Select "Security groups".
Source attribute:
To retrieve Azure AD security group details based on the group
object ID, select "Group ID".
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.
By default, Azure AD populates SAML attributes for group claims in
the format:
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.
To add the new group claim, select Save.
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:
Specifying an Object ID as the group
attribute value
If you synchronized your security group to Azure AD from a local
Active Directory, use the Group Name.
Specifying an Object Name as the group
attribute value
The following expressions are examples of Azure AD group attribute
values:
Users that are members of only the identified group:
Users that are members of only the identified group:
userAttr.<Customized Group Claim Name> = "<Group Object ID>"
Users that are members of only the named group (for AD groups
synchronized from a local Active Directory):
userAttr.<Customized Group Claim Name> = "<Group Name>"
To add SAML multi-valued attributes
(samlMultiValAttr.<claim>) in Azure AD User Rules,
you must set Select Attribute Type to "SAML (Custom)".
This applies to the following examples:
Users that are members of either identified group:
samlMultiValAttr.{http://schemas\.microsoft\.com/ws/2008/06/identity/claims/groups} = ("<Group OID A>" or "<Group OID B>")
Users that are members of both identified groups:
samlMultiValAttr.{http://schemas\.microsoft\.com/ws/2008/06/identity/claims/groups} = ("<Group OID A>" and "<Group OID B>")
Users that are members of either named group (for AD groups
synchronized from a local Active Directory):
samlMultiValAttr.{http://schemas\.microsoft\.com/ws/2008/06/identity/claims/groups} = ("<Group A>" or "<Group B>")
Users that are members of both named groups (for AD groups
synchronized from a local Active Directory):
samlMultiValAttr.{http://schemas\.microsoft\.com/ws/2008/06/identity/claims/groups} = ("<Group A>" and "<Group B>")
Users that are members of either named group (for AD groups
synchronized from a local Active Directory):
samlMultiValAttr.<Customized Group Claim Name> = ("<Group A>" or "<Group B>")
Users that are members of both named groups (for AD groups
synchronized from a local Active Directory):
samlMultiValAttr.<Customized Group Claim Name> = ("<Group A>" and "<Group B>")
To create the User Rule, select Create.
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:
Configuring a User Rule Group with a User
Authentication Policy and User Rule
To create the User Rule Group, select
Create.
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.
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:
Configure your on-premises ICS to act as a SAML AD
authentication server:
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.
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.
Configuring Secondary Authentication for On-Premises ICS (Optional)
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.
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:
Log in to the on-premises Ivanti Connect Secure
server.
On the Authentication menu, select Auth.
Servers.
The Authentication Servers page appears.
Under New, select the required authentication
server type. For example, select Time based One Time Password (TOTP)
Server.
Select New Server.
The New Time based One Time Password (TOTP) Server
page appears.
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.
Select Save Changes.
The new server (Google OTP) is added to the list of
Authentication Servers.
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.
Select the Users menu, then select User
Realms.
The User Authentication Realms page
appears.
You must now enable secondary authentication. To do this:
In the User Authentication Realms list, select
the hyperlink for the Users entry.
The General page for the Users realm
appears.
Under Additional authentication server, select
the Enable additional authentication server check
box.
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:
Log in to the on-premises Ivanti Connect Secure server
that is identified as an Identity Provider.
Navigate to System > Configuration > SAML >
Settings.
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:
If the ICS is standalone, the FQDN should resolve to the IP
address of the external interface / internal interface, whichever is
chosen.
If the ICS is an Active-Passive cluster, the FQDN should
resolve to the external VIP / Internal VIP, whichever is chosen.
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.
Select Save Changes.
Select Update Entity IDs and confirm this action
on the warning page by selecting Update Entity
IDs.
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.
Navigate to Authentication > Signing In > Sign In
SAML > Identity Provider.
Locate the the Basic Identity Provider (IdP)
Configuration section.
Under Protocol Binding to use for SAML
Response:
Select the Post check box.
Clear the Artifact check box.
Select the required Signing Certificate.
Under Other Configurations:
Select the Accept unsigned AuthnRequest check
box.
Select sha-256 for Signature Algorithm, if ICS is using 22.x version onwards.
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:
Log in to Ivanti Connect Secure server.
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.
Set Metadata Validity to 365 days.
Clear the Do Not Publish IdP in Metadata check
box.
Select Save Metadata Provider.
Select Download Metadata and save the file to
your computer.
This definition file is required to enable on-premises SAML apps on
the Controller.
By default, the Controller expects a signed metadata
definition file. To allow an unsigned metadata file, select
Allow Unsigned Metadata.
Click the Download Auth Service Provider Metadata for IDP link. Retain the downloaded file for later use.
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:
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:
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.
IDP SSO URL: A URL provisioned by the SAML IdP to
support service-provider-initiated Single Sign-On. Use the format
https://<FQDN>.
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://<FQDN>. For more information, see Using SAML Single Logout to Force User Authentication.
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:
<assertionNameDN.uid>, the NameID value where
ICS is the IdP, the UID from X509SubjectName,
<userAttr.attr>, attr from AttributeStatement
attributes.
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.
- 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.
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.
(Optional) To edit a listed authentication method, click the
adjacent three dots, then select Edit. Make any
required updates and confirm.
(Optional) To delete one (or more) an unused
authentication methods, select the check box for each, then select
Delete. You must confirm the deletion.
Enter a Login URL using the format
*/login/<path>/.
The URL must start with "*/login/" and cannot contain any
special characters. <path> 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/".
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.
(Optional) Enter a description for the authentication
policy.
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.
(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):
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.
Under Policy Server Details, select
Primary Auth Server and choose the required
authentication method from the drop-down list:
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.
(Optional) Where a secondary method is required for Multi-Factor
Authentication, repeat the previous step for Secondary Auth
Server.
Secondary authentication methods do not apply to Enrollment
User type policies. The relevant field is hidden in this case.
Select Add to create the new policy.
The new policy is added to the list of authentication policies.
If you instead elect to update an existing custom or built-in
policy:
Click the three dots adjacent to the relevant policy, then select
Edit.
The Edit authentication policy form appears.
For built-in authentication policies, all properties except
Primary Auth Server and Secondary Auth
Server (where applicable) are read-only.
Set the Primary Auth Server to be the new SAML
user authentication method (indicated):
Editing the primary auth
server
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.
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.
Select Update User Policy.
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:
Refresh your browser until the Download action is
visible for the relevant policy.
Select the check box for the policy and clear all other check
boxes.
Select Download and save the metadata file.
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.
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.
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.
To configure a SAML app on ICS with XML from the
Controller:
Log into your ICS platform.
Navigate to System > Configuration >
SAML.
Select New Metadata Provider.
Enter a Name for the metadata provider.
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).
Under Metadata Provider Verification
Configuration:
Select the Accept Unsigned Metadata check box.
Under Metadata Provider Filter
Configuration:
For Roles, select the Service Provider check
box.
Select Save Changes.
Navigate to Authentication > Signing In > Sign-In
SAML > Identity Provider.
In the Configuration section, select Add
SP.
The New Peer Service Provider page appears.
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".
In the Customize IdP Behavior section, select
the Override Default Configuration check box.
Clear the Reuse Existing NC (Pulse) Session
check box.
Select the Accept unsigned AuthnRequest check
box.
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.
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:
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.
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://<tenant FQDN>/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://<tenant MTLS FQDN>/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://<tenant FQDN>/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://<tenant MTLS FQDN>/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
- 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:
Log in to your Okta account and select Classic UI
mode.
In the Admin Console, navigate to Applications >
Applications.
Select Add Application.
Start the Application Integration Wizard by selecting
Create New App.
For Platform, select "Web".
For Sign-on method, select "SAML 2.0".
Select Create.
In the General Settings tab, enter an application
name.
Ivanti advises using a descriptive name that relates to the
user authentication policy this application is created for.
(Optional) Upload a logo for the application.
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:
Using Okta Group Attribute Statements to Categorize Users
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:
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:
userAttr.ZTAGroups = "ZTAGroup1"
Users that are members of either named group:
userAttr.ZTAGroups = ("ZTAGroup1" or "ZTAGroup2")
Users that are members of either named group, or both groups:
samlMultiValAttr.ZTAGroups = ("ZTAGroup1" or "ZTAGroup2")
Users that are only members of both named groups:
samlMultiValAttr.ZTAGroups = ("ZTAGroup1" and "ZTAGroup2")
Users that are members of "ZTAGroup1", but not members of
"ZTAGroup2":
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":
samlMultiValAttr.ZTAGroups = ("ZTAGroup1" or "ZTAGroup2") and
samlMultiValAttr.ZTAGroups = "ZTAGroup3"
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.
The Download Auth Service Provider Metadata for IDP link is enabled.
By default, the Controller expects a signed metadata
definition file. To allow an unsigned metadata file, select
Allow Unsigned Metadata.
Click the Download Auth Service Provider Metadata for IDP link. Retain the downloaded file for later use.
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:
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:
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.
IDP SSO URL: A URL provisioned by the SAML IdP to
support service-provider-initiated Single Sign-On. Use the format
https://<FQDN>.
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://<FQDN>. For more information, see Using SAML Single Logout to Force User Authentication.
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:
<assertionNameDN.uid>, the NameID value where
ICS is the IdP, the UID from X509SubjectName,
<userAttr.attr>, attr from AttributeStatement
attributes.
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.
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.
If this Auth server is used with User Policy of type “User”, then click Enable Enrollment.
Enable Enrollment
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.
By default, the Controller expects a signed metadata
definition file. To allow an unsigned metadata file, select
Allow Unsigned Metadata.
Click the Download Enroll Service Provider Metadata for IDP link.
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:
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:
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.
IDP SSO URL: A URL provisioned by the SAML IdP to
support service-provider-initiated Single Sign-On. Use the format
https://<FQDN>.
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://<FQDN>. For more information, see Using SAML Single Logout to Force User Authentication.
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:
<assertionNameDN.uid>, the NameID value where
ICS is the IdP, the UID from X509SubjectName,
<userAttr.attr>, attr from AttributeStatement
attributes.
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.
- 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.
Confirm that your settings are correct, then select
Create Authentication Server to create the authentication method.
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:
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.
Enter a Login URL using the format
*/login/<path>/.
The URL must start with "*/login/" and cannot contain any
special characters. <path> 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/".
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.
(Optional) Enter a description for the authentication
policy.
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.
(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):
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.
Under Policy Server Details, select
Primary Auth Server and choose the required
authentication method from the drop-down list:
Selecting a primary authentication method for this policy
Alternatively, select Add New Server and create a new
authentication method as per the steps described earlier in this
section.
(Optional) Where a secondary method is required for Multi-Factor
Authentication, repeat the previous step for Secondary Auth
Server.
Secondary authentication methods do not apply to Enrollment
User type policies. The relevant field is hidden in this case.
Select Add to create the new policy.
The new policy is added to the list of authentication policies.
If you instead elect to update an existing custom or built-in
policy:
Click the three dots adjacent to the relevant policy, then select
Edit.
The Update Authentication Policy form appears.
For built-in authentication policies, all properties except
Primary Auth Server are read-only.
Set the Primary Auth Server to be the new Okta
SAML user authentication method:
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.
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.
Select Update User Policy.
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:
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.
Creating a PingID SAML
Application
- 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:
In the Application Details step, enter an
Application Name and Application
Description for the new application:
Entering a name and description for your
new PingID application
Ivanti advises using a descriptive name that relates to the
user authentication policy this application is created for.
Select Continue to Next Step.
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:
Downloading the PingID application IdP
metadata file
Keep this browser page open in order to finish creating the
application after you have obtained the SP metadata file from
nZTA.
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.
To add a new custom SAML authentication method, select
Create Authentication Server.
The Create Authentication Server form appears:
Adding a user authentication method
At any point during this process, you can reset the form data by
selecting Reset Fields.
Under Choose Authentication Name and Type:
Select the Authentication Type of SAML
(Custom).
The form expands to show additional settings:
Configuring PingID SAML authentication
settings
Specify an Authentication Server Name. For example:
SAML_Ping_Enroll or SAML_Ping_SignIn.
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.
The Download Auth Service Provider Metadata for IDP link is enabled.
By default, the Controller expects a signed metadata
definition file. To allow an unsigned metadata file, select
Allow Unsigned Metadata.
Click the Download Auth Service Provider Metadata for IDP link. Retain the downloaded file for later use.
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:
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:
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.
IDP SSO URL: A URL provisioned by the SAML IdP to
support service-provider-initiated Single Sign-On. Use the format
https://<FQDN>.
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://<FQDN>. For more information, see Using SAML Single Logout to Force User Authentication.
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:
<assertionNameDN.uid>, the NameID value where
ICS is the IdP, the UID from X509SubjectName,
<userAttr.attr>, attr from AttributeStatement
attributes.
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.
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.
If this Auth server is used with User Policy of type “User”, then click Enable Enrollment.
Enable Enrollment
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.
By default, the Controller expects a signed metadata
definition file. To allow an unsigned metadata file, select
Allow Unsigned Metadata.
Click the Download Enroll Service Provider Metadata for IDP link.
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:
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:
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.
IDP SSO URL: A URL provisioned by the SAML IdP to
support service-provider-initiated Single Sign-On. Use the format
https://<FQDN>.
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://<FQDN>. For more information, see Using SAML Single Logout to Force User Authentication.
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:
<assertionNameDN.uid>, the NameID value where
ICS is the IdP, the UID from X509SubjectName,
<userAttr.attr>, attr from AttributeStatement
attributes.
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.
- 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.
Confirm that your settings are correct, then select
Create Authentication Server to create the authentication method.
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:
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.
Enter a Login URL using the format
*/login/<path>/.
The URL must start with "*/login/" and cannot contain any
special characters. <path> 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/".
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.
(Optional) Enter a description for the authentication
policy.
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.
(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):
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.
Under Policy Server Details, select
Primary Auth Server and choose the required
authentication method from the drop-down list:
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.
(Optional) Where a secondary method is required for Multi-Factor
Authentication, repeat the previous step for Secondary Auth
Server.
Secondary authentication methods do not apply to Enrollment
User type policies. The relevant field is hidden in this case.
Select Create User Policy to create the new policy.
The new policy is added to the list of authentication policies.
If you instead elect to update an existing custom or built-in
policy:
Click the three dots adjacent to the relevant policy, then select
Edit.
The Update Authentication Policy form
appears.
For built-in authentication policies, all properties except
Primary Auth Server are read-only.
Set the Primary Auth Server to be the new PingID
SAML user authentication method:
Editing an authentication policy
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.
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.
Select Update User Policy.
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.
Updating
Your PingID SAML Application with Your SP Metadata
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. 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:
Return to the PingID application previously started through the
PingOne portal (https://admin.pingone.com):
Continuing the PingID application
creation process
Locate the Upload Metadata field and select
Select File. Upload your SP metadata file.
Make any further changes you require to the application
configuration, then select Next.
The Group Access section appears.
Adding groups to your PingID
application
Add to your application any required user groups.
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.
To review your application configuration, select Continue
to next step.
The Review Setup stage appears.
Reviewing your application
configuration
To complete configuration of your PingID application, select
Finish.
Workflow: Adding TOTP to an Authentication Policy
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.
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:
User Authentication Methods
Select Create Authentication Server.
A form appears that enables you to define the authentication
method.
Creating a new TOTP user authentication
method
At any point during this process, you can reset the form data by
selecting Reset Fields.
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:
Adding TOTP authentication
settings
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.
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.
To create an authentication method based on these settings,
select Add.
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.
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:
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.
Click the three dots adjacent to your desired user sign-in
policy, then select Edit.
The Edit Authentication Policy form appears.
Selecting a secondary TOTP authentication
method for this policy
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.
Select Save to update the policy.
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:
Click the three dots adjacent to your TOTP authentication method,
then select Edit.
At the bottom of the page, a Users table is presented:
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.
(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.
(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.
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.
