Single Sign-On refers to the ability to use the same pair of credentials (username/password) across different systems.
In some cases, it also encompasses the notion of using them only once to sign in in a single system and be automatically signed in to all “connected” systems.
eFront provides various ways of performing both:
Using SAML 2.0
Using LDAP (or Active Directory)
Using the REST API
Using a cookie
Using a plugin
eFront supports Single Sign-On (SSO), a process that allows users to authenticate themselves against an external Identity Provider (IdP) rather than obtaining and using a separate username and password handled by eFront.
Under the SSO setup, eFront can work as a Service Provider (SP) through SAML (Secure Assertion Markup Language) allowing you to provide Single Sign-On (SSO) services for your domain.
All that you need is a SAML Identity Provider (IdP) which will handle the sign-in process and will eventually provide the authentication credentials of your users to eFront.
eFront users authenticated through your SAML IdP are handled from your IdP and any change they perform on their account (namely first name, last name, and email) is synced back to their eFront account.
You can setup SAML from administrator System Settings→Integrations→SAML page. You have to fill in these values:
Identity provider (IdP): the Identity Provider's (IdP) URL
Certificate fingerprint: fill-in the SHA-1 SAML certificate fingerprint provided by your IdP.
Remote sign-in URL: the remote sign-in URL of your IdP. This is the URL where eFront will redirect your users to signing-in
Remote sign-out URL: the remote sign-out URL of your IdP. This is the URL that eFront will redirect your users when they sign-out.
TargetedID: the variable that holds username (login) of the user
First name: the variable that holds the first name of the user
Last name: the variable that holds the last name of the user
Email: the variable that holds email of the user
The image below shows an example of Saml setup. In this case, simplesaml is configured as IdP server.
SAML Using ADFS 3.0 (Windows server 2012 R2)
You can have a Microsoft Active Directory Federation Services 3.0 (ADFS 3.0) service act as the Identity Provider (IdP), following the simple steps found below. The steps are almost identical when using earlier versions of ADFS, 2.0 and 2.1.
In the following examples, we assume that our ADFS is using the domain name “adfs2.efrontlearning.com” and that our eFront installation is using the domain name “saml.pro.efrontlearning.com”
Step 1. Configure ADFS 3.0
Click to Start the Server Manager. From the tools option, select “AD FS Management”
This will bring up the AD FS management console. Select the “Services” option and right click to reveal the context menu. Click on the “Edit Federation Service Properties…” option.
The “General tab” reveals the “Federation Service Identifier” which is the first item we will need for setting up SSO. In our example, it's http://adfs2.efrontlearning.com/adfs/services/trust
eFront requires a PEM format certificate. So you will need to convert the certificate to PEM format using any appropriate tool or even online tools such as sslshopper (https://www.sslshopper.com/ssl-converter.html). Convert the certificate from DER to PEM format. You will need it during configuration later on. Keep in mind that eFront will work with RSA certificates. DSA certificates are not supported.
Step 2. ADFS 3.0 Relying Party Trust Configuration
by using this step, you are going to define the eFront endpoints in your ADFS. You can do this manually or you can import the metadata XML provided by eFront. You are advised to do the latter since it is easier to implement.
The metadata XML is accessible through a URL, which you can find by signing into eFront and going to System Settings→Integrations–>SAML. Look for “SP Metadata XML”, it should be something like http://saml.pro.efrontlearning.com/saml/module.php/saml/sp/metadata.php/efront-sp Copy and paste the URL in your browser's address bar. A file called efront-sp will be downloaded, which contains the appropriate XML:
<?xml version="1.0"?> <md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" entityID="saml.pro.efrontlearning.com"> <md:SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:1.1:protocol urn:oasis:names:tc:SAML:2.0:protocol"> <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="http://saml.pro.efrontlearning.com/saml/module.php/saml/sp/saml2-logout.php/efront-sp"/> <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="http://saml.pro.efrontlearning.com/saml/module.php/saml/sp/saml2-logout.php/efront-sp"/> <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="http://saml.pro.efrontlearning.com/saml/module.php/saml/sp/saml2-acs.php/efront-sp" index="0"/> <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-post" Location="http://saml.pro.efrontlearning.com/saml/module.php/saml/sp/saml1-acs.php/efront-sp" index="1"/> <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location="http://saml.pro.efrontlearning.com/saml/module.php/saml/sp/saml2-acs.php/efront-sp" index="2"/> <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:1.0:profiles:artifact-01" Location="http://saml.pro.efrontlearning.com/saml/module.php/saml/sp/saml1-acs.php/efront-sp/artifact" index="3"/> </md:SPSSODescriptor> <md:ContactPerson contactType="technical"> <md:GivenName>Periklis</md:GivenName> <md:SurName>Venakis</md:SurName> <md:EmailAddress>[email protected]</md:EmailAddress> </md:ContactPerson> </md:EntityDescriptor>
From the AD FS Manager, go to Trust Relationships → Relying Party Trusts and right click to bring up the context menu. Select Add Relying Party Trust….
SAML Using OneLogin
OneLogin is a service which provides single sign-on and identity management applications. You can use OneLogin as IdP server in your SAML setup.
After creating an account to OneLogin click to Add Apps. Search for 'SAML Test Connector (IdP w/attr)' .You can use the Find Applications field there searching for idp to find it easier.
In SSO tab of your App you can find the necessary values for your integration with eFront. Below is a screenshot for this info
In Configuration Tab you may have to fill in some fields for the integration. Assuming that your valid eFront url is pro.localhost you can see below the required values
ACS (Consumer) URL Validator ^https:\/\/pro\.localhost\/saml\/module\.php\/saml\/sp\/saml2-acs.php\/efront-sp$
ACS (Consumer) URL https://pro.localhost/saml/module.php/saml/sp/saml2-acs.php/efront-sp
After configuring OneLogin account you have to setup IdP settings into eFront as follows:
You can find certificate fingerprint by clicking on View details one OneLogin SSO page.
SAML setup is completed. You should now see a link for Sign in with Saml in your eFront index page.
Note 1: In case most of your users are logged in via Saml, you could check the 'Redirect index page to saml' option. This will redirect eFront's first page to saml login page. Note that you can access eFront login page always via http://efront.url/start/op/login
Note 2: eFront allows you to define saml setup per branch. You can find the same screen for of configuring saml in edit branch page. Defining saml setup in branch will redirect users to this IdP when accessing branch URL to login.
For info about LDAP setup check this page
A user may sign into the system using the “REMOTE_USER” server configuration variable. If the system detects the presence of the “REMOTE_USER” in Web server variables, then it will attempt to sign the user in automatically
You can use the REST API to retrieve a one-time login URL for a specific user. A complete guide to using the REST API can be found here. One of the available calls is the following:
This will return a URL that can be used a single time, and that can be used to sign a user into the system without the need of using a username and password.
Another option for signing a user into the system without inputting a username and password is to use a specially-crafted cookie named 'ef_user'. This should include a serialized array where the key is a user id and the value is a string that matches a corresponding value stored in the user's profile.
If signing in a user automatically requires some process that is not covered by anything available in the system, a plugin can be written to implement the required functionality. A comprehensive guide to creating a plugin can be found here. The plugin would call the User::login function and would sign the user in.