Azure AD SSO

Files.com provides integration with Microsoft Entra ID (also known as Microsoft Azure Active Directory or Azure AD), enabling user authentication and user provisioning from your Azure Active Directory service.

Implementing Single Sign On (SSO) allows your users to authenticate with the password specified in your Azure Active Directory and allows your administrators to manage user credentials and privileges at a single location.

Users can be provisioned within Files.com based on criteria defined within your Azure Active Directory service. For example, you can specify that only users that are members of a specified Group should be provided with Files.com user accounts.

Integration with Azure Active Directory can be achieved using SAML, OAuth, or the LDAP protocol. You can also have more than one Azure AD instance or app connected to your Files.com site.

We recommend using SAML-based integration with Microsoft Entra ID/Azure AD because SAML-based integration is generally more secure, and it also offers seamless user and group provisioning using SCIM.

There are differences in functionality when choosing between SAML, OAuth, and LDAP. Generally speaking, the more modern SAML and OAuth standards are only designed to be used for web and cloud based applications whereas the older LDAP standard can be used by all types of applications but isn't as well integrated with web and cloud based applications. Some notable differences are:

If you don't know which method to use, we recommend using the SAML method for integrating with Microsoft Azure Active Directory which is more secure in general and also SAML method of integration supports the SCIM method for user and group provisioning.

If you decide to use the LDAP method then Azure Active Directory will be integrated with in exactly the same way as with any other LDAP capable service, such as on-premises Active Directory.

Before you start the LDAP integration process, ensure that your Azure AD is set up with LDAPS. Avoid using a self-signed TLS/SSL certificate for LDAPS, and instead, opt for a valid and chained TLS/SSL certificate for LDAPS.

To configure LDAP based integration, refer to the LDAP/Active Directory integration documentation.

Below are the instructions for adding Files.com as an application in Azure AD for SAML integration.

After logging in to your Azure portal as an administrator, navigate to Azure Active Directory -> Enterprise applications and click the New application button.

Click Create your own application.

Enter Files.com or the app name, and click the Create button.

Under Getting Started, click Set up single sign on.

Under Select a single sign-on method, click SAML.

In the Basic SAML Configuration box, click the Edit button.

Complete the form using the following values, and leave other fields at their defaults:

Click the Save button to apply the changes.

Lastly, copy the App Federation Metadata Url in the SAML Signing Certificate box. You will need this URL when adding Azure in Files.com.

Type "SSO Providers" in the search box at the top of every page and then click on the matching result. Click the Add provider button. Click to select the Azure provider.

In the Add provider form, select the Use SAML option, enter Display Name, and paste the App Federation Metadata Url you copied from Azure into the Metadata URL for the SAML identity provider field.

Lastly, click the Save button to apply the change.

The Azure SSO method will now be available when assigning an authentication method for a user in Files.com, and the Sign in with Azure SSO button will be displayed on your site's login page.

Below are the instructions for adding Files.com as an application in Azure AD for OAuth integration. If you plan to use SCIM for user and group provisioning, please be aware that SCIM provisioning is only compatible with SAML-based integration, not OAuth.

After logging in to your Azure portal as an administrator, navigate to Azure Active Directory -> App registrations and click the New registration button.

In the registration form, enter Files.com in the Name field, and enter the URL https://app.files.com/login_from_oauth?provider=azure in the Redirect URI field.

Click the Register button to complete the registration.

Next, copy both the Application (client) ID and Directory (tenant) ID by clicking the copy icon that appears when hovering your cursor over them, and make a note of these by pasting them into a text/document editor.

Next, to generate a client secret, click Certificates & secrets, and click the New client secret button.

In the dialog that appears, enter a Description and select the Expires option according to your preference.

Click the Add button to generate your client secret.

Next, use the copy icon next to the generated secret Value to copy it, and make a note of it along with your previously copied client and tenant IDs.

Type "SSO Providers" in the search box at the top of every page and then click on the matching result. Click the Add provider button. Click to select the Azure provider.

In the Add provider form, select the Use OAuth option, enter Display Name, paste your Directory (tenant) ID copied from Azure into the Tenant ID field, paste your Application (client) ID copied from Azure into the Client ID field, and paste your Client secret copied from Azure into the Client Secret field.

Lastly, click the Save button to apply the change.

The Azure SSO method will now be available when assigning an authentication method for a user in Files.com, and the Sign in with Azure SSO button will be displayed on your site's login page.

There are 2 primary methods for automatically provisioning users through Azure AD: SCIM provisioning and Just-In-Time (JIT) provisioning. SCIM provisioning involves the systematic synchronization of user data between your identity provider and Files.com, ensuring consistent and up-to-date user records. On the other hand, Just-In-Time (JIT) provisioning operates by creating user records on Files.com at the moment of their initial successful login, offering a more immediate approach. These two mechanisms provide flexibility in managing user provisioning based on your specific requirements and preferences within the Azure AD environment.

SCIM Provisioning is a standard that allows your Users to be automatically provisioned in Files.com from your Azure AD identity source. Note that SCIM provisioning is only compatible with SAML-based integration, not OAuth. Files.com offers numerous configuration options for SCIM provisioning, detailed in the Configuration Options section under our SCIM provisioning documentation.

Generate an access token in Files.com when adding Azure AD SSO as a provider or when editing your Azure provider's settings. Locate Enable automatic user provisioning via SCIM? -> Token, configure the token expiration date, and click Save to generate the token. This token is then provided to Azure Active Directory in a subsequent step.

Alternatively, you can opt for the Basic authentication method, which is the SCIM username and password option instead of a token. In your Azure portal, navigate to Azure Active Directory -> Enterprise Applications -> Files.com. Under the Manage menu, select Provisioning, set the Provisioning Mode to Automatic, enter the SCIM API endpoint URL as https://app.files.com/api/scim, set the Secret Token to the access token generated above. Click Test Connection and wait for the confirmation message, then click Save to authorize and enable provisioning.

If you are using token based provisioning, by default the token will expire in a year from the date you generated it. You will receive an alert email from Files.com before your SCIM token is going to expire. You can always extend the expiry date of the SCIM provisioning Secret token in Files.com. Type "SSO Providers" in the search box at the top of every page and then click on the matching result. Edit your Azure provider's settings and locate the Enable automatic user provisioning via SCIM? -> Token -> Token Expiration. You can either enter new date in the Token Expiration text box or pick a new date from date picker UI and click Save.

To revoke the current token and get a new one because it got compromised or for any other reason, you can reset the token from Files.com. Type "SSO Providers" in the search box at the top of every page and then click on the matching result. Edit your Azure provider's settings and locate the Enable automatic user provisioning via SCIM? -> Token -> Reset Token. Once you reset the token and click on Save, new token will be generated and available for you to copy from the Token text box.

If you create a user in Azure AD with the fields User name, Display name (or Name), First name and Last name and provision that user to Files.com via SCIM, the same user will be created or updated in Files.com by mapping Azure fields to Files.com as User name into email, First Name and Last Name combined into Full Name. We ignore Display Name and other fields from Azure AD.

JIT Provisioning works by creating user records on Files.com upon their first successful login. This method is easier than SCIM, however, it suffers from one major limitation as below when used with Azure AD.

Azure AD erroneously communicates Group Names as their Group IDs rather than the actual Group Name. This means that users will be provisioned with a list of groups that shows up as UUIDs (long strings of characters). These groups will work, but they won't be easily understood.

Some customers use our API to retroactively rename those groups, however, this is not a clean solution. We strongly recommend SCIM provisioning instead if you need to provision group memberships from Azure AD.

This is a limitation of Azure AD itself, and not Files.com. JIT Provisioning works properly on Files.com for other SAML providers, including Okta, Auth0, and OneLogin.

JIT Provisioning will work if your Azure AD Users aren't members of any Groups, or if you disable Group provisioning via SAML.

For Site Administrators currently using Active Directory/LDAP and needing to migrate their users to Azure AD SSO, we recommend the process below.

Before migrating, be aware that Azure AD SSO authentication with a password is only supported for browser-based sessions, or the Files.com Desktop app. SFTP and API authentication are supported using SFTP Keys or API Keys.

Set up the Azure AD SSO provider (SAML) alongside your existing Active Directory/LDAP SSO provider. Test the functionality with an existing Active Directory/LDAP user by updating their Authentication method to Azure at User Accounts -> Users -> [Username] -> Authentication. Verify that the user can successfully log in using the Sign in with Azure SSO button. After confirming Azure SSO works for a single user, update the authentication method for the remaining Active Directory/LDAP users to Azure. If dealing with a large user base, consider using one of our SDKs to script this process, and don't hesitate to reach out if you need assistance. Once all users have been updated to use Azure authentication, you can safely remove the Active Directory/LDAP SSO provider.

After migrating users from Active Directory/LDAP to Azure AD there will be some differences in behavior on the Files.com platform:

If you encounter issues with the username not updating automatically after a change in Azure AD, review the following steps for a resolution.

If a username has been changed within Azure Active Directory, the username change may not automatically update the username of the associated Files.com user. There are two easy ways to fix this.

In Files.com, a Site Administrator may update the user's account to match the username within Azure AD. Alternatively, this can be completed within the Azure account by an administrator.

To address this, sign in to your Azure portal, navigate to All services -> Enterprise applications, choose the relevant application where the Files.com user is located, go to the provisioning configuration page, select Provision on demand, input the updated username, and click Provision at the bottom of the page.