Identity Management with Connected Services Framework

Connected Services Framework
Two excellent and succinct definitions of identity management are:

"Identity management is the set of business processes, and a supporting infrastructure for the creation, maintenance, and use of digital identities"

- The Burton Group

"Identity Management is the process and technology used to manage digital identities as well as the policies that govern how the identities can be used to access IT resources"

- A Microsoft Architect


Single Sign-on

In the context of Connected Services Framework, single sign-on (SSO) refers to the experience of an end-user who is provided access to resources across various domains (administrative and identity provider domains) without the need to explicitly provide a credential every time.

There are number of ways to provide this experience.

  • Password Synchronization Usually effective across similar identity provider domains with very similar policies governing the identities in those domains. This is a very crude and architecturally messy method of providing single sign-on. This methodology is often used in legacy environments such as Windows NT domains.
  • Web SSO A single universal identity provider is publicly available to all domains. You can provide a single sign-on experience to users when you use this identity provider. The best example of this form of single sign-on is Microsoft® Passport. This methodology is moving toward a more federated model. For example, the next version of Passport will provide a form of federation with other providers such as Liberty Alliance.
  • Enterprise SSO A single sign-on solution, such as those provided by Netegrity, Oblix or RSA, where a common identity provider is used across the enterprise. The enterprise SSO can also be achieved by using only one identity mechanism, such as Active Directory® on the Microsoft corpnet.
  • Identity Mapping (also called the Pseudonym service in the WS-Security specifications) A pseudonym service facilitates single sign-on when multiple identities must be automatically mapped and the privacy of the identity must be maintained. This service allows a user to have different aliases at different resources and services or in different realms. It also allows an optional pseudonym change per service or per logon. In the absence of federation, this is the most common way of providing the single sign-on experience within a distributed environment such as CSF.
  • Identity Federation This is the goal. This solution defines mechanisms that allow different security realms to federate (that is, join in a league or similar association) by allowing and brokering trust of identities, attributes, and authentication between participating Web services. Federation within CSF will be based on the WS-Security set of specifications, specifically WS-Federation and WS-Trust.


Identity Management and CSF Identity Manager


To facilitate SSO where multiple identities must be automatically mapped and the privacy of the identities must be maintained, there may also be a pseudonym service. A pseudonym service allows a user to have different aliases at different resources and services or in different realms, and to optionally have the pseudonym change per service or per logon.

CSF Identity Manager is the pseudonym service introduced in the Single Sign-on Identity Mapping bullet. Identity Manager contains a WSE interface to Active Directory and Microsoft® BizTalk® Single Sign-on (SSO).

Connected Services Framework achieves identity mapping in the following manner.

The Identity Manager component provides identity services for users and organizations. It also provides identity mapping between CSF and the Web services that use CSF.

The Identity Manager component initially consisted of five endpoints:

  • UserManager
  • OrganizationManager
  • UserGroupManager
  • UserMapManager
  • UserMapQueryManager

A single combined endpoint, Identity Manager, now aggregates all Identity Manager calls in Connected Services Framework 2.5. The IdentityManagerClient is designed to send requests to any of these endpoints. The target endpoint is specified when the request is passed in to the client in the MessageContext class. We recommend that you use the new aggregate endpoint.