L a y e r 7 T e c h n o l o g i e s
Wh i t e P a p e r
Federated Identity & Single Sign‐On Using Layer 7 Federation for Web sites, Web services, APIs and the Cloud
Federated Identity and Single Sign‐On (SSO) Using Layer 7
© Copyright 2012 by Layer 7 Technologies, Inc. (www.layer7.com) 2
Contents
Why do I Need to Federate Identity? ........................................................................................................... 3
Is Federation the Same as Single Sign‐On (SSO)? ......................................................................................... 3
What Standards Address Federated Identity & SSO? ................................................................................... 4
How Does Layer 7 Help Me to Federate SOAP Web Services? ..................................................................... 4
SecureSpan STS ......................................................................................................................................... 5
SecureSpan Gateways for Service Protection ........................................................................................... 7
XML VPN Client for Federating Client Applications .................................................................................. 8
Can Layer 7 Help Me Federate APIs? ............................................................................................................ 9
Can You Describe the Layer 7 Drop‐in Federation Solution? ...................................................................... 10
How Do I Use Layer 7 to Provide Single Sign‐On to My Web Sites? ........................................................... 11
Why Should I Use Layer 7 for Attribute‐Based Access Control? ................................................................. 12
How Can Layer 7 Federate Existing LDAP or IAM Systems with Cloud‐Based SaaS Services Like
Salesforce.com & Google Docs? ................................................................................................................. 12
How Does OAuth Relate to Federation & SSO? .......................................................................................... 13
About Layer 7 Technologies ........................................................................................................................ 15
Contact Layer 7 Technologies ..................................................................................................................... 15
Legal Information ........................................................................................................................................ 15
Federated Identity and Single Sign‐On (SSO) Using Layer 7
© Copyright 2012 by Layer 7 Technologies, Inc. (www.layer7.com) 3
Why do I Need to Federate Identity? You need a federated identity solution if you have any of the following problems:
Your organization has different division or branch offices that have their own directories – and
remote users need access to central IT resources.
You have users with multiple passwords or other credentials that need to be mapped
across applications.
Your organization is merging with another that already has its own identity management system
and you need to provide new users with access to existing applications.
You need to provide internal users with Single Sign‐On (SSO) services across various different
Web applications.
You are developing a mobile device strategy and need to manage access from a wide variety of
remote applications.
You need to provide local users with access to Cloud services such as Salesforce.com and
Google Docs.
All these problems relate to different parts of federated identity. Layer 7 Technologies provides
solutions that federate identity and provide SSO services for Web applications, Web services, APIs,
mobile applications and the Cloud.
Is Federation the Same as Single Sign-On (SSO)? It is a common misconception that federation and SSO are simply different names for the same practice.
While there is certainly overlap between the terms, SSO should be considered a subset of the larger
category of identity federation.
Identity federation addresses the problem of how to integrate separate identity silos. Identity silos (or
islands) are very common occurrence in organizations. They occur when new applications introduce
their own identity stores, such as directories or identity databases, instead of leveraging a centralized
identity management system. They will also commonly occur during a merger or acquisition –
entrenched practices and technologies may make it difficult to merge existing identity stores into a
single unified, authoritative source.
The problem of siloed identity also extends beyond the boundaries of the enterprise. As partnerships
and supply chains become increasingly interconnected, the need arises to manage applications and
users that are not under direct control of any centralized authority but instead exist in autonomous
security domains. Such inter‐company connections are particularly difficult to manage because identity
in both organizations may be changing continuously as people come and go, with no coordination
between business partners.
Federated Identity and Single Sign‐On (SSO) Using Layer 7
© Copyright 2012 by Layer 7 Technologies, Inc. (www.layer7.com) 4
Federated identity management is about the process and technology behind managing siloed identity. It
describes the policies and procedures that govern access to applications and data from entities residing
in another distinct security domain. This includes the overall management of trust relationships, access
control strategies, identity mapping mechanics, policies and common protocols.
SSO is subset of federation that deals specifically with reusing a single identity to authenticate across
multiple domains. Federation is largely about architectural concepts, process and procedures. SSO, in
contrast, is more concerned with technological approaches to solving the problem of individual users
having to manage different identities for different applications.
What Standards Address Federated Identity & SSO? There are a number of standards associated with federated identity management and SSO. One of the
most important is the Security Assertion Markup Language – or SAML for short. SAML provides a
cryptographically secure mechanism for communicating acts of authentication, entitlements and
attributes between security domains. It defines both the protocol and the process to enact SSO across
domains and to implement components of an overall federation strategy.
SAML includes profiles for both browser‐based (passive) and service/API‐based (active) communication
scenarios. The passive profile, in particular, is the basis of most Cloud‐based SSO solutions, such as those
offered by leading SaaS vendors Salesforce.com and Google Docs. It is also the most common SSO
solution deployed within the enterprise.
The active profiles are augmented by additional standards such as WS‐Trust and WS‐Federation. The
WS‐Trust standard defines a SOAP‐based protocol for token interaction with a Security Token Service
(STS), which can include validation and exchange of tokens, as well as trust brokerage between parties.
For example, it describes how to exchange local credentials in return for issuance of a SAML token. WS‐
Federation builds on WS‐Trust, defining typical federation scenarios and solutions for identity mapping,
augmentation, token management etc. It covers both active and passive profiles.
How Does Layer 7 Help Me to Federate SOAP Web Services? Layer 7 provides infrastructure that allows organizations to federate their Web services simply and
easily, with no changes to code. Layer 7 provides federation solutions as deployment patterns of existing
product lines, rather than single‐purpose solutions. This has the advantage that the technology can also
be applied to address general Web services security and management challenges.
Federated Identity and Single Sign‐On (SSO) Using Layer 7
© Copyright 2012 by Layer 7 Technologies, Inc. (www.layer7.com) 5
Figure 1: Layer 7's SecureSpan line covers all aspects of federation and SSO, using general Gateway solutions. Each component can work independently, with other vendor components or with other Layer 7 components.
Layer 7’s SecureSpan Gateway product line can be deployed to provide Security Token Services for a
range of clients and to provide federated access control for individual services. Layer 7 also offers
client‐side federation support using its XML VPN Client product. Each of these deployment patterns is
outlined below.
SecureSpan STS The STS is the foundation infrastructure component of any federation or SSO strategy. It provides the
ability to validate tokens or exchange tokens from one form to another (e.g. the exchange of username
and password for a SAML token).
Any Layer 7 SecureSpan Gateway can be deployed as a WS‐Trust‐compliant STS. The Gateway provides
both a native WS‐Trust endpoint for drop‐in federation solutions (described below) and a WS‐Trust
policy template that can easily be customized to meet any local integration challenges that a customer
may be faced with.
The SecureSpan Gateway STS can be used for local SSO in the enterprise and to support federation
scenarios between different organizations. Layer 7’s CloudSpan CloudConnect product (described in
detail below) is an STS deployment for connecting to Cloud SaaS applications such as Salesforce.com or
Google Docs.
Federated Identity and Single Sign‐On (SSO) Using Layer 7
© Copyright 2012 by Layer 7 Technologies, Inc. (www.layer7.com) 6
Figure 2: Layer 7's SecureSpan line supports the most common enterprise federation and SSO scenarios.
This solution is able to leverage SecureSpan’s existing identity provider framework. This offers direct
connection into most directory and Identity and Access Management (IAM) products, including:
Generic LDAP
Generic database
Microsoft Active Directory
Tivoli Access Manager
Oracle Access Manager
OpenSSO
CA/Netegrity SiteMinder
RSA ClearTrust
These connectors allow organizations to preserve investments and leverage expertise in existing IAM
infrastructure, extending it into the SSO space. The SecureSpan STS deployment acts as a minimally‐
intrusive layer over an organization’s identity stores and can leverage existing groups, roles and access
control rule sets. This is a far more cost‐effective and flexible solution than vendor‐specific STS add‐ons,
which are typically very expensive and limited in the federation scenarios they support.
Layer 7’s template‐driven approach to providing STS means token exchange can be entirely customized
to meet an organization’s federation challenges. The WS‐Trust templates constitute a script that
validates identity, interacts with identity stores and generates return tokens. It works out of the box for
common federation and SSO scenarios but can easily be augmented to meet the most demanding
specialized requirements.
This template‐based approach promotes customized identity mapping functions within the context of a
WS‐Trust transaction. For example, formulaic mappings, such as string transformations of names, can
easily be integrated within the policy and used as input into generated SAML assertions. This is
invaluable for federation challenges where naming conventions differ between security domains and
need to be reconciled at run time.
SecureSpan Gateways also have full access to directory attributes associated with identities. This allows
custom tokens to be constructed with authoritative attribute declarations — an essential feature in
Attribute‐Based Access Control (ABAC) regimes.
Federated Identity and Single Sign‐On (SSO) Using Layer 7
© Copyright 2012 by Layer 7 Technologies, Inc. (www.layer7.com) 7
SecureSpan’s WS‐Trust policy can leverage the full range of potential incoming security
tokens, including:
HTTP basic authentication
HTTP digest
SSL Client‐side certificate authentication
X.509 signatures in SOAP messages
SAML token in HTTP headers
SAML Token Profile in WS‐Security
Kerberos (Windows Integrated Authentication)
Kerberos binding to SOAP messages
WS‐Trust is not limited to SAML token issuance. The SecureSpan STS can alternatively return most of the
credential types listed above, providing absolute flexibility in complex federation scenarios.
SecureSpan Gateways for Service Protection SecureSpan Gateways can also be deployed in front of Web services servers to provide access control
for federated services. This removes the complexity of token processing, administration of trust
relationships and audit from the application and centralizes this for all services. This logical shift to a
more declarative style of security management means that dedicated security administrators can
assume responsibility to all application access control, ensuring that the security policy is consistent with
corporate requirements.
Figure 3: SecureSpan Gateways deployed to federate and protect services and APIs.
Federated Identity and Single Sign‐On (SSO) Using Layer 7
© Copyright 2012 by Layer 7 Technologies, Inc. (www.layer7.com) 8
Layer 7’s policy‐based access control system can accommodate most security token types. Also, it
integrates with existing infrastructure such as directories and IAM. The internal STS capabilities of the
Gateway can be leveraged for identity mapping functions or strict token validation.
SecureSpan Gateways additionally provide a rich trust‐management interface that simplifies
management of federated partners. This features integral CRL and OCSP support, to ensure that the
integrity of the web of trust is maintained. All cryptographic functions are FIPS‐compliant and hardware
Gateway instances feature available integration with leading Hardware Security Modules (HSMs) from
Thales and SafeNet.
Gateways can also incorporate XACML access control rules directly into policy or communicate with
remote XACML Policy Decision Points (PDPs) using the XACML protocol. Integration with other external
PDPs is possible using SAMLP and WS‐Trust protocols.
The Gateways feature very rich and configurable SAML token processing, allowing support for virtually
any federation or SSO scenario. SAML tokens can be extracted from transport headers (such as HTTP) or
isolated in SOAP messages under the WS‐Security SAML token profile standard. The Gateways support
both SAML bearer tokens protected with SSL and more sophisticated WS‐Security‐based bindings for
SAML, including holder‐of‐key and sender‐vouches‐style tokens cryptographically bound into messages.
Token evaluation is completely flexible, allowing simple access control based on trust relationship or
adoption of more sophisticated methods such as ABAC using SAML attribute assertions.
Finally, all other aspects of security supported by SecureSpan Gateways are available to ensure that
services are fully protected in one place. This includes features such as message content validation,
automated threat detection, audit, transformation, throttling, traffic shaping and content or
state‐based routing.
XML VPN Client for Federating Client Applications Layer 7’s XML VPN Client is a small‐footprint, client‐side application that helps to rapidly on‐board
clients in Web services federation scenarios. This eliminates the burden of implementing federation and
SSO functions in code, thus ensuring that federation is done right the first time.
The XML VPN client interacts with a remote SecureSpan Gateway to load the most up‐to‐date policy in
effect. It then automatically coordinates SAML security token acquisition with a local STS, buffering the
token for all transactions across the token’s lifetime and automatically inserting it into transactions
destined for a remote service.
Federated Identity and Single Sign‐On (SSO) Using Layer 7
© Copyright 2012 by Layer 7 Technologies, Inc. (www.layer7.com) 9
Figure 4: The SecureSpan XML VPN Client can federate client applications without requiring any changes to code.
The XML VPN Client integrates with local STS using the standards‐based WS‐Trust protocol. It can
integrate with either a SecureSpan‐based STS or a third‐party STS such as Microsoft’s ADFS.
The XML VPN client solution is particularly well suited to federating branch office applications and to
rapidly federating applications during organizational mergers and acquisitions.
Can Layer 7 Help Me Federate APIs? The emerging API paradigm is based on RESTful design, JSON data structures and OAuth security tokens.
Layer 7 Gateways have always supported REST‐style messaging. The policy language treats JSON as a
first‐class citizen beside XML. The OAuth toolkit provides rich OAuth integration capabilities1.
SecureSpan’s SAML capabilities are entirely applicable to SAML bearer tokens carried as transport
payload. This allows sophisticated federation models — including access control paradigms such as
ABAC — to be applied to APIs, not just SOAP endpoints.
1 OAuth support in Layer 7 SecureSpan Gateways is described in a dedicated white paper.
Federated Identity and Single Sign‐On (SSO) Using Layer 7
© Copyright 2012 by Layer 7 Technologies, Inc. (www.layer7.com) 10
Figure 5: Federating APIs using OAuth and SAML. Enforcement uses SecureSpan Gateway to enact access control policies.
SecureSpan can also be used to bridge between existing SAML SSO systems and newer OAuth‐based API
interactions. The SecureSpan policy language provides the perfect vehicle for articulating rules designed
to bridge between these two important token formats.
Can You Describe The Layer 7 Drop-in Federation Solution? Layer 7 can provide a complete, turnkey federation solution that is able to federate SOAP Web services
with no modifications to client or server code. The solution consists of:
A service‐access Gateway deployed in the enterprise, to manage secure service access
A Gateway deployed as an STS at the client site
The XML VPN Client, to coordinate token acquisition and securing of messages for the client
Federated Identity and Single Sign‐On (SSO) Using Layer 7
© Copyright 2012 by Layer 7 Technologies, Inc. (www.layer7.com) 11
This is depicted in the figure below:
Figure 6: Drop‐in federation for Web services, using Layer 7.
This solution is particularly well suited to branch deployments, where a central authority needs to drive
rapid federation of applications using local user stores.
How do I Use Layer 7 to Provide SSO to My Web Sites? Layer 7 can provide Security Token Services that allow browser‐based clients to perform SSO with
internal or partner Web applications. This deployment pattern for SecureSpan Gateways is described
above. It makes use of standards‐based SAML profiles to allow a single credential to be used once in
order to access any number of local Web sites.
The Web applications must be configured to locally perform access control based on standard SAML SSO
profiles. Most modern Web application servers can easily be configured to consume SAML tokens and
enforce trust relationships.
Federated Identity and Single Sign‐On (SSO) Using Layer 7
© Copyright 2012 by Layer 7 Technologies, Inc. (www.layer7.com) 12
Why Should I Use Layer 7 for Attribute-Based Access Control? Layer 7 SecureSpan Gateways provide an excellent solution for implementing ABAC schemes. The Layer
7 policy language can easily be configured to evaluate rules based on any combination of attributes
associated with a transaction. Attributes can be mined from SAML assertions, extracted from X.509
certificate fields or dynamically queried from directory or proprietary attribute services. Rule sets can
easily be expressed using the policy language. The Gateway also incorporates an on‐board XACML
engine, allowing attribute evaluation rules to be expressed in a standards‐based way. Additionally, the
Gateway can integrate with external, standalone XACML policy servers, using the XACML PDP query
language, as well any other PDPs that support the SAMLP protocol.
How Can Layer 7 Federate Existing LDAP or IAM Systems with Cloud-Based SaaS Services Like Salesforce.com or Google Docs? Layer 7’s CloudSpan CloudConnect Gateway includes templates that enable SSO to any Cloud‐based
SaaS applications that use SAML as a means of access. CloudConnect is deployed as an STS overlay on
the user’s existing Identity and Access Management (IAM) infrastructure, thus extending existing
identity assets into the Cloud.
Figure 7: Cloud Single Sign‐On using CloudConnect.
CloudConnect supports standardized SAML browser profiles. Because there is considerable variation
between different SaaS implementations, Layer 7 has provided SaaS SSO templates that can easily be
adapted to accommodate local differences. The rich policy language can easily be used to build custom
authorization schemes, exchange tokens or integrate with local IAM infrastructure.
Federated Identity and Single Sign‐On (SSO) Using Layer 7
© Copyright 2012 by Layer 7 Technologies, Inc. (www.layer7.com) 13
Figure 8: Administrators have full access to SaaS SSO templates, allowing simple customization to accommodate local security directives.
How Does OAuth Relate to Federation & SSO? OAuth is primarily a means of authentication and limited, delegated federation, rather than a
full‐blown federation or SSO model. It was developed as a solution to the password anti‐pattern,
a bad practice that multi‐site Web applications sometimes resorted to as a means of lightweight,
user‐driven federation.
OAuth allows a user who has separate accounts on two sites to effectively federate these for certain
functions. For example, a user of Twitter might want to post tweets on his or her Facebook wall (thus
federating the accounts). OAuth provides a means to do this without forcing the user to share
credentials between sites.
There are interesting overlaps between what can be accomplished with SAML and what can be done
with the emerging OAuth specifications (particularly the OAuth 2.0 spec). These are beyond the scope of
this white paper. At present, OAuth is mainly finding application in user‐delegated account federation
on Web sites, with an emphasis on social networking sites (largely because of the developer culture at
these organizations). In these cases, OAuth is used as the security token in API calls.
SAML appears more commonly in enterprise or Cloud‐based SaaS applications. There are some
interesting emerging approaches for exchanging SAML tokens acquired using a browser‐based profile
for OAuth tokens that can be used by APIs running within the context of a browser user agent. Layer 7
has policy templates available that implement some of these scenarios. However, this is presently very
much a moving target with little standardization between implementations.
Layer 7 provides an OAuth Toolkit, consisting of several policy assertions that constitute the building
blocks of OAuth applications. The Toolkit also includes policy templates that leverage these assertions to
provide basic OAuth functions such as distributed authorization services, user access management and
API access control.
Federated Identity and Single Sign‐On (SSO) Using Layer 7
© Copyright 2012 by Layer 7 Technologies, Inc. (www.layer7.com) 14
Figure 9: Layer 7 Gateways deployed as an OAuth Authorization Server (AS) and protecting a Resource Server (RS).
Federated Identity and Single Sign‐On (SSO) Using Layer 7
© Copyright 2012 by Layer 7 Technologies, Inc. (www.layer7.com) 15
About Layer 7 Technologies
Layer 7 Technologies helps enterprises secure and govern interactions between their organizations and the
services they use in the Cloud, across the Internet and out to mobile devices. Through its award‐winning line of
SOA Gateways, Cloud Brokers and API Proxies, Layer 7 gives enterprises the ability to control identity, data
security, SLA and visibility requirements for sharing application data and functionality across organizational
boundaries. With more than 150 customers spanning six continents, Layer 7 supports the most demanding
commercial and government organizations. Layer 7 solutions are FIPS compliant, STIG vulnerability tested and
have met Common Criteria EAL4+ security assurance.
Contact Layer 7 Technologies Layer 7 Technologies welcomes your questions, comments and general feedback.
Email: [email protected]
Web Site: www.layer7.com
Phone: (+1) 604‐681‐9377 1‐800‐681‐9377 (toll free within North America)
Fax: 604‐681‐9387
Address: Layer 7 Technologies Suite 405 – 1100 Melville Street Vancouver, BC V6E 4A6 Canada
Legal Information Copyright © 2012 by Layer 7 Technologies, Inc. (www.layer7.com). Contents confidential. All rights reserved. SecureSpan™ and Cloud Span™ are registered trademarks of Layer 7 Technologies, Inc. All other mentioned trade names and/or trademarks are the property of their respective owners.