About Siebel Authentication and Session Management SOAP Headers

You can use Siebel Authentication and Session Management SOAP headers to send and receive user credentials and session information. You can send a username and password for login that calls one of the following sessions:

• One that closes after the outbound response is sent.

• One that remains open after the response is sent.

For example, a custom Web application can send a request that includes a username and password, and calls a stateless session, one that remains open after the outbound response is sent. The Siebel Server generates an encrypted session token that contains user credentials and a session ID. The Siebel Server includes the session token in the SOAP header of the outbound response. The client application is responsible for capturing the returned session token and including it in the SOAP header of the next request.

The Session Manager on the Siebel Application Interface (AI) extracts the user credentials and session ID from the session token and reconnects to the session on the Siebel Server. If the original session has been closed, then a new session is created.

You can use the SOAP headers listed in the following table to call different types of sessions and pass authentication credentials.

Note: The values entered are case insensitive.

SOAP Header Block	Description
SessionType	You use the SessionType SOAP header to define the type of session. Valid values are None, Stateless, Stateful, and ServerDetermine: None. A new session is opened for each request and then closed after a response is sent out. The SessionType none might or might not include UsernameToken and PasswordText SOAP headers. When UsernameToken and PasswordText SOAP headers are included, these credentials are used for authentication. If the UsernameToken and PasswordText SOAP headers are excluded from the SOAP header, then anonymous login is assumed. The anonymous login requires additional configuration in the Application Interface profile and Named Subsystem configuration (AllowAnonymous equals (=) True, Impersonate equals (=) False). For more information about configuring anonymous login, see Siebel Security Guide. Stateless. A new session is opened for an initial request and the session remains open for subsequent requests. Relogin occurs automatically (transparent to the user) if the session is closed. UsernameToken and PasswordText must be included as SOAP headers in the initial request to open a stateless session. Stateless session management is the best method to use for high-load Web service applications. Using Stateless mode, the application provides the username and password only once, that is for the initial request. A session is opened on the server and is dedicated for this user. In the response Siebel CRM returns the session token, which is an encrypted string containing the information about username, password, and timestamp. For subsequent requests the application must use the session token to reuse the session. For security reasons, the session token is returned for each response. The application must provide the last received session token for the next request. The session token-Siebel session map is maintained in the Application Interface (AI); based on the SessionToken value, AI sends the request to the correct Siebel session (task). Although the session is persistent, authentication happens for each request (AI decrypts the UserName and Password from the session token). Stateful. A new, dedicated session is opened for an initial request and the session remains open for subsequent requests. Relogin does not occur automatically if the session is closed. UsernameToken and PasswordText must be included as SOAP headers in the initial request to open a stateful session. As with Stateless sessions, Siebel CRM returns the session token in the response. For subsequent requests the application must use the session token to reuse the session. Unlike Stateless sessions, transparent failover (automatic relogin) is not supported. This is because Stateful sessions might have state information stored that makes it mandatory to connect to the same task for each request. ServerDetermine. A new session is established to Siebel CRM, and a series of subsequent requests is served. The Siebel Server is free to multiplex the session to serve other users if possible, but the client is free to make stateful calls to Siebel CRM. Failover is not supported for this mode. ServerDetermine provides the most flexibility: the session can be dedicated or not. If the number of users increases and resources must be recovered, then the session state is written to the database so that it can be restored. The session can then serve other users. If SessionType is absent, then the default value is None, and the session will be closed after the request is processed.
UsernameToken	You use the UsernameToken SOAP header to send the login ID to the Siebel Server.
PasswordText	You use the PasswordText SOAP header to send the password used by the login ID to the Siebel Server. If using Web single sign-on (SSO), then use the Siebel trust token value in PasswordText instead of the password.
SessionToken	Session tokens are used with stateless requests. They are sent and received using the SessionToken SOAP header. After receiving an initial request with valid authentication credentials and a session type set to Stateless, the Siebel Server generates a session token and includes it in the SOAP header of the outbound response. The session token is encrypted and consists of a session ID and user credentials. The custom Web application uses the session token for subsequent requests. The Session Manager on the AI extracts a session ID and user credentials from the session token, and then passes the information to the Siebel Server. The session ID is used to reconnect to an existing session or automatically log in again if the session has been terminated. Note: Reconnecting or automatic logging in again will only happen if the token has not timed out. If it times out, then the user must manually log in again. Token timeout must be greater than or equal to session timeout. For more information on session token timeout, see Session and Session Token Timeout-Related Parameters. However, the session token must be changed to the new one sent on every response. The session token has a maximum time to live, which can invalidate it even if its timeout (for being inactive) has not been reached. Always get the newest session token returned by the response and use it on the next request. The same session token must not be used by concurrent requests, because having multiple requests point to the same session token can cause errors.

For examples of using SOAP headers for session management and authentication, see Examples of Using SOAP Headers for Siebel Authentication and Session Management.

The namespace used with Siebel Authentication and Session Management SOAP headers is:

xmlns="http://siebel.com/webservices"

Note: The Siebel Authentication and Session Management SOAP headers are different from the SOAP headers used for WS-Security. Do not use the two types of header together.