Federated Identity and SaaS

In addition to the SaaS architecture papers, I’ve also recently published a paper on federated identity: Federated Identity: Scenarios, Architecture and Implementation.

Before taking on the job of tackling SaaS architecture guidance, identity and access management used to be my gig. Therefore, my motivation of writing this paper is to address some of the pain points that I’ve heard from my customers. The following are key topics discussed in the paper:

· business scenarios where you may want to consider using identity federation technology

· shortcomings of today’s technology for managing identity across organizations

· conceptual architecture for identity federation

· a sample implementation of the architecture using WSE 3.0

While off-the-shelf products such as Microsoft ADFS (Active Directory Federation Service) are already available for federating users of browser-based Web applications, infrastructure solution that facilitates identity federation between Web services is not yet readily available. The sample implementation serves to illustrate that with some development work, today’s Web services development tools can be used to build Web service applications that are capable of federating identities.

For those who have seen the Web services security guide, you will notice that the conceptual FI architecture is an extension to the STS Brokered Authentication Pattern and the sample implementation is a code extension to the SAML Token STS Quickstart. Although identity federation can be facilitated through any standard, agreed-upon security tokens, we have chosen to illustrate the scenarios using SAML token because it is the token format that is most frequently requested by our customers.

The information in this paper is definitely relevant to SaaS providers, especially for SaaS ISVs who have larger enterprise customers who are requiring the SaaS provider to accept identities issued and managed by the customers themselves. In addition to having a federated identity solution that speaks standard security protocols, the SaaS providers should also be prepared to negotiate and deal with trust and security policy management issues with their customers, for the reasons mentioned below.

In order for SaaS providers to accept identities issued by another party, they must be able to validate that the identity information came from a trusted entity. Thus, managing who the SaaS provider should trust becomes a necessary operational task. Other than single sign-on, identity federation solution can also help propagate security policy information maintained by the customers to the SaaS provider. For example, if the customers are already maintaining roles information for their employees, the security token issued by the customer’s federation infrastructure can contain role attributes. Subsequently, the role attributes are used by the SaaS application to determine the features that are accessible by the users of the federated customers. However, in many cases, there may not be an exact mapping between the roles that are defined within the customer’s organization and those that are already implemented in the SaaS application. Hence, the SaaS provider may also need to manage the transformation of such security policies.

Despite these caveats, federated identity is a valuable capability that will not only improve the single sign-on experience, but also add another measure of security protection to your SaaS application.

Comments

• Anonymous
  July 12, 2006
  The comment has been removed
• Anonymous
  July 18, 2006
  by Brian Reed The latest issue of Business 2.0 includes their view on the 50 People Who Matter. Somewhat surprisingly, within their Top 50 is only one pure-play company from the SaaS and On-Demand Marketplace. Mark Beinoff of SalesForce.com at...
• Anonymous
  August 02, 2006
  Approximately six months back we made a strategic decision to invest on creating architecture guidance...