SAML and Federated Identity Part 2 - Identity Management
Last time, I talked a bit about SAML and Federated Identity. It turns out this is a subset of a general area, an area commonly referred to as Identity Management. The issue is how to protect and manage credentials across a wide array of network applications that have different authentication methods and requirements. I talked about SSO last time, mostly around SSO in browsers and web applications. As Pablo reminded me, it's not just web browsers; SAML is trying to solve the problem of SSO in general so that the user can log in once for multiple applications. This is, of course, critical in Real-World services or SOA. All of this points to an effective identity management infrastructure.
The Elements of an Identity Management System
Such a solution would be made up of the following capabilities as services [1]:
- Identity Provisioning Services - Set up users easily; Provision users and roles typically in LDAP compliant sources; Policy definition and enforcement
- Identity Data Synchronization Services - This is all about synchronizing identity data across a wide range of heterogeneous apps, directories, databases and other stores
- Access Management Services - SSO access to apps and services across heterogeneous apps, Web Services and resources running on diverse platforms local or network
- Federation Services - This is one place where SAML comes in to provide a federated framework and authentication -sharing mechanism that is interoperable with existing systems
- Directory Services - Above and beyond LDAP
- Auditing and Reporting Services
Wikipedia lists some additional capabilities [4]
One such example of the above, that I have been using is CA SiteMinder, which is a centralized Web access management system that enables user authentication and single sign-on, policy-based authorization, identity federation, and auditing of access to Web applications and portals.
CA SiteMinder Web Access Manager is an example of enabling SSO via a portal, implementing a security token that is presented on each request. The portal can then use the security token to verify the user's identity across all the apps/services within it.
This is done by utilizing an intercepting agent as identified in the Intercepting Web Agent Pattern [2]. As stated, this is a specialization of the GOF Proxy Pattern "helps protecting Web based J2EE applications through a Web Agent that intercepts requests at the Web Container and provides authentication, authorization, encryption, and auditing capabilities." [3]
Intercepting Web Agent
Problem
Retrofitting authentication and authorization into an existing Web application or Service is cumbersome and costly (yah think? :))
Forces
- You do not want to or cannot modify the existing web application
- You want to completely decouple the authentication and authorization from an existing application
- You want to leverage out-of-the-box security from a reliable third-party vendor rather than try to implement your own
Solution
Use an Intercepting Web Agent to provide authentication and authorization external to the application by intercepting requests prior to the application.
The win here is that the app or service is protected by providing authentication and authorization from outside of the service instead of modifying or rewriting the code.
Participants and Responsibilities
See below
CA SOA Security Manager/CA Site Minder
An example, as I have mentioned that I am using today, with WCF Services, is CA SOA Security Manager + CA SiteMinder. So, SOA Security Manager provides a manifestation of the Intercepting Web Agent Pattern with its SOA XML Agents. These guys intercept incoming calls, check with the Policy Server for authentication/authorization, construct a SAML Assertion that is injected/inserted (based on SiteMinder protected login session) into the XML message (I should say Header), and finally pass the message onto the target Web Service. Notice, that this, and SAML, allow Web Service calls to be "chained."
Back to SAML..what do we got? We have SAML Authentication, Attribute, and Authorization Assertions as part of a WS-Security message inserted into the header.
So Now What?
So, now we need to peel out the SAML token and deal with it. That brings us into dealing with the world of Claims and Claims Based Security, the subject of Part 3. Then we'll delve into the wacky world of WS-Trust, STS's, and Federated Security.
[1] Core Security Patterns: Best Practices for J2EE, Web Services, and Identity Management, Sun/Prentice Hall, 2006
[1] Core Security Patterns: Best Practices for J2EE, Web Services, and Identity Management, Sun/Prentice Hall, 2006, Section 8.5
[3] http://www.coresecuritypatterns.com/patterns.htm
[4] http://en.wikipedia.org/wiki/Identity_management