Beyond Simple Federation

One of the typical scenarios we've encountered when discussing our federation solutions with customers includes dynamic account provisioning. A number of people at Network World in Chicago last week were asking me about this capability, so here's an overview:

Typical federation scenarios include a person attempting to access an application that lives outside of the security domain in which the person is currently authenticated. This is achieved by authenticating the user within the current security domain and passing an assertion to the requested application stating that the user is authenticated (and providing the user's identity information). This assumes that an account has been created in the foreign application for the user. The process of creating and managing accounts for this purpose is typically a manual process due to the distributed environment. Whether manual or not, the process that's in place usually kicks off whenever a new employee account is created within the originating security domain and ultimately concludes with an account being created in the external environment in a ready state - waiting for the user to come along at some later date and logon. Apparently, there are a number of possible reasons why you might not want accounts created for system users who may only potentially access an external application.

MaXware's Federation Server (MFS) is built on top of our Virtual Directory product (MVD). MVD enables account authentication to one or more heterogeneous back-end data stores. It also enables account creation to one or more heterogeneous back-end data stores. So, one of the scenarios we've implemented for a customer in the past (and will likely again sometime soon) includes on-demand federated account provisioning. In this scenario, the user is authenticated in their home environment and an assertion is sent to the external application environment. MFS on the application side leverages its internal MVD to dynamically create an account in the requested application. And to take it a step further, MFS actually opens a session on behalf of the user so that when the user is redirected to the application, there is no need to logon again. So, it also serves as a distributed SSO environment. But, that was the original point of federation, wasn't it? Pretty cool stuff. You don't have to worry about orphaned accounts if they don't get created in the first place. On-demand federated account provisioning -- the next big thing? Maybe not, but it's good to know that it's there if you need it.