SAML 2.0 Integration

Last updated Oct 3, 2023

Access Anywhere supports integration with many directory services through the SAML and LDAP protocols providing authentication and authorization services including single-sign on, identity and group synchronization, auto-add and permission synchronization.

This document describes integration with SAML 2.0 using a number of popular providers. For LDAP see LDAP Integration and for Active Directory see Active Directory Integration. The Access Anywhere identity and access management features are summarized here.

The following flows are supported:

• Service Provider Initiated Flow
• Identity Provider Initiated Flow (since release 2106.00)

This document describes basic SAML 2.0 setup as well as integration with these identity providers:

• Active Directory Federation Services (AD FS)
• Azure Directory Services
• Google Workspace (formerly G Suite).
• Okta
• Duo Access

If you are looking for how to set up SAML integration with the SMB or Nasuni Connector please refer to this page.

To begin configuring the SAML 2.0 connection, you will need to ensure that SAML is enabled in your Package. To do this login as the ApplAdmin user, visit the User Packages screen, find the package that your organization uses, and ensure that SAML 2 Login System is highlighted in the “Extra options” section

Next, login as the Organization Administrator, visit the Auth Systems screen from the Organization menu.

Under Add Auth System, select SAML from the dropdown beside Auth System.

On this screen, you are now required to enter details about your particular SAML 2.0 identity provider. The following list describes the meaning of each field, including one which will be populated automatically when the authentication system has been added.

• Auth System Name - Each authentication system has a name that is provided for your reference. Enter a name you can use to identify this authentication system later on.
  
  
• Identifier (Entity ID) - Unique ID that identifies your application to the SAML Identity Provider. This value must be unique across all applications in your SAML Identity Provider. The default identifier will be the audience of the SAML response for IDP-initiated SSO. (New in release 2301).
  
  
• Reply URL (Assertion Consumer Service URL) - This field will hold a URL that can be shared with the SAML system so SAML can deliver authentication tokens to the Access Anywhere server. Access Anywhere will generate the URL and fill in the field when the authentication system has been created. The generated value cannot be overwritten.
  
  
• Login button label - Users who are associated with this authentication system will be shown a button on the login page for them to click to perform the login. The text you supply here will be used on the button, for example, you may wish to enter “Login with AcmeCorp AD”
  
  
• The Service provider entity ID - Your identity provider will either ask you to supply an Entity ID or will generate one for you. In either case ensure that the values match between the identity provider and Access Anywhere.
  
  
• SSO entry point - Your identity provider will provide you with a URL that begins the login flow for your users with the Access Anywhere service. This can commonly be referred to as the SSO URL or SSO Login Endpoint. Enter it here.
  
  
• The logout service endpoint - Your identity provider will provide you with the Logout URL, where the Access Anywhere server will send users to when they wish to logout. Enter it here.
  
  
• x509 Certificate - Your identity provider will provide you with a certificate when you configure it for SAML. You should download that certificate and paste its entire contents into this field.
  
  
  

  Additional Options
• Force authentication - When this option is enabled users to whom this authentication system has been assigned will not be allowed to reuse existing sessions and will have to re-authenticate to login.
  
  
• Sign AuthnRequest and LogoutRequest - If this option is enabled then authentication and logout requests will be signed.
  
  
• Fetch user Role\Group Name by id (for Azure AD) - If you are using Azure Active Directory Federation Services, you will need to tick this option. Otherwise, leave it unchecked.
  
  
  

  Users Login Settings
• Auto create user on login - When SAML is being used manual user import is not supported so this option should always be checked.
  
  
• Refresh role/group membership on login - When this option is enabled each user's groups/roles membership will be refreshed each time the user logs in.
  
  
• Auto create new roles/groups on login - When this option is enabled if the server discovers new roles or groups associated with a user it will automatically create corresponding Access Anywhere roles.
  
  
• Update user info on login - When this option is enabled, when a user logs in the server will compare the user's name, email address, and phone number returned by the SAML provider with the corresponding values in Access Anywhere and update the database if differences are discovered.
  
  
  

  SAML Users Import Fields

The Access Anywhere server requires certain pieces of information when mapping an authentication system user to a user. Since the names of the fields used by identity providers to hold these values are not standardized, you will need to supply the mappings.

• Unique User Attribute Field - Enter the name of the identity provider field containing this information.
  
  
• User Login Field - Enter the name of the identity provider field containing this information.
  
  
• User Name Field - Enter the name of the identity provider field containing this information.
  
  
• User Email Field - Enter the name of the identity provider field containing this information.
  
  
• Role\Group Name Field - Enter the name of the identity provider field containing this information.
  
  
• User Phone Field - Enter the name of the identity provider field containing this information.
  
  
  

  SAML Users Import Settings
• NAA Administrator role maps to - Provide the name of a SAML group whose members should automatically be assigned the Administrator role by Access Anywhere.
  
  
• Restrict import of SAML users from the following roles\groups - If this field is left empty then Access Anywhere will import users with all roles and groups. To prevent users with specific roles and groups from being imported, list those roles and groups here, one per line. A user will be excluded if she has at least one of the roles or groups listed here regardless of other roles or groups she may have.

As described here, Access Anywhere implements the SCIM 2.0 protocol, allowing identity providers to automatically provision users. If your SAML system supports SCIM and you wish to make use if it, set and use the details as described in this section.

• Enable SCIM 2.0 Server - This switch turns SCIM integration on and off for the SAML authentication system that is being configured. When it is set to Yes the SCIM configuration details will be visible.
• Tenant URL - This value is pre-set by Access Anywhere. You cannot change it. You will need to include it in your identity provider's SCIM configuration.
• Secret Token - This value needs to be included in your identity provider's SCIM configuration. Access Anywhere will generate a default value, but you can overwrite.

For specific details on configuring different identity providers, follow our guides below.

Once you have completed the configuration you can use the Test Settings button, and complete this by clicking Add Auth System.

From the AD FS management screen, click Add Relying Party Trust… from the sidebar.

This will open a wizard:

Click Start

Click the radio button Enter data about the relying party manually and click Next



Enter an appropriate Display name so that you can recognise it in the future and click Next



Select the AD FS profile radio button and click Next.



Under the Configure Certificate, leave the settings as their default settings and click Next.



On the Configure URL screen, tick the Enable support for the SAML 2.0 WebSSO protocol checkbox.

In the Relying party SAML 2.0 SSO service URL field, you will need to enter your appliances base URL, with “/saml.htm” appended to it. For example, if your appliance is hosted at “https://sme.example.com” you would enter “https://sme.example.com/saml.htm” in this field.



Click Next.

On the Configure Identifiers screen, you will need to enter the base URL for your appliance in the Relying party trust identifier field. For example, we could enter “https://sme.example.com” then click Add



You will then be asked if you wish to Configure Multi-factor Authentication for this relying party trust. You may do so, but it is out of scope for this guide.

Click Next

On the Choose Issuance Authorization Rules screen, select the Permit all users to access this relying party radio button.



Click Next

On the Ready to Add Trust screen, review the settings you have entered.

Click Next

On the final screen, ensure that the Open the Edit Claim Rules dialog for this relying part trust when the wizard closes is ticked, and click Close

From the Issuance Transform Rules screen, click Add Rule…



From the Claim rule template drop down, select Send LDAP Attributes as Claims and click Next.

Enter a friendly name under Claim rule name.

Select Active Directory from the Attribute store

Configure the Mapping of LDAP attributes as per the image below.

Next, add another Claim Rule.

From the Claim rule template select Send Group Membership as a Claim. Provide a Claim rule name.

Select the User's group that this applies to

Select the Outgoing claim type as Group

Input the Outgoing claim value as “groups”



Close the Claim Rules dialog.

Next, visit the Certificates folder under Service



Double click on your certificate under the Token-signing section.

Click on the Details tab and click Copy to File



Click Next when the dialog opens.

Select Base-64 encoded X.509 (.CER) as the export format.

Click Next

Select the location on disk to store the certificate and follow the prompts to complete the export.

Finally, click on the AD FS folder on the left-hand side. From the Action menu, select Edit Federation Service Properties.

Copy the value from the Federation Service identifier field and save this.

Now we will configure the Auth System inside SME. Given the guide at the top of this document, the relevant fields from AD FS are as follows:

Service provider entity ID - This is the value from the Federation Service identifier field

SSO entry point - For AD FS this is typically the base URL of the service appended with “/adfs/ls”, for example “https://ad.example.com/adfs/ls”

Logout service endpoint - For AD FS this is typically the SSO endpoint with the additional query string of “?wa=wsignout1.0”, for example “https://ad.example.com/adfs/ls?wa=wsignout1.0”

Certificate data - Open the exported certificate you obtained from the AD FS system into Notepad, and copy the whole contents into this field.

Ensure the field mappings are as follows:

• Unique user attribute ⇒ username
• User Login Field ⇒ username
• User Name Field ⇒ fullname
• User Email Field ⇒ email
• Role\Group Name Field ⇒ groups
• User Phone Field ⇒ phone
  
  

  Configuring with Azure AD Enterprise Application

As an administrative user, log into the Azure portal: https://portal.azure.com/

Search and enter the page for “Enterprise Applications”, Add a New Application. Click “Create your own application”.

Input a name for the application, for example Nasuni Access Anywhere.

Select Integrate any other application you don't find in the gallery from the list of options.

Now that the application is created, we will enable SAML for single sign-on.

In “Basic SAML Configuration” we will enter the following URLs, which point to your Access Anywhere instance.

Identifier (Entity ID): Server URL - ex: https://files.example.com/

Reply URL (Assertion Consumer Service URL): ex: https://files.example.com/saml.htm

Next we will set up Group Claims.

Under User Attributes & Claims click Edit. Then select Add a group claim.

Select All Groups as which groups should be returned in the claim. Source Attribute should be set to Group ID.

Please Note: Due to an internal limit within Azure AD, if a user is a member of more than 150 groups, the SAML assertion does not return any groups. Rather a link to Microsoft's Graph API is returned instead. Currently this would result in the user not being assigned to any groups within Access Anywhere.

To resolve this you will need to update the Enterprise App to filter the groups just to the Roles you would like to leverage in Access Anywhere.

You can achieve this either by selecting an option like “Groups assigned to the application” and assign the relevant groups to the Enterpise App, or apply a filter to restrict based on a given prefix or suffix.

Once this is set, we will copy and save the URLs



Next we will download the Certificate (Base64) from the “SAML Signing Certificate” section.



Next we will make sure we have added the correct users and/or groups to the Enterprise Application. (only users/groups entered here will be able to log into the Access Anywhere server via this SAML integration)



Finally, we will ensure we are passing all the correct attributes that the Access Anywhere server needs.

In the “User Attributes & Claims” we'll add a new claim and make sure all the claims below are entered:



Please note, in order to get the correct UPN local part for the user we will need to create a transformation for one of those attributes, like so:

Transformation: ExtractMailPrefix()

Paramater 1: user.userprincipalname

In order to get the correct group names from AD FS, we will need to enable the Microsoft Graph API.

In App Registrations, create a “New registration”, naming it something like “NAA GraphAPI”.

Once created, we will edit the API permissions, and “Add A Permission”.

From the list, select Microsoft Graph.

Select Application permissions when presented with the choice.

Input “Directory.Read.All” into the search field and select the permission when returned.

Click Add permissions

These permissions will need to be granted for the organisation, by clicking the Grant admin contest for XX Directory.

Now we will gather the credentials. In “Overview”, copy the “Application (client) ID”.

In “Certificates & Secrets”, click “New client secret” in “Clients Secrets” section. Set Description to something like “NAA” and decide when it expires. Now copy the new Value added in the Client Secrets section.

As an Org admin, we will now enable SAML Authentication. Click on: Organization > SAML 2

Fill in the following details:

Auth System Name - Azure SAML

Login Button label - This text field will be what is displayed in the login button on the Access Anywhere login page. Use something that the users will understand like “Login with Microsoft Azure”

The service provider entity ID - Enter the “Azure AD Identifier” you saved from the Azure Enterprise Application SAML App setup screen above

SSO Entry point - Enter the “Login URL” you saved from the Azure Enterprise Application SAML App setup screen above

Logout Service Endpoint - Enter https://login.microsoftonline.com/common/wsfederation?wa=wsignout1.0

Certificate Data - Enter the certificate text you downloaded from the Azure Enterprise Application SAML App setup screen above

Fetch User Role\Group Name by id - Check

Azure AD Application ID - Enter the GraphAPI “Application (client) ID” saved from above

Azure AD Application Key - Enter the “Clients Secrets” value saved from above

Auto create user on login - Check if you would like users to be auto provisioned when logging in via SAML

Update user roles/groups on login - Check if you would like Access Anywhere roles to be updated on user login

Update user info on login - Check to update all user information on SAML login User Import Fields

Ensure the following mappings are set:

User Login Field: loginname

Once your Auth System has been created in Access Anywhere, you will then be able to obtain a Reply URL. From the Auth Systems screen, copy the URL supplied next to the Reply URL field.

Go back to the Enterprise Application you created within Azure, and edit the Basic SAML Configuration. Replace the Reply URL with the URL from the Auth System screen.

Azure provides mechanisms to test the integration.

Your users will be then able to access the application from here: https://myapplications.microsoft.com/

As the administrative user for your Google Workspace domain, login to the Google Workspace Admin page.

Then Select Apps > SAML Apps from the menu on the left hand side of the screen (“hamburger menu”).



On the following screen, click the yellow plus (+) symbol in the bottom left to add a new SAML Application. Then select “Setup my own custom app”

On the next screen you will want to save the SSO URL, Entity ID and download the certificate.



On the next page enter an Application Name that matches your Access Anywhere system, and use any Description or Logo you would like, and click next.

Next fill out the “Service Provider Details” like so:

ACS URL = Access Anywhere URL + “/saml.htm” - ex: https://filefabric.fileserverapp.com/saml.htm

Entity ID = Access Anywhere URL - ex: https://filefabric.fileserverapp.com/

Start URL = Access Anywhere URL - ex: https://filefabric.fileserverapp.com/

Name ID = Leave as Default: Basic Information > Primary Email

Name Format = Leave as Default: Unspecified



We will set up the following mappings in the Attribute Mapping Section:

Username > Basic Information > Primary Email

email > Basic Information> Primary Email

fullname > Basic Information > First Name

groups > Employee Details > Department

phone > Contact Information> Phone Number

upn > Basic Information > Full Name



Click Finish to complete the setup of the SAML App.

Finally select the three dot menu for the app and select “ON for everyone” to enable all of your Google Workspace users to use this app.

As the Org admin, we will now enable the SAML Authentication.

Click on: Organization > Auth Systems.

Select: Auth System > SAML 2

Fill in the following details:

Auth System Name - Google Workspace SAML

Login Button label - This text field will be what is displayed in the login button on the Access Anywhere login page. Use something that the users will understand like “Login with Google”

The service provider entity ID - Enter the Entity ID you saved from the Google SAML App setup screen

SSO Entry point - Enter the SSO URL you saved from the Google SAML App setup screen

Logout Service Endpoint - https://accounts.google.com/Logout

Certificate Data = Enter the certificate text you downloaded from the Google SAML App setup screen

Fetch User Role\Group Name by id - Leave unchecked

Auto create user on login - Check if you would like users to be auto provisioned when logging in via SAML

Update user roles/groups on login - Check if you would like Access Anywhere roles to be updated on user login

Update user info on login - Check to update all user information on SAML login

User Import Fields

Ensure the following mappings are set:

Unique user attribute > username

User login field > username

User Name field > fullname

User email field > email

Role\Group name field > groups

User Phone field > phone



Click Test and then Update to save these settings

From your Okta's Administrative account, click on Applications from the top menu, and then click Add Application. From the left menu click on the Create New App button.

For the Platform option, select Web.

For the Sign on method, select SAML 2.0.

Then click Create.

On the next screen, we need to supply some basic information for the application.

For the App Name, provide a friendly name for the NAAservice, e.g. Access Anywhere. Optionally you can also provide an App logo that users would recognize.

Click Next.

On the SAML settings screen we want to configure the fields as follows:

• Single sign on URL - This should be the URI of your Access Anywhere server, appended by “/saml.htm”. For example “https://files.example.com/saml.htm”
• Audience URI - This should be the URI of your Access Anywhere server, e.g. “https://files.example.com”
• Default RelayState - This should be left blank
• Name ID format - Select Email Address
• Application username - Select Okta Username

Under Show Advanced Settings:

• Tick Enable Single Logout
• In Single Logout URL enter the value you entered in Audience URI
• In SP Issuer enter the value you entered in Audience URI
• From the Signature Certificate upload the Signing Certificate that can be obtained from your Access Anywhere appliance Auth System configuration screen.

Under Attribute Statements configure the mappings as follows:

• Name “email”, Name format “basic”, Value

 user.email 

• Name “fullname”, Name format “basic”, Value

user.firstName + "  " + user.lastName 

• Name “username”, Name format “basic”, Value

user.login 

Under Group Attribute Statements, you will need to choose which groups need to be exposed to Access Anywhere.

A Groups Entry will need to be added with a name of “groups”. The Value is dependant on what you would like to expose to Access Anywhere. Some examples are below:

• Contains: IT - Matches groups containing the word “IT”
• Regex: “^.*$” - Matches all groups

Follow the on-screen steps to save the changes.

On the Application Details screen, under Sign On, click the View Setup Instructions button.

On the Access Anywhere SAML Auth System screen, enter the following values:

• The Service provider entity ID - The URI entered earlier from the Audience URI field
• SSO entry point - Enter the Identity Provider Single Sign-On URL found on the Okta setup instructions screen
• The logout service endpoint - Enter the Identity Provider Single Logout URL found on the Okta setup instructions screen.
• x509 Certificate - Enter the X.509 Certificate found on the Oka setup instructions screen

Before users are able to access the Okta application, Users or Groups must be assigned the application for it to be available to them.

Your Okta setup with the Access Anywhere server is now complete.

First you will need to set up your Duo Access Gatway As defined here: DAG Create your cloud application in duo.

Service Provider Name: NAA Access Anywhere

Entity ID: your Access Anywhere URL

Assertion Consumer Service: your Access Anywhere url + /saml.html



Send Attributes: All

a) Group name fix There is an issue with the group name (when leveraging AD as the Directory backend). By default the results that come back are the DN and not the friendly name.

When you finish generating the json file you’ll edit to to update the memberof to look like so:

            "94": {
                "class": "core:AttributeAlter",
                "subject": "memberOf",
                "pattern": "/^CN=(.*?),.*/",
                "replacement": "${1}"
            },

Apply that json to your DAG.

Update DAG to return displayName (and other attributes we need)

We need to ensure that the display name is returned:

In the DAG under Authentication Source we can add displayName as one of the attributes to return:



Gather info from DAG for NAAintegration

Follow the steps as defined here: DAG - Configure Your Service Provider This will give you URL/IDs/Certs needed for Access Anywhere Auth System Setup.

Create Auth System in SME

We’ll enter this data into Access Anywhere. Logged in as the Org Admin, in a package with SAML enabled, go to Organization> Auth Systems.



This will now allow your users to click the Duo Access Gateway login button the page and login through your DAG into Access Anywhere.