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

Security scenarios -- Part 1

Sxip covers certain security scenarios well.

1. There is a user who has been authenticated inside MyCompany's corporate domain who wishes to access a web site hosted elsewhere on the Internet without any more challenges. Authentication at the remote web site unfolds silently against the Corporate Directory by way of Sxip. Authorization at the remote web site might be based on user attributes stored in the Company Directory and passed by SAML. This is the local user/centralized authorization/remote web site scenario with a single sign-on solution.


2. There is a user that belongs to MyCompany who is remote and wants to access a remote web site. Authorization decisions are based on user attributes maintained by the remote web site (e.g. roles). The user logs in with a username specific to the application and the password from her Windows account. This is not single sign-on in fact because at a second remote web site the user is required to log in again. In this scenario the authorization decision point is the remote web site, not the Corporate Directory. This is the remote user/decentralized authorization/remote web site scenario with a single password solution.

These are the two scenarios Sxip Access for ASPs seems to address. These two scenarios begin to define a grid. Let's consider the grid.

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

Note 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.

In the grid User Affiliation can also take OtherCompany. Also in the grid the App Location can be an Extranet.

Stay tuned. There is definitely more to come.

Technorati Tags: 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

Identity Management and On-demand Software

TheCompany is both a producer and a consumer of on-demand software.

Identity management with on-demand software is challenging.

There are a number of scenarios:

1. TheCompany is the Application Service Provider (ASP). A client requires Single Sign-on (SSO) for users already authenticated in the client's domain.


2. TheCompany is the consumer of an on-demand web app hosted elsewhere. TheCompany requires that access to the on-demand web app be limited to a subset of its corporate users.


3. TheCompany is at once the producer and consumer: it has deployed on its "extranet" a web app that should only be accessed by a subset of corporate users.

Centralized user management needs to be part of the solution because the proliferation of user data stores would make rapid provisioning and de-provisioning of users very challenging. Also centralized user management potentially enables the "paper trail" needed for regulatory compliance with, for example, SOX or HIPAA.

One solution for all three scenarios is delegated authentication that integrates with the Corporate Directory (LDAP).

With delegated authentication there is an identity provider -- sxip in our picture. The on-demand app redirects the user to the identity provider, and the identity provider authenticates the user with the Corporate Directory. SAML is used to pass authentication and, if needed, authorization information between the identity provider and the service provider.

This is a Single Sign-on solution.

Sxip sells a product called Sxip Access for ASPs which is a delegated, single sign-on with SAML authentication solution.

Currently SAML delegated authentication solutions are more mature and more secure than OpenID delegated authentication solutions. However, in the future the possibility of a convergence between OpenID and SAML is growing.

Technorati Tags: OpenID, SAML

Simple Registration Extension

MyOpenID.com now supports the Simple Registration OpenID Extension. Indeed, MyOpenID.com supports what might be called an extension to the extension -- personas.

Each persona can hold the full set of attributes. The user gets to choose which persona to present to the application.

It does appear that the DotNet OpenID Library can retrieve Simple Registration information from the host by way of classes in the consumer module that engage the host in a request for attributes and parse the host's response.

Note that the DotNet OpenID Library is a port of the Python OpenID Library. The DotNet OpenID Library in turn has a dependency called Mono.Security.dll -- a library built and distributed freely by the Mono Project.

Technorati Tags: OpenID

Jennifer's OpenID Sequence Diagram

There are a series of redirects. Depending on whether or not a site is trusted by the user, a user may or may not be prompted to authorize the passing of credentials and optionally an attribute exchange (via the the simple registration extension) between the site and the OpenID Server.

These redirects are visualized in Jennifer's sequence diagram.

A good narrative to go with the diagram can be found in the overview of the Python OpenID Library consumer module.

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