Security scenarios -- Part 2

Let's consider another scenario that may be of some interest.

User Location	User Affiliation	Identity Store	Access Policy Store	App Location	Solution
Local and Remote	MyCompany	Corporate Directory Mixed Mode	ASP Store	Extranet	Single sign-on with SAML aka Token Authentication Single sign-on with Corporate Password aka Delegated Authentication (Sxip Access for ASPs)

This is the scenario where MyCompany hosts a web application at its "secure Extranet" and the users are MyCompany employees some of whom are logged into the Corporate Directory and other who are not.

(Recall that "Mixed Mode" is a situation where authentication goes against the ASP store with username, the Corporate Directory with the password and only succeeds if the username in the Corporate Directory and the ASP store can be harmonized).

Notice that the Access Policy Store is the application for both local and remote users. That's because at MyCompany the Windows groups in which an employee participates might have no relationship to the roles the employee has at a particular web site. Consequently LDAP might not be a suitable access control policy store and the job falls to the application.

Let's consider a variation of this scenario in which both MyCompany employees and OtherCompany employees are users of the application. Now MyCompany users are local and OtherCompany users are remote.

User Location	User Affiliation	Identity Store	Access Policy Store	App Location	Solution
Local and Remote	MyCompany and OtherCompany	Corporate Directory CardSpace Identity Provider	ASP Store	Extranet	Single sign-on with SAML aka Token Authentication (Sxip Access for ASPs) CardSpace

This is going to take some explaining...

Leaving aside the implementation, the issues here are complicated. An alternative solution might have been to authenticate OtherCompany users from the application data store. The trouble with this approach is that OtherCompany would be put in the position of maintaining the consistency of two data stores -- its Corporate Directory and the ASP store.

The OtherCompany could also deploy Sxip hardware but let's assume that they won't.

How does CardSpace change this equation? Or, put another way, what is the difference between an OtherCompany employee with administrative rights managing users at the application and an OtherCompany hosting a CardSpace identity provider?

The answer is centralized administration across all applications as opposed to a decentralized approach in which the OtherCompany is trying to maintain many data stores distributed over many ASPs. Note that with CardSpace you don't get automatic provisioning and de-provisioning of users. It is kind of a poor person's Sxip Identity Provider in this context.

Note that in this discussion CardSpace might be a placeholder for OpenID or vice versa. OpenID will have to figure out how to support a more open-ended set of user attributes the way CardSpace does with SAML. Note that skip identity already offers a product called WhoBar which integrates with a web app and makes it capable of supporting a choice of emerging identity protocols including CardSpace and OpenID.

Technorati Tags: CardSpace, OpenID, SAML, sxip identity