BackgroundOn my blog at MSDN I wrote a series of blog post to share my experiences and observations from a series of SaaS engagements with hosters and ISVs during the SaaS incubation effort that I led in Microsoft’s Innovation Center in Copenhagen. The last two scenarios where never finished before I left Microsoft to start my own business. I promised to deliver the last two, so here is one of them….
Why & who?Until now, this series of blog posts have been talking about building, hosting, delivering and monetizing SaaS solutions. The last piece is consuming the SaaS solution. In earlier posts I described the initial steps in consuming a SaaS solution – subscribing to it. This post focus on authentication and authorization while consuming SaaS applications. My old colleague and participant on the SHP incubation initiative, Kevin Sangwell from Microsoft Europe, have addressed many aspects of enterprise SaaS consumption architecture such as (integration, composition, SLA, monitoring, governance, regulatory compliance etc) in his talks.
Most (all?) existing SaaS applications require you to type in the user name and password of the first user/administrator of the SaaS application. This person can then create more user accounts, roles, permissions. This is known as “delegated administration” and allows each tenant to manage their own accounts, groups, roles etc. This is all nice and good as long as this application is the only one. The problem is that these users already have user accounts in his organization, already are assigned to groups and roles and – more importantly – are part of an identity and access lifecycle strategy and process.
Enterprises typically have processes and/or systems in place to create an account for new employees, assign to relevant groups/roles to give access to relevant systems. If the new employee is in sales and the CRM application is provided as a service, the CRM application need to either integrate with the enterprise systems or duplicate account and group/role information. If the enterprise has 100 internal applications and one new smart must-have SaaS application, it may not seem so bad, but what if the enterprise has 5 or 10 SaaS applications?
It’s easy to see that creating and maintain the user, password, group/role membership etc 5 or 10 times quickly gets cumbersome, but what is worse is termination of employment and regulatory compliance. What happens when the employment is terminated? How can the enterprise de-provision the user from 5-10 different SaaS applications hosted by different providers? And what about reporting? How can the enterprise create a report of what a given employee has access to?
How?One solution to this problem is to duplicate and synchronize the accounts, groups and roles between the enterprise and each SaaS provider. If all SaaS provides exposed this information through some service API, a directory replication or meta-directory product could help solving the issue. However, I firmly believe that federation is the best solution to this issue. Federation is based on open standards specification such as WS-Federation which is co-written by Microsoft, IBM, BEA, Novell, VeriSign etc, under standardization through OASIS and 20+ of the major organizations and platform companies have stated they will support it. Microsoft supports the first part of federation (browser based a.k.a. “passive profile”) through Active Directory Federation Services – ADFS. ADFS is available in Windows Server 2003 R2. Support for SmartClient a.k.a. “active profile” is planned for Windows Server “Longhorn”.
Without federation a user at the consuming enterprise (application tenant) would authenticate against a local directory (such as Active Directory – AD) when starting the client machine up in the morning. After authentication, the user typically has single sign-on to all internal systems. Through this authentication and local group membership, a user in sales may read internal documents about products/pricing, access inventory status, have mail & IM communications with colleagues to plan an upcoming campaign. However, as soon as the employee tries to access customer & order information from the SaaS CRM application a new logon is required. Then, when the employee wants to write a news nugget about the campaign and update product/price information on the corporate web site through the SaaS CMS application, a third logon is required. Now imagine an employee in HR, using HR as a Service, trying to terminate the employment of this sales person – how many logons will the employee in HR have and how do the account copies of the sales person get de-provisioned?
Image 1: Conceptual sequence diagram for one consumer of three applications on same or different SHPs without federation – no SSO!
With federation, the accounts only exist once in an account domain. In the enterprise scenario this could be in SaaS consumers AD. The resources, in this case the SaaS application, exist in a resource domain at the SaaS provider. Both the SaaS consumer and the SaaS provider expose a federation server. These servers could be Windows Server 2003 R2 servers with ADFS or any other sever OS/platform that implements the open federation standards. Once the federation servers are in place, a “federation trust” is established between the consumer and provider. This is a one-time set-up that involves describing resources, describing claims and exchange of certificate public keys. This process can be automated through the APIs described in the AFDS SDK.
Once the federation trust is established, the consumer can issue a claim, sign the claim with its private key and pass the claim to the provider. Claims can be confusing in the beginning, but it’s a beautiful concept. The consumer can claim anything and the provider of the resource would accept the claim since it’s signed by someone the provider trust. If the provider is as an analyst web site that have signed an agreement that all the consumer employees can access their reports, the claim from the consumer could simply be that the user indeed is an a employee. The provider wouldn’t need any name, user name, group membership or password to accept the claim and give access to the analyst reports. In order to greet the user and track who is downloading reports, a user name would be useful, but I bring up this example to show that a claim doesn’t have to include a name and definitely not a password.
In the example of CRM as a service, the claim could be that the user calling the CRM SaaS application is named John Doe, is an employee of the consumer, is a sales manager and is allowed to approve orders up to $50k. Then when John tries to use the HR as Service, his federation server could pass a claim to the HR a service provider that John is a full time employee in the Danish subsidiary. Finally when John tries to use update the corporate web site through the CMS a Service, his federation server could pass a claim to the CMS a service provider that John member is a content editor.
The SaaS application provider can use the claim to authenticate the user as well as to provide access to certain functions of the application based on the content of the claim.
Image 2: Conceptual sequence (in reality there’s a lot of redirects going on and there are federation servers involved) diagram for SSO between a consumer and two applications on different SHPs that both trust the consumer’s claims
So what happens when John loses his password? A normal password reset of his local account is enough – no SaaS providers need to know this ever happened.
What happens with the SaaS applications when the consumer decides to implement SmartCard logon? Nothing – the claim sent to the SaaS providers are unchanged.
What happens when John leaves the company to go to a competitor and need to be locked out of the on-premise intranet and extranet applications and all SaaS application from all SaaS providers – simply delete or disable his local account which stops the federation sever from issuing anymore claims about John.
So from the enterprise perspective I think the benefit of federation is clear. It should also be clear for SaaS providers that thinking of identity as islands in each application is not acceptable for the consumers and SaaS providers must provide support for federation in the SaaS Hosting Platform – SHP.
During the SHP Proof of Concept we configured federation using ADFS, included support for the SaaS provider to describe support for federation in the platform manifest, provided support for trust setup in the application tenant provisioning sequence, provided support for the ISV to describe the support for federation in the application manifest and finally we made the SiteCore CMS application “claims aware”. See Lars Nielsen’s (solutions architect at Sitecore) blog post about this here.
Ok, enough about the enterprise SaaS consumers. They have their IT department, their internal directory and could set up federation trust with their SaaS providers. But what about the small business SaaS consumers and the private SaaS consumers? A carpenter working alone or a 5 person company signing up for three applications from different ISVs sold through a single aggregator/store-front in a small business plan would not be willing or capable to set up federation. However, the consumer would not expect to create three accounts for each user and log on three times to access the applications. For these scenarios, federation and ADFS also support a configuration (Federated Web SSO) where the SaaS provider has both the account and the resource domain as in the illustration below:
Image 3: Conceptual sequence (in reality there’s a lot of redirects going on and there are federation servers involved) diagram for SSO between two applications on the same SHP where the SHP provides the directory
See the ADFS design guide for details and more information.
Remember Me