Enterprise Single Sign-On

A business process that relies on several different applications probably needs to deal with several different security domains. Accessing an application on a Windows system might require one set of security credentials, while accessing an application on an IBM mainframe might require different credentials. To address this challenge, BizTalk Server 2004 includes Enterprise Single Sign-On (SSO).

Enterprise Single Sign-On provides a way to map a Windows user ID to non-Windows user credentials. This service can make things simpler for business processes that use applications on diverse systems.

To use SSO, you define affiliate applications, each of which represents a non-Windows system or application. An affiliate application might be a CICS application running on an IBM mainframe, an SAP ERP system running on Unix, or any other kind of software. Each of these applications has its own mechanism for authentication, and so each requires its own unique credentials.

SSO uses a Credential database to store encrypted mappings between users' Windows user IDs and their credentials for one or more affiliate applications. When a user needs to access an affiliate application, an SSO server can look up that user's credentials for that application in the Credential database. The following figure shows how this works.

In this example, a message sent by some application to BizTalk Server 2004 is processed by an orchestration, and then sent to an affiliate application running on an IBM mainframe. The job of Enterprise Single Sign-On is to make sure that the correct credentials (for example, the right user name and password) are sent with the message when it is passed to the affiliate application.

The figure illustrates a five-step process:

1. When a receive adapter gets a message, the adapter can request an SSO ticket from SSO server A. This encrypted ticket contains the Windows identity of the user who made the request and a time-out period. After it is acquired, the SSO ticket is added as a property to the incoming message. The message then takes its normal path through the BizTalk Server 2004 engine, which in this example means being handled by an orchestration. When this orchestration generates an outgoing message, that message also contains the SSO ticket acquired earlier.
2. This new message is destined for the application running on an IBM mainframe, and so it must contain the appropriate credentials for this user to access that application. To get these credentials, the send adapter contacts SSO server B, supplying the message (which contains the SSO ticket) that it just received and the name of the affiliate application for which it wants to retrieve the credentials.
3. This operation, called redemption, causes SSO server B to verify the SSO ticket, and then look up this user's credentials for that affiliate application.
4. SSO Server B returns those credentials to the send adapter.
5. The send adapter uses the credentials to send an appropriately authenticated message to the affiliate application.

This example shows what is likely to be a typical use of Enterprise Single Sign-On, but this is not the only option. A smaller BizTalk Server 2004 installation might have only a single SSO server, for example.

SSO also includes administration tools to perform various operations, such as the following:

• Monitor operations performed on the Credential database and set various audit levels
• Disable a particular affiliate application
• Turn on and off an individual mapping for a user

There is also a client utility that enables end users to configure their own credentials and mappings.

Like other parts of BizTalk Server 2004, Enterprise Single Sign-On exposes its services through a programmable API. The creators of third-party BizTalk Server adapters use this API to access the Single Sign-On services, and you can also use it to create scripts for automating common tasks.

See Also

Using Enterprise Single Sign-On