applications
Single Sign-On Identity Provider
Enabling biometric single sign-on to web applications
The Challenge
The constant increase in complexity, especially due to globalisation, forces us to use more and more applications to optimise corporate performance and communication on a daily basis. We saw a dramatic change in how people work and do business with the introduction of the World Wide Web. People are no longer tied to specific locations and/or devices.
We are now able to communicate with each other in real time over the Internet; bridging continents and time zones. This results in the need for new business models and the migration from traditional mainframe and client-server applications to more mobile user applications in a cloud environment.
These processes and workflows ask for highly complex and integrated applications with massive storage needs. We see a vast increase in applications that are partly or completely hosted outside an organisation, only to be accessed when required through a specific supplier portal and/or via the cloud. Today we need applications and information that can be accessed instantaneously from multiple devices (such as laptops, smart phones, tablets, desktops and so on), at times even from a variety of devices, by the same user. Due to the changed environment, the need for a different access modality is necessary. It amplifies the need of secure access to applications from virtually anywhere on any device that is able to connect to the web, while maintaining and securing application and data security. In many cases, moving from organisation specific built and hosted business applications with the necessary in-house support and development, to outsourced applications via the web or cloud and their reduced support needs.
This increase in usage and portability asks for a safe and easy way to use the applications and keep track of their rightful use. In the past, we were looking at user specific log in and password systems; however, with the increase of usage and/or users it was increasingly more difficult to administrate, especially for bigger enterprises. The unique user and password combinations are hard to manage; the art in keeping them safe and still easily available, poses more and more challenges to organisations and individuals
Externally hosted applications generally require each user to have their own username and password combinations. This reduces productivity and increases security risks from phishing and hacking, as users tend to pick memorable passwords. If an organization attempts to thwart this by establishing strict password policies, users are prone to record passwords offline, leading to further vulnerability. What is needed is a way to eliminate passwords altogether and provide SSO to web applications, while maintaining high security levels.
Important Concepts
Authentication
Authentication (from Greek: αὐθεντικός authentikos, “real, genuine”, from αὐθέντης authentes, “author”) is the act of confirming the truth of an attribute of a single piece of data claimed true by an entity. With information systems, the term authentication is commonly used to describe access control, specifically the process of obtaining factors from a person using a system, to determine if that person is who they claim to be. The most common form of authentication is using username and password.
Security research has determined that for a positive authentication, elements from at least two, and preferably all three, factors should be verified. The three factors (classes) and some of elements of each factor are:
- the knowledge factors: Something the user knows (e.g., a password, partial password, pass phrase, or personal identification number (PIN), challenge response (the user must answer a question, or pattern), Security question
- the ownership factors: Something the user has (e.g., wrist band, ID card, security token, implanted device, cell phone with built-in hardware token, software token, or cell phone holding a software token)
- the inherence factors: Something the user is or does (e.g., fingerprint, retinal pattern, DNA sequence (there are assorted definitions of what is sufficient), signature, face, voice, unique bio-electric signals, or another biometric identifier).
Authorisation
Authorisation is the function of specifying access rights/privileges to resources, which is related to information security and computer security in general and to access control in particular. Once the identity of a person has been established (by using authentication), authorisation takes care of determining which function can be used by the authorises person, and what data van be seen or modified by that person.
Identity Federation
Federated identity management (FIM) is an arrangement that can be made between multiple parties to let subscribers use the same identification data to obtain access to the networks of all the enterprises in the group. The use of such a system is sometimes called identity federation.
Identity federation links a user’s identity across multiple security domains, each supporting its own identity management system. When two domains are federated, the user can authenticate to one domain and then access resources in the other domain without having to perform a separate login process.
Identity federation offers economic advantages, as well as convenience, to enterprises and their network subscribers. For example, multiple corporations can share a single application, resulting in cost-savings and consolidation of resources. Single sign-on (SSO) is an important component of identity federation, but it is not the same as identity federation.
Identity federation involves a large set of user-to-user, user-to-application and application-to-application use cases at the browser tier, as well as the service-oriented architecture tier.
Available Standards
Single sign-on and Federated identity would be impossible without standards. Any advantage would be lost due to development and negotiations by each single organisation on its own.
Three major protocols for federated identity emerged: OpenID, SAML, and OAuth
SAML 2.0
The OASIS Security Services Technical Committee (SSTC) started in 2001 to define an XML framework for exchanging authentication and authorization information. The first version of SAML was published in 2002, and SAML 2.0, the version of the standard which is in force until today, was published in 2005.
The SAML specification defines three roles: the principal (typically a human user), the identity provider (IdP), and the service provider (SP). In the primary use case addressed by SAML, the principal requests a service from the service provider. The service provider requests and obtains an authentication assertion from the identity provider. On the basis of this assertion, the service provider can make an access control decision, that is, it can decide whether to perform the service for the connected principal.
At the heart of the SAML assertion is a subject (a principal within the context of a particular security domain) about which something is being asserted. The subject is usually (but not necessarily) a human. As in the SAML V2.0 Technical Overview the terms subject and principal are used interchangeably in this document.
Before delivering the subject-based assertion to the SP, the IdP may request some information from the principal, such as a user name and password, in order to authenticate the principal. SAML specifies the content of the assertion that is passed from the IdP to the SP. In SAML, one identity provider may provide SAML assertions to many service providers. Similarly, one SP may rely on and trust assertions from many independent IdPs.
The primary role of SAML is authentication, but SAML offers a rich feachure set to enable identity federation.
The convenience of identity federation and one-click access to web applications has shown a significant increase in the adoption of applications. Identity federation also enhances security, limits risk and improves compliance by eliminating web application passwords. When it comes to delivering business value, identity federation helps remove business barriers, reduce costs and increase productivity for the entire enterprise.
OAuth
OAuth 2.0 is an industry-standard protocol for authorization. OAuth 2.0 supersedes the work done on the original OAuth protocol created in 2006. OAuth 2.0 focuses on client developer simplicity while providing specific authorization flows for web applications, desktop applications, mobile phones, and living room devices. This specification and its extensions are being developed within the IETF OAuth Working Group.
OAuth is an authorization protocol, rather than an authentication protocol. Using OAuth on its own as an authentication method may be referred to as pseudo-authentication
OAuth is a service that is complementary to and distinct from OpenID. However, OAuth is directly related to OpenID Connect (OIDC) since OIDC is an authentication layer built on top of OAuth 2.0.
Open ID
OpenID is an open standard and decentralized authentication protocol.
Promoted by the non-profit OpenID Foundation, it allows users to be authenticated by co-operating sites (known as relying parties, or RP) using a third-party service, eliminating the need for webmasters to provide their own ad hoc login systems, and allowing users to log into multiple unrelated websites without having to have a separate identity and password for each.
Users create accounts by selecting an OpenID identity provider, and then use those accounts to sign onto any website that accepts OpenID authentication. Several large organizations either issue or accept OpenIDs on their websites according to the OpenID Foundation.
The OpenID standard provides a framework for the communication that must take place between the identity provider and the OpenID acceptor (the “relying party”). An extension to the standard (the OpenID Attribute Exchange) facilitates the transfer of user attributes, such as name and gender, from the OpenID identity provider to the relying party (each relying party may request a different set of attributes, depending on its requirements).
The OpenID protocol does not rely on a central authority to authenticate a user’s identity. Moreover, neither services nor the OpenID standard may mandate a specific means by which to authenticate users, allowing for approaches ranging from the common (such as passwords) to the novel (such as smart cards or biometrics).
The current version of OpenID is OpenID Connect 1.0, finalized and published in February 2014
Open ID Connect
OpenID Connect is a simple identity layer on top of the OAuth 2.0 protocol, which allows computing clients to verify the identity of an end-user based on the authentication performed by an authorization server, as well as to obtain basic profile information about the end-user in an interoperable and REST-like manner. In technical terms, OpenID Connect specifies a RESTful HTTP API, using JSON as a data format.
OpenID Connect allows a range of clients, including Web-based, mobile, and JavaScript clients, to request and receive information about authenticated sessions and end-users. The specification suite is extensible, supporting optional features such as encryption of identity data, discovery of OpenID Providers, and session management.
A Closer Look at SAML
Wikipedia defines SAML 2.0 as: “Security Assertion Markup Language 2.0 (SAML 2.0) is a version of the SAML standard for exchanging authentication and authorization data between security domains. SAML 2.0 is an XML-based protocol that uses security tokens containing assertions to pass information about a principal (usually an end user) between a SAML authority, that is, an identity provider, and a SAML consumer, that is, a service provider. SAML 2.0 enables web-based authentication and authorization scenarios including cross-domain single sign-on (SSO), which helps reduce the administrative overhead of distributing multiple authentication tokens to the user.”
How Does SAML 2.0 Work?
A user can access applications, a portal, or website address without having to login with username and password to every application individually. The applications which the user wants to access, or more specifically, the part of the application which understands how to ‘speak SAML’, are called Service Providers.
When the user attempts to access the application (the SAML service provider) it would in the background send a message to the IDP, the Identity Provider. The Identity Provider could be the employer, or a third-party company like PayPal or Amazon. The Identity Provider checks if the user is allowed to use the specific application. The Identity Provider then sends a specific secure message to the Service Provider to allow usage of the application with the details of the user. The Service Provider makes sure that the message comes from a trusted Identity Provider and then grants the requested access. As the user, you do not see all the communication of the Providers in the background. The user only clicks on a link and is then directed into the desired application.
SAML Use in Enterprise
Enterprises can share identity between an existing IDM system and web applications. There is an Outbound Internet SSO to web-based cloud, business-process outsourcing, partner, vendor or supplier applications. There is also an Inbound Internet SSO that provides secure access to internal web applications for customers, business partners and affiliates/subsidiaries.
Benefits:
- Username/Password combinations do not cross firewalls. The authentication of the user happens within the firewall.
- Web applications with no passwords are much harder to hack as the authentication process happens within an enterprise IDM that features much stronger mechanisms.
- Access for users outside the firewall will be sent to an authentication portal. Only after authenticating there is the user allowed to use the app and their username/password combination stays hidden and locked inside the firewall.
- Easy change of application suppliers – since SAML is an open standard, one can switch suppliers without an impact to the user’s experience.
- Reusable – several SPs can connect to one IDP for authentication and vice versa.
- Better accessibility.
- Eliminates the administration and development cost of implementing a proprietary SSO solution.
- Removes the administration and in-house IT helpdesk function for username/password combinations.
SAML Use in Enterprise
SMBs have the same advantages, however, they usually miss the in-house IT and helpdesk function and, therefore, even profit more from the identity federation service. Microsoft offers a directory service that comes with many Microsoft Windows Server products providing similar SSO options.
Alcazar SSO Identity Provider
The Alcazar SSO Identity Provider combines the benefits of an OIDC 1.0 and SAML 2.0 Identity Provider with biometric authentication. Biometric authentication is generally considered stronger and more reliable than username and password, as a fingerprint cannot be shared, lost or forgotten. Biometric authentication is more convenient, as no passwords need to be remembered. Biometric authentication is also more support friendly, as password resets are no longer required.
The SSO Identity provider integrates with a biometric store and common LDAP directories, in particular Active Directory.
The IDP is configured by mutual metadata exchange with participating web applications. Once a trust relationship has been established, the participating application can request an authentication workflow from the IDP and obtain an assertion from the IDP that a user has been authenticated and may access the application.
The IDP maintains its user base in an LDAP directory (specifically, Active Directory), and/or performs biometric verification against biometric credentials stored in LDAP or in Biostore, depending on client requirements and configuration.
Many off-the-shelf web applications (like Oracle, SAP, SalesForce, or CA) support both SAML and OIDC out of the box, and are ready to interact with the IDP by simply mutually exchange metadata. For custom or in-house applications, the Alcazar SSO Identity Provider includes an integration kit, which makes enabling your web applications for OIDC or SAML easy.
Sign Sign-On Identity Provider is part of our single sign on suite. Explore our signle sign on solutions.