1 Raindrop

Assertion Federation Assurance

Ping is set to demo its new Infocard authentication + federated SSO at Catalyst.

A user authenticates to a healthcare portal leveraging a self-asserted InfoCard. The user’s credentials are validated by a Java InfoCard Server built by Ping Identity. PingFederate is then used to enable federated single sign-on to a remote Web site without a redundant user authentication.

There are a number of interesting aspects here including proving out Identity Law 5, which is, of course, Pluralism of Technologies and Operators, jacking InfoCards assertion into the federation network through the WS-Trust backplane, and the ability of InfoCards to help to strengthen the authentication process, for example through a smart card and then have that assertion carried through the system, Brian Snow:

Consider the use of smartcards, smart badges, or other critical functions. Although more costly than software, when properly implemented the assurance gain is great. The form factor is not as important as the existence of an isolated processor and address space for assured operations - an "Island of Security" if you will.

An island of security in a networked world, now there is a future worth inventing.

Web Services and XML Security Training at OWASP Europe (Belgium)

I will be teaching a one day course on Web Services and XML Security at the OWASP Europe conference. I enjoy the OWASP conferences, there is a good mix of security folks, developers, and architects, plus it is vendor neutral, many different industries are represented, and usually in a nice location.

The focus areas of my class are:

• Web Services attack patterns
  
• Common XML attack patterns
  
• Data and XML security using WS-Security, SAML, XML Encryption and XML Digital Signature
  
• Identity services and federation with SAML and Liberty
  
• Hardening Web Services servers
  
• Input validation for Web Services
  
• Integrating Web Services securely with backend resources and applications using WS-Trust
  
• Secure Exception handling in Web Services
  

The class explores standard secure coding and application security issues and looks at new risks and countermeasures that are present in Web Services, SOA, and XML paradigms.

Service Oriented Security Architecture

My paper on Service Oriented Security Architecture from the Nov. issue of ISB is now online. The paper describes an approach to dealing security design and architecture issues in developing Web Services and SOA software.

The primary goals are to illustrate a set of key analytical areas, and a way to synthesize these relationships. As Kruchten and others observed separation of concerns is an useful technique in software architecture. In security architecture, it is useful as well, and in addition separation of assets yields a more robust risk management model. In the case of this paper, the assets are separated as Identity, Message, Service, Deployment Environment, and Transaction. This way the risks and countermeasures can be understood and the elements and constraints dealt with in their own domain to the extent possible.

SAML 2.0 Federated Identity Standards Convergence

Patrick Harding articulates what SAML 2.0 may mean to the industry:

Until this year, identity federation has suffered from the problem of too many standards. Companies that deployed federation before the fourth quarter were forced to deal with five incompatible protocols: OASIS Security Assertion Markup Language 1.0 and 1.1, Liberty Alliance ID-FF 1.1 and 1.2 and Shibboleth. The result was a complex matrix of enterprise and consumer use cases, protocols and implementations that slowed the growth and increased the cost of federation deployments.

The Organization for the Advancement of Structured Information Standards (OASIS), the Liberty Alliance and Shibboleth have since joined forces to create a single standard that would make their previous work obsolete. The result is SAML 2.0, which OASIS ratified in March and is beginning to appear in vendor products. SAML 2.0 radically alters the federation landscape by removing the largest barrier to increased federation adoption: multiprotocol complexity.
...

SAML 2.0 incorporates every critical-use case and feature from every predecessor protocol into a single standard. As it represents a superset of all the functionality in all five predecessors, SAML 2.0 makes them obsolete.

                                    

SAML 2.0 describes two roles for enabling federation; the service provider is the entity that makes an application or resource available to the user, while the identity provider is responsible for authenticating the user. The service provider and the identity provider exchange messages to enable single sign-on and single log-out. These message exchanges can be initiated by the identity provider or the service provider.

                                    

For single sign-on, the identity provider is responsible for creating a SAML assertion that contains the identity of a user and then securely sends that assertion to the service provider. The service provider is responsible for validating the SAML assertion before letting the user access the application.

Since the whole point of federation is to port identity information across domains and render it usefully, convergence of the myriad of standards is a welcome development.

Future of Databases

Grady Booch blogs a paraphrase of an exchange with Bruce Lindsay on the future of databases:

Database management systems will have to support ACID SOA calls. Applications will exploit multiple data repositories. Careful attention to authentication and security will be needed. Distributed two-phase commit will be avoided by recoverable messaging to applications (via services) that consult and modify the database and send a recoverable reply. Database size will become a non-issue. We'll see lots of low-latency asynchronous replication of reference data among databases serving various applications and their associated service interfaces. It's unclear how documents will integrate with database management systems: there may be a content manager inbetween. Finally, XML will probably not replace all other document formats. Files will not disappear from application implementations.

He does not mention federation specifically, but it would seem that given all of these moving parts - XML, files, databses, apps, and so on that federation is a natural fit to communicate security information and provide part of the security solution Bruce is advocating for.

Scaling Federation in 06

Andre's blog also contains another entry on Federation in 06, starting with Burton Group's take:

Long term, federation isn’t a separate product

Federation standards already seeping into many product classes: Firewalls, gateways, application servers, and IdM products

Federation likely won’t be point-to-point like SSL; various tiers of the infrastructure will act on claims as necessary

Systems need to federate, but that doesn’t necessitate an uber-federation system

Then he pulls in Ping's CTO, Patrick Harding, in an email excerpt in which Patrick points out the limitations of scaling federation without some shared infrastructure on a separate layer. Drawings of two options below:

Federation everywhere

Federation with a separate federation layer

I have described the need to separate an Identity Abstraction layer in the BuildSecurityIn paper on Identity in Assembly and Integration, Patrick points out that a system that lacks a separate federation system is analogous to having all systems run their own PKI (scary, I know). Patrick describes the positive impact that this separation can have on scalability of the federated identity system. There are many other gains such as simplifying the developer's experience through abstraction of the back end resources and technologies, interoperability, and pluggability. Lastly, the separate fedaration layer supports the 5th Law of Identity: Pluralism of Operators and Technologies which states:

So when it comes to digital identity, it is not only a matter of having identity providers run by different parties (including individuals themselves), but of having identity systems that offer different (and potentially contradictory) features.

A universal system must embrace differentiation, while recognizing that each of us is simultaneously—and in different contexts—a citizen, an employee, a customer, and a virtual persona.

Abstraction is about the best tool we have in programming, it is nice that in 2005 we are actually using it for identity.

Andre Durand Interview on Federation

In this interview, Ping Identity CEO/Founder, Andre Durand discusses the recent Trustgenix acquisition, the state of Federated idenity (are we still waiting for the big bang?), and the ideas behind starting Ping.

The next five years might be characterized by the entire ID management stack becoming standardized, where the interfaces between everything are standards. What's interesting about all of this is while you have a tightly integrated, proprietary suite from the vendors on the one hand, which is very self-serving, on the other hand, you have almost the opposite thing happening: a modular, loosely-coupled stack with standards in between.

With this, companies can pick and choose best-of-breed authentication and tie it to best-of-breed policy, where all of the vendor products are interoperable. Therein lies the big, long-term opportunity for Ping because we started at the beginning of this modularization.