Evidian Web Access Manager provides its own portal home page to authenticate users. This portal can be customised in accordance with the company style guide. You can also use a web page from a web server protected by Evidian Web Access Manager as the user home page for the portal.
Evidian Web Access Manager allows the web pages of protected applications to be modified dynamically. This unique functionality makes it possible to use any page on a protected server as an authentication window for restricted-access services.
Here is an example of a web page from a server in the original version:
Once the page has been protected by Evidian Web Access Manager, this page will receive a new user authentication form. This page is in the "public" zone, accessible to all, and will serve as a portal for protected services that require authentication.
The page is dynamically modified in transit through Evidian Web Access Manager and becomes:
The authentication form and a link to the password recovery service have been dynamically inserted without modifying the web server.
Users can then be authenticated for access to their private services:
A new menu has been inserted dynamically into the page. It contains links to users' private services. Even if the user has bookmarks linking to private services, and is not authenticated, an authentication request will be automatically triggered.
The customisation of the authentication form, and the information displayed after authentication, is done through portions of the HTML code and can therefore be presented in any format.
This functionality allows any web page or web server to be transformed into a portal user homepage and facilitates the seamless integration of Evidian Web Access Manager into the company branding.
At no point are the original web pages modified on the server.
Evidian Web Access Manager supports SAML 2.0 as a Service Provider or Identity Provider. When company domain users wish to access the company's "Google Apps" applications, Evidian Web Access Manager is used as the Identity Manager.
When users connect to Google applications using URLs such as https://mail.google.com/d/domain.com or https://calendar.google.com/d/domain.com or through the Google authentication hub https://www.google.com/apps, they will be redirected to the company's authentication page.
Evidian Web Access Manager's Identity Provider supports all kinds of authentication, and users who, for example, have already been authenticated in the company's copy of Kerberos, will see no authentication window. Single Sign-On is federated for cloud and Google applications as well as the company's internal applications.
Here is an example of an access scenario for Google applications. A user "werner" tries to connect to his Google Calendar account through his company's dedicated URL: https://calendar.google.com/a/anon.frec.bull.fr. He is instantly redirected to the Identity Provider URL:
The user authentication is therefore managed by the IDP, while decisions about the strength of the authentication and the means of authentication are taken by the company. Each authentication produces logs and audit events.
Once he has been correctly identified, the user is automatically redirected to the page of the Google service:
All of the Google services are accessible:
Users may be handled by Google Apps manually or automatically, using Google Apps Directory Sync.
The IDP configuration has native support in Evidian Web Access Manager without the need for additional licences or software. Any configuration that protects internal web applications can rapidly become an Identity Provider for cloud services.
The cloud transforms the way people work with their company applications. Professional users deploy more and more software available in SaaS mode to complete their tasks. Salesforce, for example, offers all the functionality of a CRM to the sales staff who use it, and Google Apps allows its users to be more productive. However, the questions arising are even more obvious:
What about security?
How can we ensure effective access control?
How can we help users through, with the multiplication of URLs for SaaS mode services, and logins and passwords that are constantly changing?
Evidian uses identity federation standards to provide a Single Sign-On for cloud applications.
Evidian has also developed proprietary tools to protect and provide SSO to specific SaaS mode applications that do not comply with standards. Evidian addresses cloud security with the following usage scenarios:
- Companies using applications available in SaaS mode
- Companies that use their own private cloud
- Providers of cloud services that wish to protect the services they offer
Social authentication (or delegated authentication)
Issue
A truck manufacturer wished to provide access to dedicated services (technical documentation, the catalogue, reporting, etc.) for its dealers. The manufacturer's aim was to simplify access for dealers while minimising the administration tasks related to user account management.
Our solution
Because users can be located anywhere, we suggested creating a Social Login. Dealers could then use their LinkedIn accounts to access dealer services.
Evidian Web Access Manager includes an authentication module allowing user authentication to be externalised to an external identity provider. The implementation of protocols such as SAML, OpenID and OAuth allow authentication to be delegated to a large number of identity providers, such as for example:
