When a session routes messages to Web services, the session typically uses a set of primary credentials to identify the user. This information is stored in the Persona participant for the session. The credentials in a Persona are in a Username token, which contains a username and a password. For more information, see How to Create a Persona Participant.

Different Web services that participate in the same session might require different credentials from the same user, such as a username or password. To store the different credentials that are required for the same user in the same session, you use Secondary Credentials.

Specifying Message Credentials

The Connected Services Framework (CSF) provides access to a single sign-on (SSO) service. The SSO service enables you to store the various credentials that identify a user, and associate them with the various Web services that require these credentials. The CSF uses the username that is specified in the Persona as the key into this identity store, and retrieves the credentials for a specified service. For example, if a session, which has a Persona with a primary username of john@NorthwindTraders.com, routes a message to the ContosoWS Web service, the session can determine the credentials to apply to the message by examining the information in the identity store. The information for a specific user is referred to as a user map. This example is shown in the following figure:

 

In this example, the session retrieves the username john@Contoso.com, and the password Pa$$w0rd, and then applies them as the security credentials to the message that is sent to Contoso.com. If there are no corresponding Web service secondary credentials in the user map for the user who is identified in the Persona, the session does not send the message but records an error in the Windows Application event log. The error code 20300 is recorded with the message "Secondary credentials do not exist for either message security or transport security for Participant ({0})", where {0} is replaced by the participant name at runtime.

An administrator can maintain the  user identity information in the SSO database by using the Identity Manager. For more information, see The Identity Manager Component. When a session starts, it retrieves the identity map for the user who is specified in the Persona by calling the Identity Manager. The session then caches this information locally, to reduce the overhead of repeatedly looking up identities.

Instead of using a Persona to specify a user's  primary credentials, it is possible to specify that an application should use the credentials of the service account that runs the Session service. In this case, when looking up secondary credentials required by a Web service, the credentials of the service account are used as the key into the user map. Again, if there are no corresponding Web service secondary credentials in the identity store for the service account, the session does not send the message but records an error in the Windows Application event log instead. The error code 20300 is recorded with the message "Secondary credentials do not exist for either message security or transport security for Participant ({0})", where {0} is replaced by the participant name at runtime.

A further alternative is to indicate that the session should not actually look up any secondary credentials when sending messages to a Web service. In this case, the primary credentials specified in the Persona can be used.

A final option is to indicate that the Web service should not expect any credentials to be supplied, and in this case the session sends the message to the Web service without attaching any user credentials. Note, no user credentials are sent in this circumstance, which includes those of the anonymous user.

When you route a message to a Web service by adding a SecondaryCredentialMap object to the Web service participant, you can specify which option the session should use when it determines the secondary credentials, by using one of the following constants:

• Persona. The session looks up the credentials to attach to the message by using the identity specified in the Persona to retrieve the credentials for the Web service from the user map.
• System. The session looks up the credentials to attach to the message by using the Kerberos token of the account running the Session service to retrieve the credentials for the Web service from the user map.
• PassThrough. The session does not look up any secondary credentials, but instead uses the Username token specified in the Persona as the secondary credentials.
• None. The session does not supply any security credentials.

For more information, see How to Specify Message Credentials.

Specifying Transport Credentials

When a session sends a message to a Web service, it might also need to provide transport credentials for establishing a connection to the Web service. You can store and retrieve transport-level credentials required by a service by using a user map maintained by Identity Manager. You can indicate which transport credentials to use by specifying one of Persona, System, PassThrough, or None, as you can for message credentials. 

Additionally, a Web service can expect these transport level credentials to be different types, according to the security requirements of the Web service. You can specify one of the following options for the transport type in the SecondaryCredentialMap object for the Web service participant:

• Ntlm. The session will communicate with the Web service by using integrated Windows authentication. This is the default.
• Basic. The session will communicate with the Web service by using Basic authentication. The username and password will be sent as plain text.
• Digest. The session will communicate with the Web service by using Digest authentication. The username and password will be sent as an encrypted message digest.

For more information, see How to Specify Transport Credentials.

See Also

 

 

Copyright © 2006 Microsoft Corporation. All rights reserved.