Share File offers two ways a user to authenticate:
Share File Integrated authentication:
The user logs on with his Share File username (his e-mail address) and its Share File password that he has forgiven after activating their user accounts in Share File.
The user logs on using the credentials that he already knows from his corporate environment (eg Active Directory credentials). For more information about SAML: https://de.wikipedia.org/wiki/Security_Assertion_Markup_Language
Short explanation to the topic SAML:
A SAML server (also SAML IDP (Identity Provider) called) is nothing more than a Web server that will be published. About this SAML IDP a user in the company’s environment can with the known him credentials to authenticate (eg Active Directory), and then receives a ticket from the SAML IDP. This ticket can then log on to services that are outside the corporate environment (such as File Share, Office 365 or Salesforce). The services are to be used must be configured accordingly for their own SAML environment so that an application with the SAML ticket is also accepted.
The advantage of SAML is: The user knows his credentials anyway and has a central access point and authentication instead of having to multiple user names and passwords. In addition, the authentication always takes place in its own corporate environment and not to an external service.
Share File and SAML:
Entering the Account Share File URL (eg https://firma.sharefile.eu) redirects the user to the normal standard login page Share File:
This is the default.
Should take place an authentication with SAML, the user typically needs to specify a different URL, for example https://firma.sharefile.eu/saml/login. Here, then, is behind the normal Share File URL account yet / SAML / login inserted, which then redirects the user to the SAML authentication URL.
About the Share File Support the default behavior of the login page can be changed, so you will for example be forwarded immediately when you enter the account URL without the addition / SAML / Login for SAML URL – this would, however, prevent external users could log in to the Share File System, because these usually have no proprietary user account and must register with the Share File credentials. However, the Share File Support can also change the default page so that a dual login page appears:
Here you can now select whether you want to carry out the registration via SAML (left side) or Share File authentication (right side).
In the mobile apps Share File can basically always choose whether the application wants to perform with the company credentials (SAML) or File Share credentials. Here the dual registration option is permanently installed and does not need to be activated.
In all other Share File applications this is not possible and dual registration facility is not supported. Take, for example, the Outlook plug-in, so the application will automatically detect whether Share File SAML account is enabled on the and also requires this type of login. If the account is set to Share File application and not on SAML as the user must enter his credentials Share File.
Now always comes the question why this is so and only the web interface and the mobile app allows this dual registration and support. The answer is very simple, because these two Share File applications can both licensed users (in Share File employee called) and unlicensed users (called in Share File clients) be used. All other Share File applications can be used only by licensed users, thus it makes no sense to install a dual registration there.
The SAML login is in File Share Account in the Admin section under Configuring Single Sign-On is configured and enabled:
Is this KontrollkästchenSAML set Enable, then (except the web interface and the mobile app) require a SAML authentication from now on each tool.
Just because SAML enabled this does not mean that licensed users sin now forced to carry out the registration via SAML. Each user has a Share File username and password in Share File – always! And with these credentials, a user can also carry out an application. Enable SAML in this case means first only that a user can carry out the registration via SAML – does not have to! To force the user to use SAML as an application, this must be configured on this page. The option for this is to find among the optional settings and is called SSO Registration required. With this option enabled MUST be a licensed user via SAML login.
The way in which the application takes place via SAML depends always from the SAML identity provider used. Share File supports SAML 2.0 and SAML supportet among other IDP’s as XenMobile Server (in XenMobile is a SAML IDP integrated), Citrix NetScaler, Microsoft ADFS, Azure AD, ONELOGIN, Ping Federate or Okta.
Depending on what can support these SAML IDP’s and how they carry out the registration and on what logon directories a connection can be made different scenarios are covered (eg 2-factor authentication, Windows Integrated authentication, form-based (Web) authentication, etc.). All this has nothing to do with the Share File application. Registration always takes place on the own SAML IDP – in this moment of registration is also not connect to Share File. Therefore, one should make sure to use a SAML IDP, which corresponds to own Bedrüfnissen. I often get the question whether a Share File 2 factor authentication support and the answer is no, but … But no why? Well, if SAML is used for authentication, it depends on the SAML IDP used if a 2-factor authentication can be established or not. Actually, my answer would have to be called, but Share File itself does not 2-factor authentication (and that would make any sense anyway). But if a company wants to use for security reasons SAML, then he can of course insert a 2 factor authentication – providing the SAML used IDP supports this. And here the 2-factor authentication makes sense, because everything is in our own hands to control the in-house IT.
In the second and third part of this blog series I want to show the installation and configuration using the example of Microsoft ADFS 2.0 and 3.0. These are from my experience in customer projects, the most common SAML IDP’s.
Until then: Stay tuned