Federated Identity and Single Sign-On using CA API Gateway

WHITE PAPER DECEMBER 2014 Federated Identity and Single Sign-On using Federation for websites, Web services, APIs and the Cloud K. Scott Morrison VP Engineering and Chief Architect

2 WHITE PAPER: FEDERATED IDENTITY AND SINGLE SIGN-ON (SSO) USING CA TECHNOLOGIES ca.com Table of Contents Why do I need to federate identity? 3 Is federation the same as single sign-on (SSO)? 3 What standards address federated identity and SSO? 4 How does CA Technologies help me to federate SOAP Web Services? 5 STS 5 for Service Protection 7 XML VPN for Federating Applications 9 Can help me federate APIs? 10 Can you describe drop-in federation solution? 11 How do I use to provide single sign-on to my websites? 12 Why should I use for attribute-based access control? 12 How can federate existing LDAP and IAM systems with cloud-based SaaS services like Salesforce.com and Google Docs? 12 How does OAuth relate to federation and SSO? 14

3 WHITE PAPER: FEDERATED IDENTITY AND SINGLE SIGN-ON (SSO) USING CA TECHNOLOGIES ca.com 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. CA 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.

4 WHITE PAPER: FEDERATED IDENTITY AND SINGLE SIGN-ON (SSO) USING CA TECHNOLOGIES ca.com 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 and 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.

5 WHITE PAPER: FEDERATED IDENTITY AND SINGLE SIGN-ON (SSO) USING CA TECHNOLOGIES ca.com How does CA Technologies help me to federate SOAP Web Services? CA Technologies provides infrastructure that allows organizations to federate their Web services simply and easily, with no changes to code. CA Technologies 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: covers all aspects of federation and SSO, using general gateway solutions. Each component can work independently, with other vendor components or with other CA API Gateway components. For Federation and Single Sign-On (SSO) Directory STS XML VPN Services Service Gateway can be deployed to provide Security Token Services for a range of clients and to provide federated access control for individual services. also offers client-side federation support using its XML VPN product. Each of these deployment patterns is outlined below. 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 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. STS can be used for local SSO in the enterprise and to support federation scenarios between different organizations. Cloud Integration with (described in detail below) is an STS deployment for connecting to SaaS applications such as Salesforce.com or Google Docs.

6 WHITE PAPER: FEDERATED IDENTITY AND SINGLE SIGN-ON (SSO) USING CA TECHNOLOGIES ca.com Figure 2: line supports the most common enterprise federation and SSO scenarios. STS Scenario #1: Internal Enterprise SSO Securely connect enterprises applications: Leverage existing IAM infrastructure May identities Track and monitor usage STS Scenario #2: Enterprise-to-Enterprise Federation Securely connect two enterprises: Leverage existing IAM infrastructure May domains Adapt tokens Track and monitor usage Applications Applications Existing IAM Enterprise Enterprise B STS Existing IAM Application Enterprise A STS This solution is able to leverage the 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 Single Sign-On (formerly CA SiteMinder) RSA ClearTrust These connectors allow organizations to preserve investments and leverage expertise in existing IAM infrastructure, extending it into the SSO space. STS deployment acts as a minimallyintrusive 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. includes a 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.

7 WHITE PAPER: FEDERATED IDENTITY AND SINGLE SIGN-ON (SSO) USING CA TECHNOLOGIES ca.com 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. also provides 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. The WS-Trust policy in policy can leverage the full range of potential incoming security tokens, including: HTTP basic authentication HTTP digest SSL -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. STS can alternatively return most of the credential types listed above, providing absolute flexibility in complex federation scenarios. for Service Protection 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.

8 WHITE PAPER: FEDERATED IDENTITY AND SINGLE SIGN-ON (SSO) USING CA TECHNOLOGIES ca.com Figure 3: deployed to federate and protect services and APIs. Service Gateway Protect Services and APIs: Evaluate tokens against trust relationships Broad token support Manage trust Audit all usage Web Service Server Federated Message with Security Token Administer The policy-based access control system in 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. additionally provides 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. 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. features 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. It supports 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 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.

9 WHITE PAPER: FEDERATED IDENTITY AND SINGLE SIGN-ON (SSO) USING CA TECHNOLOGIES ca.com XML VPN for Federating Applications XML VPN 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 interacts with a remote a remote 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. The XML VPN integrates with local STS using the standards-based WS-Trust protocol. It can integrate with either a either a STS or a third-party STS such as Microsoft s ADFS. Figure 4: The XML VPN can federate client applications without requiring any changes to code. Rapid -Side Federation Using the XML VPN Securely connect enterprises applications: Leverage existing IAM infrastructure Automatically aquite and use tokens Automatically secure messages according to policy Track and monitor usage Web Service Endpoints CA API Gateway Enterprise A Local STS XML VPN Standalone Federated Web Service Endpoint Application Remote Branch of Enterprise A

10 WHITE PAPER: FEDERATED IDENTITY AND SINGLE SIGN-ON (SSO) USING CA TECHNOLOGIES ca.com The XML VPN solution is particularly well suited to federating branch office applications and to rapidly federating applications during organizational mergers and acquisitions. Can help me federate APIs? The emerging API paradigm is based on RESTful design, JSON data structures and OAuth security tokens. has always supported REST-style messaging. The policy language treats JSON as a firstclass citizen beside XML. The OAuth toolkit provides rich OAuth integration capabilities 1. The SAML capabilities in 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. can also be used to bridge between existing SAML SSO systems and newer OAuth-based API interactions. policy language provides the perfect vehicle for articulating rules designed to bridge between these two important token formats. Figure 5: Federating APIs using OAuth and SAML enforcement uses CA API Gateway to enact access control policies. API Federation -side Federation without code: Leverage existing IAM infrastructure Automatically aquite and use tokens Automatically secure messages according to policy Track and monitor usage API Servers Mobile OAuth Gateway Enterprise A Message bearer SAML token in transport header, protected by SSL JavaScript App Mashup Web App

11 WHITE PAPER: FEDERATED IDENTITY AND SINGLE SIGN-ON (SSO) USING CA TECHNOLOGIES ca.com Can you describe drop-in federation solution? 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, 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 CA API Gateway Drop-In Federation Using Complete federation solution without code: Leverage existing IAM infrastructure Automatically aquite and use tokens Automatically secure messages according to policy Track and monitor usage Applications CA API Gateway Enterprise A CA API Gateway STS XML VPN Application Remote Branch of Enterprise A

12 WHITE PAPER: FEDERATED IDENTITY AND SINGLE SIGN-ON (SSO) USING CA TECHNOLOGIES ca.com How do I use to provide single sign-on to my websites? can provide Security Token Services that allow browser-based clients to perform SSO with internal or partner Web applications. This deployment pattern for 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 for attribute-based access control? provides an excellent solution for implementing ABAC schemes. 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 federate existing LDAP and IAM systems with cloud-based SaaS services like Salesforce.com and Google Docs? Cloud integration with includes templates that enable SSO to any cloud-based SaaS applications that use SAML as a means of access. It 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.

13 WHITE PAPER: FEDERATED IDENTITY AND SINGLE SIGN-ON (SSO) USING CA TECHNOLOGIES ca.com Figure 7: Cloud Single Sign-On using STS Scenario #3: SaaS Cloud SSO Securely connect to the cloud: Leverage existing IAM infrastructure Track usage Existing IAM STS Enterprise supports standardized SAML browser profiles. Because there is considerable variation between different SaaS implementations, 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.

14 WHITE PAPER: FEDERATED IDENTITY AND SINGLE SIGN-ON (SSO) USING CA TECHNOLOGIES ca.com Figure 8: Administrators have full access to SaaS SSO templates, allowing simple customization to accommodate local How does OAuth relate to federation and 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. has policy templates available that implement some of these scenarios. However, this is presently very much a moving target with little standardization between implementations. 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.

15 WHITE PAPER: FEDERATED IDENTITY AND SINGLE SIGN-ON (SSO) USING CA TECHNOLOGIES Figure 9: s deployed as an OAuth Authorization Server (AS) and protecting a Resource Server (RS) Enterprise OAuth Using Authorization Server (AS) Enterprise Resources Owner (RO) The AS and RS functions can be combined into a single gateway, or distributed across the network. Resources Server (RS) Learn more at ca.com/api Connect with CA Technologies at ca.com CA Technologies (NASDAQ: CA) creates software that fuels transformation for companies and enables them to seize the opportunities of the application economy. Software is at the heart of every business, in every industry. From planning to development to management and security, CA is working with companies worldwide to change the way we live, transact and communicate across mobile, private and public cloud, distributed and mainframe environments. Learn more at ca.com. 1 OAuth support in is described in a dedicated white paper. Copyright 2014 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies. This document is for your informational purposes only and to the extent permitted by applicable law, CA provides it as is without warranty of any kind, including, without limitation, any implied warranties of merchantability, fitness for a particular purpose, or noninfringement. The information in this document is based upon CA s experiences with the referenced software products in a variety of development and customer environments. Past performance of the software products in such development and customer environments is not indicative of the future performance of such software products in identical, similar or different environments. In no event will CA be liable for any loss or damage, direct or indirect, from the use of this document, including, without limitation, lost profits, business interruption, goodwill or lost data, even if CA is expressly advised in advance of the possibility of such damages. CS200_87497_1214