Federated Identity & SSO Using Layer 7

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



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 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.



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.



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.



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.



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.



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.



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



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.



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.



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.



Figure 9: Layer 7 Gateways deployed as an OAuth Authorization Server (AS) and protecting a Resource Server (RS).



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.

Federated Identity & SSO Using Layer 7

Documents

Transcript of Federated Identity & SSO Using Layer 7