Overview
Your organization may have users from multiple domains (for example, because of a merger, or due to different geographical locations), you may want to have the users log on to an M-Files vault through their own existing domain credentials. This article explains how you can achieve this for an OAuth setup. For the sake of brevity, we will assume familiarity with user synchronization and authentication (you can see the starting points for those in the Document Vault Authentication article if you are not familiar with the concepts).
Example
Let's say we have the following two users: user1@domain1.com and user2@domain2.com that need access to the vault. Thus, in another format (called down-level), their Windows users can be read as domain1\user1 and domain2\user2.
Solutions
There are several ways you can enable them to authenticate with their current windows users and domains against the vault:
- Create login accounts in M-Files with their correct domains
- Set up two scopes for federated authentication
- Migrate them all to the same domain
- Provide the same domain to M-Files only
- Possibility to map several domains to one domain in M-Files
Create login accounts in M-Files with their correct domains
Create (or sync) login accounts in M-Files with the current domains - if the users don't have logins in M-Files already, there is likely no need to map them to one domain in M-Files if they are not in that domain in the external system.
Assuming that the IDP can authenticate the different domains, then M-Files logins will work.
For example, user with AAD user user@domain1.com can have an M-Files login like domain1\user1 (in M-Files, user names are converted to down-level by default), and user2@domain2.com can have domain2\user2. Those user names should be coming down in the appropriate account claim and this is what M-Files will send to AAD.
Set up two scopes for federated authentication
If you have created the logins with the different domains, but they come from different tenants or even IDPs, you can create several scopes for the authentication so that each domain has its own scope.
You can see examples in the help texts in the M-Files Admin. Here is the general pattern for the scope:
Host:<network address>:<account type>:<domain name>
For example, the first one can be:
Host:myVault.cloudvault.m-files.com:Windows:domain1
And the second one:
Host:myVault.cloudvault.m-files.com:Windows:domain2
Where each can have its own AAD setup, with different tenants, AAD apps and so on.
Migrate them all to the same domain
For example, in a merger situation, the end goal may be that all users will use the same domain. You should try to do this change before adding login accounts and user accounts for them in the M-Files server/vault.
If all users in AAD (if we take AAD as an example for an identity provider) have the same domain, you could then enable user synchronization for them, and import them in the vault, and then authentication will work seamlessly with the basic authentication setup.
Provide the same domain to M-Files only
Note that this approach has the most caveats, listed below.
If you can edit the accounts in the IDP, you could provide the same type of information for all users, regardless of their actual domain. For example, if a claim "preferredUserName" comes from AAD always like user1@dom1.com and user2@dom1.com even if the original domains are user1@domain1.com and user2@domain2.com, then M-Files will only get "dom1" as the domain (assuming that the AccountClaim in the federated authentication config is set to preferredUserName).
With this approach, you can "lie" to M-Files about the actual domain and "unify" domains for all users. It is important, however, to keep in mind the following:
- Changes to the domains at a later time may break authentication, and renaming domains in the vault can cause issues (for example, it may not be allowed at all, or may break the audit trail).
- The IDP must be able to authenticate the users with that claim, regardless of their actual domain and name.
- The information (such as which user did what to what object) will contain the information from the claim sent to M-Files, so it may not match the user names you would expect.
- The users may get confused on what credentials they are logging in with.
Possibility to map several domains to one domain in M-Files
We have an enhancement idea with ID 156911 logged, with the goal to allow one federated authentication scope to map one domain in the vault against more than one domain in the IDP. You can follow the release notes for news of its implementation.
At the moment, you can map multiple domains to multiple domains through specific syntax in the scope settings in "Advanced" mode - when you edit the JSON directly. For example, you can have "DomainMapping": "Domain1:DOM1 Domain2:DOM2", but not "DomainMapping": "Domain1:DOM1 Domain2:DOM1" (this will not throw an error, but it is invalid configuration that could lead to issues). Note the space before the new line symbol () and that the domains that M-Files gets are different.
Note that, even if it were possible to map more than one domain to one domain per configuration, such an approach still poses a logical problem - if everyone has the same domain in the vault, how would the vault know which domain to map to when sending out the claim to the IDP? Thus, you may want to consider one of the options above and use such syntax only if you need to re-map a few domains for the same authentication scope instead of defining multiple scopes.
