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

SAML everywhere?

A couple of pictures from Paul Madsen's December 17th, 2006 ConnectID blog entry are most definitely worth many thousands of my words.



Madsen views the second picture as "more speculative" perhaps because it entails somehow transporting a SAML XML fragment through a query string in place of the pieces of an OpenID 1.0 Simple Registration Extension persona.

Certainly this calls to mind that aphorism about a camel passing through the eye of a needle. Of course, that was before Fortran took us all to the moon (and beyond) relying exclusively on a method of parameter passing called pass-by-reference.


Note that Liberty Alliance is a working group that promotes the federation architecture where a user might store identity information with several identity providers that might also be web sites. These sites have an agreement to share identity information.

At this point we probably need a score card to keep track of everything. Not everything under the sun. But everything under Identity 2.0. Fortunately, such a score card seems to exist. See also the reference to Identity 2.0 in Wikipedia.

Technorati Tags: Identity 2.0, Liberty Alliance, OpenID, SAML

OpenID NOW!

There are a number of pieces -- moving parts. Some are core. Some are not depending on what we might want OpenID to do.

Let's say there are three scenarios:

1. We want to build a .NET 2 application that authenticates with OpenID.


2. In this application we want to control which OpenIDs will be accepted. We might only want to accept OpenIDs from a subset of our employees or from this subset and a subset of employees at another organization, etc.


3. In our application we will want to retrieve attributes of the user's profile to guide .NET 2 authorization.

Today perhaps all three scenarios can be implemented. The first is leading edge. The second and third are bleeding edge.

The first scenario requires that:

the user has an account at an OpenID Server and

class libraries are available for .NET 2 to use to interact with the OpenID server.

In fact, I just set up an OpenID account with Verisign's Personal Identity Provider. As far as a library goes to enable interaction between a .NET 2 app and an OpenID Server goes, see the C# library at OpenID Enabled.

The second scenario can be implemented in a couple of ways. One approach is to use a dedicated OpenID Server. We could host it or have someone else host it. See Host your own OpenID server.

The second way to implement the second scenario uses attribute exchange. Attribute exchange is part of the OpenID 1.0 Simple Registration Extension. It enables an application with the permission of the user to access user attributes that are part of the user's profile stored at the OpenID Server. Currently, some OpenID servers support attribute exchange. Others do not. As an aside, attribute exchange is the path OpenID will grow if it is to compare favorably with CardSpace (Microsoft).

Finally, with regard to our last scenario, OpenID support for .NET 2 authorization and role-based access to pages also depends on attribute exchange.

If you want the skinny on OpenID, CardSpace and attribute exchange see a recent post at Kim Cameron's Weblog.

Technorati Tags: CardSpace, OpenID