Tuesday, May 23

Identity Management for SOA

From my soon-to-be-released MaXware whitepaper titled Identity Management in a Service Oriented Architecture:

As companies continue to deploy identity management solutions throughout 2006 and 2007, they should do so with an eye toward their enterprise SOA strategy. Organizations that implement identity management solutions will benefit most over the long term when IdM solutions are offered as a service. Companies are beginning to move toward Service Oriented Architecture models and adoption is already gaining momentum. IdM will be a critical component of SOA infrastructure securing service access to applications as well as access to the services themselves. Applications will be looking to access identity data throughout the organization over standard service protocols like DSML and SPML. MaXware is uniquely positioned to meet the current and future needs of organizations looking to build, manage and secure an SOA infrastructure.

There is certainly a significant amount of hype about SOA, but that doesn't necessarily mean that it's only hype. SOA done right has the potential to greatly reduce application integration costs, which has been an albatross for many large organizations. I expect a gradual adoption over the next few years as software vendors provide SOA hooks into their software. I don't really see companies rolling out enterprise-wide SOA infrastructure, but as more apps become service oriented, communication between platforms will become much easier to facilitate. Organizations will obviously need to consider security for the SOA infrastructure but they should also expect that Identity Management solutions (provisioning systems, identity data stores, etc) should be available as a service over standard protocols. If you're interested in the whitepaper, check our web site -- it should be available within the next few days.

Monday, May 8

SAML for Secure SOA

I've been researching Service Oriented Architecture (SOA) and came across this article on the JavaWorld site - Secure your SOA.

from the article:
"In the past, most systems were designed under the assumptions that a single system would posses all of the information necessary to make access control decisions and all the data would be recorded in the audit trail. However, large-scale distributed systems are always built by multiple organizations with a mixture of products. Thus, users may be authenticated by different authorities using different methods. In addition, different authorities retain different information about user properties and attributes. Centralizing all capabilities and information is just not practical. SAML provides standard formats to express authentication and user attributes, and the protocols to request and receive. "

With regard to service-enablement for our customers, I've been primarily focused on the ability of our Virtual Directory to enable service-based access (DSML, SPML, other) to identity data in practically any back-end format. I see this as very cool technology. Simple, but effective.

This article lays out another concept I've been thinking about, which is IdM as providing security for the SOA environment itself. That is, playing its role in locking down access to and from the services themselves. I've seen a number of articles and analyst reports that expect SOA deployments to take off throughout 2006 and 2007. Even if companies aren't ready to transform their entire infrastructure to an SOA, we can expect some degree of adoption within most large organizations.

An efficient and flexible Identity Management infrastructure is going to be critical in securing access to the SOA services themselves and their access to other systems and applications. Our Federation Server, using SAML, is an ideal candidate for enabling a secure SOA environment.

The scenario would look like this:
  1. Application-A (portal) requests data from Application-B (HR System).

  2. Federation Server authenticates Application-A and generates a SAML assertion.

  3. Application-A forwards the assertion to Application-B, which verifies the assertion and grants or denies access to its resources based on the information in the assertion.

The scenario would work the same if it were a user attempting to access an application instead of an application-to-application interface. Or potentially, in a portal scenario, the portal requesting access on behalf of the user with multiple layers of trust. Interesting stuff.

The next step might be to add-on a provisioning environment that captures audit data on service access rights for SOA governance. I'd be curious to hear how people are implementing SOA governance. Would traditional user-provisioning systems fit the bill?