In the past decade we’ve literally seen an explosion of web based applications make their way into many big and small businesses. No doubt, the payoff has been great. With various business models, such as Amazon and Ebay, the Web Service concept was born allowing companies to consolidate several “stores”, aka Portals, and offer the consumer a one-stop-shopping experience.In the past decade we’ve literally seen an explosion of web based applications make their way into many big and small businesses. No doubt, the payoff has been great. With various business models, such as Amazon and Ebay, the Web Service concept was born allowing companies to consolidate several “stores”, aka Portals, and offer the consumer a one-stop-shopping experience.
The same opportunities made their way to large corporations. Big companies with affiliates, such as 401K, Health Insurance, and Payroll providers are able to offer their employees access to portals built directly inside company’s intranet sites.
With these implementations new challenges have arrived. For example, in order for an employee to see his or her payroll and file a medical claim, the employee would have to log onto 2 separate sites and provide a set of credentials to each before being able to get access to each portal.
So how do we solve this issue? The concept is simple and certainly not new today. But the adoption of the SSO technology had been pretty slow up until about 5 years ago when the adoption of the single sign-on soared. The main reason for such rapid growth is technology maturity.
There are various single sign-on authentication technologies today. Common examples of Enterprise Single Sign-on (ESSO) are Windows Integrated SSO allowing the user to access applications within the network. Another example is a Server based SSO allowing systems such as a RACF Mainframe to be used by a user authenticated utilizing Active Directory.
And there is a Web Single Sign-On enabling the user to access resources over the Internet using a single set of user credentials
For this blog entry we will focus on Web Single Sign-On technology managing authentication using web based protocols.
Let’s look at the typical Federated Single Sign-On scenario: Health Care and 401K providers are doing business with an Employer and have their sites available to employees within Company intranet site. An employee of the company has to (1) log onto the company’s intranet site, (2) log onto the 401K site By adding SSO the user will be able to log on once and let the trusted partners ascertain that the logon was a success. In other words, if you authenticate your employee against your Directory, then I trust you and will allow him/her to enter my site without prompt for credentials.
There are several Single Sign On implementation methods developed and available today:
In future blogs we plan to cover each of the methods in details, but today we will explain the benefits of SAML-based authentication and Shibboleth metadata validation.
SAML is an XML-based framework. With proper formatting and following the guidelines and standards of the OASIS consortium, it allows businesses to make secure assertions and securely exchange identity information.
On March 28, 2008, The Oasis Technical committee laid out well-defined standards for SAML 2.0. Perhaps most important is the Metadata requirement. Without properly formed Metadata the Identity Provider fails during parsing. The required end point location must be properly defined for an Identity Provider to build a SAML response and to redirect the user to a proper destination.
An example of metadata (below) shows required elements for an Identity Provider to understand a SAML request:
|<EntityDescriptor xmlns_saml=”urn:oasis:names:tc:SAML:2.0:assertion” xmlns_ds=”http://www.w3.org/2000/09/xmldsig#” entityID=”https://site.with.certificate.com”><SPSSODescriptor AuthnRequestsSigned=”false” WantAssertionsSigned=”true” protocolSupportEnumeration=”urn:oasis:names:tc:SAML:2.0:protocol”>
<KeyDescriptor use=”signing” xmlns_md=”urn:oasis:names:tc:SAML:2.0:metadata”>
<ds:X509Certificate xmlns_ds=”http://www.w3.org/2000/09/xmldsig#”>cert info</ds:X509Certificate>
<AssertionConsumerService isDefault=”true” index=”0″ Binding=”urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST” Location=”https://home.customer.redirect.location.com” />
Metadata Validation using Shibboleth
Shibboleth is an open source software package for web single sign-on. The schema file used in validation is included as part of the package and installs to /usr/share/xml/opensaml/saml-schema-metadata-2.0.xsd by default.
- XMLSEC Tool: validates the schema as well as well-formedness of the metadata document.
The following syntax is used to perform validation:
o xmlsectool.sh –validateSchema –schemaDirectory /usr/share/xml/opensaml/ –inFile your-metadata.xml
- XMLLINT: This utility is included with RedHat and allows you to validate metadata against the predefined OASIS SAML schema metadata XSD file. To perform validations on RedHat execute following command:
o xmllint –schema click here –noout example-metadata.xml
As usual if you have questions, comments or concerns feel free to reach out to us at IDMWorks.