Integration Platform Technologies: Siebel Enterprise Application Integration > Web Services >

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 Web Server Extension (SWSE) 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 Table 11 to call different types of sessions and pass authentication credentials:

NOTE:  The values entered are case insensitive.

Table 11. Siebel Session Management and Authentication SOAP Headers
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 Siebel Web Engine (eapps.cfg) 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 Business Applications return the SessionToken, which is an encrypted string containing the information about username, password, and timestamp. For subsequent requests the application must use the SessionToken to reuse the session.

    For security reasons SessionTokens are regenerated for each response. The application must provide the last received SessionToken for the next request.

    The SessionToken-Siebel session map is maintained in the Siebel Web Server Extension (SWSE); based on the SessionToken value SWSE sends the request to the correct Siebel session (task).

    Although the session is persistent, authentication happens for each request (SWSE decrypts the UserName and Password from the SessionToken).

SessionType

  • 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 Business Applications return the SessionToken in the response. For subsequent requests the application must use the SessionToken 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, 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. 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 contains a session ID and user credentials. The custom Web application uses the session token for subsequent requests. The Session Manager on the SWSE 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 can cause errors.

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

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

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

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

Integration Platform Technologies: Siebel Enterprise Application Integration Copyright © 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices.