Thursday, April 17, 2008

SecureAuth® Authentication and SAML 2.0 Federated Architectures

"SecureAuth® - An Ideal Authentication Solution for the Authentication of SAML 2.0 Federated Architectures."

By Garret Grajek
COO, MultiFactor Corp.

Now that SAML 2.0 Federation is becoming a more common place consideration on how to trust an identity across an intranet and extranet, especially with the introduction of Google Apps - the question is how to authenticate the user for this federation?

There is much confusion in this space - not only on how to federate - but on how to conduct the authentication. For example, some experts on the subject feel that a secure federation should be done by setting up X.509 PKI trust across the federated sites. (Authentication, PKI and SAML by Anil John)

Though Anil made several excellent comments in his blog, including this comment:

"...I consider authorization to be separate and distinct from the authentication."

At MultiFactor we agree strongly with this principal and have sought out and successfully implemented solutions to enterprises, both in the network and application arena, where MultiFactor SecureAuth provides the identity to the enterprise and lets the enterprise authorize the user according to the established roles and permissions.

But there is one aspect which where we disagree with Anil's post. In Anil's article he implies that if a relying party wants to enjoy the security benefits of a PKI, it should install its own PKI accepting infrastructure, namely be able to accept C-SSL certificates.

At MultiFactor we feel that PKI is very compatible to SAML and should be seen as integral component to a secure SAML federated model - not as a replacement. As long as the PKI is done in a easy to deploy manner and used to establish the identity of the user. (See Diagram #1)

Diagram #1 - SecureAuth® integrated into a SAML 2.0 Architecture
(click to enlarge)

This is exactly what MultiFactor has executed in its Google Apps integrations.

In this scenario, a site host MultiFactor SecureAuth® authentication and the original identities to become a trusted IdP (Identity Party) and the Google Apps site is the SP(Service Provider). The authentication is conducting by MultiFactor SecureAuth® with a valid X.509 authentication occurring. (MultiFactor has many patents-pending on the uniqueness of the ability to deploy via WebServices the necessary PKI infrastructure and distribute the X.509 certificates to end users - but for that's for another discussion. See: Diagram #2)

Diagram #2 - SecureAuth® Simplifies X.509 Delivery into a SAML 2.0 Federated Architecture (click to enlarge)

What is germane here is that a valid bi-lateral, X.509 authentication is conducted by an IdP (Identity Party) that is hosting the identities and SecureAuth® for authentication. The IdP in turn, creates a SAML 2.0 assertion which is trusted by the Relying Party - and thus the end user achieves a secure log-on into the target application.

In this model - only the IdP needs to have a trusted PKI "infrstructure" - ideally an easy to deploy SecureAuth® authentication module.

Thus, it is MultiFactor's believe that SAML and PKI (if PKI is deployed simply and manageably via SecureAuth®) are compatible and in fact inseparable in a trusted, scalable, federated environment.

--
Garret Grajek is the COO and a co-founder of MultiFactor Corporation. He is a certified security engineer who has deployed 100s of security solutions while working for RSA, IBM, Cisco and others.


1 comment:

aniltj said...

Garret... I very agree with you that one of the benefits of using a SAML 2.0 architecture for Federated Identity is that the the task of AuthN is at the IdP and you can pass an AuthN assertion to the SP.

My point in my blog entry was not that this was a "bad" alternative or that PKI enabling the SP was a "good" alternative, as much as calling out that there are some communities, usually ones who have extensive PKI infrastructures already in place, that will not allow a remote entity (i.e. an IdP) to vouch for the identity of a subject.

In addition, I was making a point that the reason for this often is not technical as much as an issue of trust. i.e. An SP org may not have visibility into the user vetting and credential issuance policies of the IdP and as such may not trust the assertion.



Copyright 2008. MultiFactor Corporation. All Rights Reserved.