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

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