1. Security Guide
  2. What's New in This Release

6Single Sign-On Authentication

Supported Single Sign-On Solutions for Siebel Deployment

Siebel supports three types of HTTP access through which Siebel-provided services and data can be accessed: interactive user interfaces, Web services, and REST API.

Siebel deployment supports the following single sign-on (SSO) solutions:

  1. Web Single Sign-On (Web SSO). This solution includes the following use case:

  2. Federated Single Sign-On with Security Assertion Markup Language (SAML). In this solution, the user’s single authentication token is trusted across multiple applications. For more information, see About Implementing Federated Single Sign-On. This solution includes the following use cases:

    Note: These use cases use Oracle Access Manager (OAM) and Oracle Access Gateway (OAG) for demonstration purposes only. Any equivalent solution from other vendors can also be used.
Note: Siebel Open UI provides standards-based Single Sign-On (Web SSO and SAML based). Windows Integrated Authentication (WIA) is not supported.

About Web Single Sign-On

In a Web SSO implementation, users are authenticated by a third-party authentication system at the Web-site level. Siebel Business Applications do not provide Web SSO authentication capabilities; they do, however, support this mode of authentication by providing an interface that allows a third-party Web SSO system to pass user information to a Siebel application. Once authenticated by the third party, a user does not have to explicitly log into the Siebel application.

Web SSO authentication does not apply to the Siebel Mobile Web Client. When connecting to the local database using Siebel Mobile Web Client, mobile users must use local database authentication. For a particular Siebel application, when users connect from the Siebel Developer Web Client to the server database, the authentication mechanism must be the same as that used for Siebel Web Client users. For information about authentication options for local database synchronization for mobile users, see Siebel Remote and Replication Manager Administration Guide.

Web SSO allows you to deploy Siebel Business Applications into existing Web sites or portals. Web SSO architecture is appropriate for Web sites on which only approved registered users can gain access to sensitive data, such as a Web site on which you share data with your channel partners.

If you are using Oracle’s Siebel CRM Desktop applications, then you can implement CRM Desktop Single Sign-On. CRM Desktop SSO allows you to implement Single Sign-On for the CRM Desktop client, and can be customized to support your existing Web Single Sign-On implementation. For information, see Siebel CRM Desktop for IBM Lotus Notes Administration Guide and Siebel CRM Desktop for Microsoft Outlook Administration Guide.

Web Single Sign-On Limitations

In Web SSO deployments, user authentication and user management are the responsibility of the third-party security infrastructure. As a result, certain capabilities are not available, as Siebel Business Applications features, in a Web SSO environment.

In a Web SSO environment, the following features are not available:

  • User self-registration

  • Delegated administration of users

  • Login forms

  • Logout links or the Log Out menu item in the File application-level menu

  • Change password feature (in Profile view of User Preferences screen)

  • Anonymous browsing

Access to Siebel administration and configuration views is also not available with an Application Object Manager configured for Web SSO authentication.

Verify that functionality you require does not rely on the capabilities in the previous list before you attempt to deploy such functionality in a Web SSO environment. For example, the Siebel eSales - Checkout Process workflow and user registration both make use of login forms.

Your Siebel Business Applications might require configuration changes to hide the capabilities in the previous list. For information on hiding or disabling the capabilities listed, see Configuring Siebel Business Applications. For information about logging out of a Web SSO environment, see Logging Out of a Siebel Application.

Web Single Sign-On and Silent Login

Silent login is typically not supported in Web SSO deployments where you want to start Siebel from an external application and both Siebel and the external application have different SSO credentials. In this case, there must be a Siebel session open for the external application to work with Siebel in SSO mode. However, if Siebel and the external application are both configured with the same SSO credentials, then silent login is supported and you will be able to start Siebel from the external application without being prompted for login credentials.

About Implementing Web Single Sign-On

To provide user access to Siebel Business Applications on a Web site implementing Web SSO, the authentication system must be able to provide the following to Siebel Business Applications:

  • Verification that the user has been authenticated

  • A user credential that can be passed to the directory, from which the user’s Siebel user ID and database account can be retrieved

In a Web SSO environment, you must provide your authentication service and any required components, such as an authentication client component.

Web Single Sign-On Implementation Considerations

The following are some implementation considerations for a Web SSO strategy:

  • Users are authenticated independently of Siebel Business Applications, such as through a third-party authentication service or through the Web server.

  • You must synchronize users in the authentication system and users in the Siebel database at the Web site level.

  • You must configure user administration functionality, such as self-registration, at the Web site level.

  • A delegated administrator can add users to the Siebel database, but not to the authentication system.

  • Siebel Business Applications support the standards-based Web SSO solutions that meet the requirements listed in Requirements for Standards-Based Web Single Sign-On.

Note: Implement Web SSO in a development environment before deploying it in a production environment.

Web Single Sign-On Options

You can implement the following options in a Web SSO environment that uses a Siebel-compliant security adapter:

  • User specification source. You must specify the source from which the Siebel Web Engine derives the user’s identity key: a Web server environment variable or an HTTP request header variable.

  • In addition, many options identified in Security Adapter Deployment Options can be implemented for Web SSO.

Related Topic

Requirements for Standards-Based Web Single Sign-On

Web Single Sign-On Authentication Process

The following image illustrates the user authentication process in a Web SSO environment.


Web Single Sign-On Authentication Process: In this image, Siebel Client is labelled (A), SSO Solution is labelled (B), Siebel Web Server/Siebel Application Interface is labelled (C), Siebel Server (Application Object Manager) is labelled (D), Siebel Security Adapter is labelled (E), LDAP Directory Credentials is labelled (F), and Siebel Database is labelled (G). There is a bi-directional arrow going from A to C, C to B, B to F, F to E, E to D, D to G, and D to C.

The steps in the Web SSO authentication process are as follows:

  1. A user attempts to access the Siebel client (A).

  2. The SSO authentication service (B) intercepts the user request and determines if the Siebel resource is protected.

    • If the resource is protected, the SSO authentication service checks for the user's session cookie.

    • If a valid session does not exist, the user is prompted to enter a username and password.

  3. The user enters credentials at the client that are passed to the Web server (C).

  4. The third-party authentication client on the Web server (C) passes the user credentials to the third-party authentication service (B).

  5. The authentication service (B) verifies the user credentials, sets an HTTP header variable that maps to the Siebel user ID, and passes the authenticated user’s user name in the header variable to the Siebel Application Interface on the Web server (C).

    Note: For LDAP standards-based Web SSO, a header variable must be used.

  6. The Siebel Application Interface (C) passes the authenticated user’s user name and the value for the Trust Token parameter to the security adapter (E). The user name can be the Siebel user ID or another attribute.

  7. The security adapter (E) provides the authenticated user’s user name to a directory (F), from which the user’s Siebel user ID, a database account, and, optionally, roles are returned to the security adapter.

    In addition, the security adapter (E) compares the Trust Token value provided in the request with the value stored in the Application Object Manager’s configuration file (D). If the values match, then the Application Object Manager accepts that the request has come from the Siebel Application Interface; that is, from a trusted Web server (C).

  8. The Application Object Manager (D) uses the returned credentials to retrieve the user’s data based on their roles and visibility (G).

    If the user is not authorized, the user is denied access and redirected to another URL as determined by the organization's administrator.

Related Topic

About Web Single Sign-On

Requirements for Standards-Based Web Single Sign-On

In this guide, the term standards-based Web SSO refers to Web SSO systems that support the LDAP standards described in this topic. This topic outlines the requirements for integrating Siebel CRM with a standards-based Web SSO system.

To integrate a standards-based Web SSO authentication system with Siebel Business Applications, the following are the minimum requirements that must be met:

  • The Web SSO authentication system can send the identity of each Siebel user to be authenticated in an HTTP header variable using HTTP1.1 standard W3C HTTP 1.1 RFC-2616+.

    In a standards-based Web SSO implementation, the Siebel Application Interface derives the user’s user name from the HTTP request header variable. The recommended method is to use a header variable populated with an attribute value that is stored in the directory.

  • Siebel Web Single Sign-On is configured for the Siebel Application Interface.

  • The Siebel LDAP security adapter is implemented to provide authentication functionality.

  • The Web SSO authentication system uses a static trust token in the HTTP header.

  • The Web SSO authentication system supports the following:

    • LDAP 3.0 standard based on compliance with IETF LDAP RFC 2256 and later

    • IEFT Password Policy for LDAP Directories (09)

  • In Siebel Application Interface configuration, the fully qualified domain name and the port number for the application interface host are specified. For additional information, see Siebel System Administration Guide.

Set up Tasks for Standards-Based Web Single Sign-On

This topic describes the tasks that must be completed for a standards-based Web SSO authentication solution so that it can integrate with Siebel CRM. For detailed information on configuring your authentication service, see the vendor documentation.

To set up the third-party Web SSO authentication service, you must perform the following tasks:

  • Install all the components required for the Web SSO authentication service as detailed by the vendor.

  • Synchronize the time on all servers hosting the Siebel application and the Web SSO authentication service.

  • Configure the authentication service to map an SSO header variable uid to the Siebel uid directory attribute.

    The Header variable set in the Web SSO policy must be equal to the value of the User Specification parameter in the Siebel Application Interface profile. In the following example, the uid is mapped to the SSO_SIEBEL_USER HTTP header variable: 

    Type: HeaderVar 
Name: SSO_SIEBEL_USER 
Attribute: uid

  • Grant access to resources that are protected by the policy domain to all Siebel users.

  • Remove default no-cache HTTP pragma header fields for your Web SSO solution. No cache should be created by Web SSO.

  • The following parameters must be set in the Siebel Application Interface profile:

    • Configure Web Single Sign-On must be set to TRUE to implement SSO.

    • Trust Token must be set to HELLO, or another contiguous string of your choice.

      In SSO mode when used with a custom security adapter, the specified value is passed as the password parameter to a custom security adapter if the value corresponds to the value of the Trust Token parameter defined for the custom security adapter.

      Note: Typically, password encryption applies to Siebel Application Interface configuration. In this case, you must specify the encrypted value. For more information, see Encrypted Passwords in Siebel Application Interface Profile Configuration.

    • User Specification must be set to, for example, OAM_REMOTE_USER.

      Note: OAM_REMOTE_USER is the header which carries the Siebel ID set by the SSO process.

Configuring the Session Timeout

You can configure an expiration period for a Siebel session by setting a session timeout value in both Siebel Business Applications and many Web SSO authentication service providers. The timeout values must be the same for both applications. If you configure a timeout value for your Siebel application that is shorter than the one you configure for your Web SSO authentication service, users can re-establish their Siebel session after it times out without providing login credentials.

The procedures in this topic describe how to configure the session timeout. To make sure that users must re-authenticate after the timeout limit is reached, you must also configure the same timeout value for your Web SSO authentication service. For information on the Siebel Active Session Timeout Value (in seconds) parameter, see About the Active Session Timeout Value Parameter.

Configuring the Session Timeout

To configure the session timeout for your Siebel application and for the Web SSO authentication service, perform the steps in the following procedure.

To configure the session timeout

  1. To configure the session timeout for the Siebel application:

    1. Navigate to the application interface configuration located in the AI_ROOT\BIN directory.

    2. Set the value of the Active Session Timeout Value parameter as required.

    3. Restart the Siebel Web server.

  2. To configure the session timeout for the Web SSO authentication service, follow your Web SSO vendor's procedure for setting session timeout values. Specify the following values:

    1. Change the value of the Maximum user session time (seconds) field.

      Set this value to be just longer than the session timeout value you specified for the Siebel application.

    2. Change the value of the Idle session time (seconds) field.

      Set this value to be the same as the value you set for the Siebel application.

Testing the Web Single Sign-On Session Timeout Configuration

After configuring the session timeout values for your Siebel application and Web SSO authentication service, verify that the session timeout values work correctly by performing the steps in the following procedure.

To test the Web SSO session timeout configuration

  1. Configure the Web SSO session timeout to be five minutes and restart the Web servers.

  2. Open a Web browser and access the Web server's main page (http://hostname).

    The main page is displayed; user authentication should not be required.

  3. Access the Siebel URL for the Web server from the same browser used in the previous step.

    Basic authentication should be required.

  4. Enter valid Siebel user credentials.

    The Siebel application should be displayed.

  5. Leave the browser window open and idle for more than five minutes.

  6. Refresh the browser window using the Refresh button.

    You should be prompted to enter user credentials.

  7. Enter valid Siebel user credentials.

    The Siebel application should be displayed.

  8. Repeat steps 2 through 5 of this procedure for the Web server you have implemented.

For information about Federated or Security Assertion Markup Language-based SSO, see About Implementing Federated Single Sign-On.

Configuring Siebel CRM and Oracle Business Intelligence Enterprise Edition for Web Single Sign-On

Siebel CRM and Oracle Business Intelligence Enterprise Edition must be set up to use the same Web SSO and authentication server. Oracle Business Intelligence Enterprise Edition does not require credentials.

The Symbolic URL arguments that are required are shown in the following table.

Argument Name

Argument Required?

Argument Type

Argument Value

Append As Argument?

Sequence

Comment

IFrameLogin:Cmd

Y

Constant

Login

Y

1

None

Cmd

Y

Constant

Answers

Y

2

This argument indicates to display the Answers tool page in Oracle Business Intelligence Enterprise Edition.

PostRequest

Y

Command

PostRequest

Y

3

None

Style

Y

Command

IFramestyle="height: 768px; width: 1024px;"

Y

4

This argument is for determining the size of the iframe in Siebel Open UI.

For more information about configuring Symbolic URL, see the section about integrating external content in Siebel Portal Framework Guide. For more information about Oracle Business Intelligence Enterprise Edition, see the relevant documentation on Oracle Technology Network.

Configuring Siebel Migration Application for Web Single Sign-On

Siebel Migration supports header based SSO and SAML assertion based SSO authentication. Several parameters must be configured in Siebel Management Console for Siebel Migration application to use Web SSO, SSO with SAML, or basic authentication. The required parameters are described in the following table. For more information about creating and deploying a Siebel Migration profile, see the Siebel Installation Guide for the operating system you are using.

Setting in Siebel Management Console

Section (Under Create Profile)

Comment or Description

Host Name

Database Information

Specify the host name for the database. Siebel Migration application uses this host name to establish the database connection. For example:

Host Name = <database_hostname>.FQDN

Port Number

Database Information

Specify the port number of the database.

Authentication Type

Authentication

Specify the authentication type for the Siebel Migration application. Specify one of the following:

  • Basic Authentication

  • Single Sign-On

Authentication Host

Authentication

Specify the Siebel authentication host for authenticating the Siebel Migration application user. Siebel Migration application uses this URI to authenticate users when they log in to the application. The value will be the REST URI of the Siebel application. For example:

Authentication Host = https://<ApplicationInterface_hostname>.FQDN:<AI_https_port>

User Specification

Authentication

This option appears if you selected Single Sign-On Authentication.

Provide the user specification for SSO authentication.

Note: This is the name of the http header which carries the identity for header based SSO. If you need only header based authentication, then set the appropriate value in this field. If you need SAML assertion based SSO, then set a dummy value in this field.

Assertion Specification

Authentication

This option appears if you selected Single Sign-On Authentication.

Provide the assertion specification for SSO authentication.

Note: This is the name of the http header, which carries the SAML assertion, when SAML based SSO is configured.

Identity Provider Logoff URL

Authentication

This option appears if you selected Single Sign-On Authentication.

Provide the identity provider logoff URL for SSO authentication.

Note: This is the Identity Provider Logoff URL that will be invoked when the user logs off from the application.

Parameter Name for Identity Provider Logoff Return URL

Authentication

This option appears if you selected Single Sign-On Authentication.

Provide the parameter name for the identity provider logoff return URL for SSO authentication.

Note: This is the Siebel Migration URL to navigate to, after logout.

Siebel Application Name for Data Administration

Other Information

Specify the Siebel application name that needs to be embedded in the Siebel Migration application.

Language

Other Information

Specify the language of the Siebel application that needs to be embedded in the Siebel Migration application.

Web Single Sign-On Authentication Process When Using Siebel REST and Web Services in Portal Application

The figures in this topic show the typical steps in a Web SSO authentication process when Siebel REST and Web Services are invoked by a server that is part of a portal application. The process uses Oracle WebLogic server with Oracle Access Manager and Oracle API Gateway for illustrative purposes, but you can use any other Web application server with a SAML (Security Assertion Markup Language) identity provider solution and a Service Provider Gateway.

There are three parts in the Web SSO authentication process, which is shown in the following figures:

  • SSO authentication process, see Steps 1 through 9.

  • REST invocation process, see Steps 10 through 18.

  • SSO logout process, see Steps 19 through 24.

The following image shows the Web SSO authentication process when using Siebel REST and Web Services in a portal application.

Web SSO Authentication Process When Using Siebel REST and Web Services in Portal Application: This image is described in the surrounding text.

The steps in the Web SSO authentication process shown in this image (using Oracle WebLogic server with Oracle Access Manager and Oracle API Gateway for illustrative purposes) are:

  1. GET/Access protected Siebel Portal. A non-authenticated user requests access to a protected Siebel Web Portal.

  2. Redirect to Login page. There is no OAMAuthn cookie, so the user is redirected to the login page.

  3. Enter credentials and submit login form. The user enters their credentials and submits the login form.

  4. Validate credentials in IDStore. Oracle Access Manager validates the user credentials in the IDStore (Oracle LDAP or Oracle Unified Directory installed with Identity Store).

  5. IDStore responds success. The IDStore returns success to Oracle Access Manager.

  6. Respond with OAMAuthnCookie. Oracle Access Manager forwards the OAMAuthnCookie to Oracle Webgate.

  7. Set OAMAuthnCookie and redirect to Portal. Oracle Webgate sets the OAMAuthnCookie and redirects the user to the portal.

  8. Portal Home page. The user accesses the portal home page.

  9. There is no step 9 in the Web SSO authentication process shown in the figures in this topic.

  10. Click on QUOTE link that points to REST service. The user initiates the REST invocation process by clicking the QUOTE link, which points to the REST service.

  11. Validate authorization for QUOTE link URI. Oracle Webgate invokes Oracle Access Manager to validate authorization for the QUOTE link URI.

  12. Return SAML assertion. Oracle Access Manager returns SAML assertion to Oracle Webgate.

  13. Send original URL and SAML assertion to Oracle WebLogic Server. Oracle Webgate sends the original URL and SAML assertion to the servlets hosted in the Oracle WebLogic server.

  14. Send SAML assertion with URI. Oracle WebLogic server sends the URL with SAML assertion to the Oracle API Gateway.

  15. Validate SAML assertion. Oracle API Gateway validates SAML assertion, extracts the user ID, sets the user ID in the request header, and sends a REST call with the user ID header.

  16. Return result. Siebel REST returns the result to the Oracle API Gateway.

  17. Return result. Oracle API Gateway returns the result to the Oracle WebLogic server.

  18. Return generated HTML page. Oracle WebLogic server returns the generated HTML page to the portal.

  19. Display generated HTML page. Siebel Web portal displays the generated HTML page to the user.

  20. Click Logout to terminate Siebel session The user clicks Logout to terminate the Siebel session.

  21. Trigger Oracle Access Manager logout URL. Siebel Web Portal invokes the Oracle Access Manager logout URL.

  22. Oracle Access Manager triggers logout URL to terminate the cookie and session. Oracle Webgate invokes the Oracle Access Manager Logout URL to terminate the cookie and the session.

  23. Oracle Webgate redirects to final logout page. Oracle Access Manager redirects Oracle Webgate to the final logout page.

  24. User lands on logout page. The user lands on the logout page.

For more information about each step in this process, consult the supporting documentation for Oracle WebLogic, Oracle Access Manager, and Oracle API Gateway. For information about using OAuth with Siebel REST, see Siebel REST API Guide.

About Implementing Federated Single Sign-On

Note: This topic discusses what is required to integrate Siebel with an external Web SSO solution. This topic applies to Siebel 17.x, 18.x, and later releases.

Browser based applications are suited to using single sign-on (SSO) authentication, which is cookie based. All configurations related to SSO (SSO cookie or Security Assertion Markup Language (SAML) token) must be performed outside Siebel. Siebel expects SSO authentication to be performed before the request reaches Siebel and looks at the HTTP request header injection for the subject. The Identity Provider (IdP) vendor must review this functional requirement. For SAML deployments, note that Siebel does not currently have a SAML validator or Assertion Consumer Service built into the product.

For customer use cases where multiple applications are federated in one SSO solution, the IdP, which acts as a service provider, validates the user credentials and passes SAML assertion to Siebel. If the request is directly sent to Siebel with a SAML token, Siebel currently does not have any way to validate it internally. This is required when Siebel has a SAML assertion consumer service by default.

The SAML solution vendor can provide the external service provider or the service provider can be procured from open source solutions (for example: custom servlet). The implemented solution can use an external gateway to validate the SAML token/ID token/access token, and relay the request to Siebel (when successful) with the subject (part of the token) set in the request header. Solutions similar to this rely on the IdP and the use case that is to be implemented.

An example of an open source SAML authentication module, which can be implemented by customers, is the mod_auth_mellon module. This module provides the service provider and authentication function when used with Apache HTTPD. The mod_auth_mellon module is available only for Linux. For non-Linux platforms, such as Windows, the module must be compiled. The mod_auth_mellon module authenticates users against a SAML 2.0 IdP solution and grants access to directories depending on the attributes received from the IdP. For more information about the mod_auth_mellon module, see https://www.keycloak.org/docs/4.8/securing_apps/index.html#_mod_auth_mellon and https://github.com/Uninett/mod_auth_mellon.

Note: The mod_auth_mellon module is not supported by Oracle.

Federated Single Sign-On Authentication Process for Interactive User Interfaces

The following image shows the user authentication process in a federated environment for interactive user interfaces. The process uses Oracle Access Manager (identity management solution) and Oracle Webgate (gateway) for illustrative purposes, but you can use any identity management solution and gateway.


Example Federated Single Sign-On Authentication Process: This image is described in the surrounding text.

The steps in the federated SSO authentication process shown in this image (using Oracle Access Manager and Oracle Webgate for illustrative purposes) are:

  1. A non-authenticated user requests a Siebel interactive UI protected by Oracle Webgate.

  2. Oracle Webgate intercepts the request and redirects the user to Oracle Access Manager for authentication.

  3. The user enters their credentials, Oracle Access Manager determines whether the federation SSO should occur and invokes the federation engine to create a SAML AuthN request.

    Oracle Access Manager redirects the user to the tenant's identity provider (IdP) with the SAML AuthN request.

  4. The tenant's IdP processes the SAML AuthN request and authenticates the user if required.

  5. The user's IdP creates an assertion containing the user data and session data, and redirects the user with an assertion to Oracle Access Manager.

  6. Oracle Access Manager invokes the federation engine to validate the assertion and map it to a local user record. Oracle Access Manager creates a local session for the user, performs authorization policy evaluation and redirects the user to the protected resource.

  7. If the user is authorized by Oracle Access Manager, then Oracle Webgate grants access to the protected resource.

About Configuring Interactive User Interfaces for Federated Single Sign-On

The following prerequisites are required on the Siebel side before configuring identity federation. You must install and set up the components to suit your own business needs. Consult the supporting documentation of your chosen components (for example, Oracle Access Manager and Oracle API Gateway) for more information.

  • Siebel Object Manager configured for SSO.

  • The following parameters must be set in the Siebel Application Interface profile:

    • Configure Web Single Sign-On must be set to TRUE to implement SSO.

    • Trust Token must be set to HELLO, or another contiguous string of your choice.

      In SSO mode when used with a custom security adapter, the specified value is passed as the password parameter to a custom security adapter if the value corresponds to the value of the Trust Token parameter defined for the custom security adapter.

      Note: Typically, password encryption applies to Siebel Application Interface configuration. In this case, you must specify the encrypted value. For more information, see Encrypted Passwords in Siebel Application Interface Profile Configuration.

    • User Specification must be set to, for example, OAM_REMOTE_USER.

      Note: OAM_REMOTE_USER is the header which carries the Siebel ID set by the SSO process.

Identity Provider-Initiated Single Sign-On Authentication Process

The following images show the typical steps in an identity provider-initiated SSO authentication process where the portal application, which links to Siebel REST and Web services, acts as the identity provider (IdP) and initiates the federation. The process uses Oracle WebLogic server with Oracle Access Manager and Oracle API Gateway for illustrative purposes, but any Web application server with a SAML identity provider solution and a gateway for the service provider can be used.

Note: For Siebel REST, you can use any identity provider (IdP) or gateway solution from any vendor. For more information, see Siebel REST API Guide.

The following image shows an identity provider-initiated SSO authentication process.

Identity Provider-Initiated Single Sign-On Authentication Process: This image is described in the surrounding text.

The typical steps in the IdP-initiated SSO authentication process shown in this image (using Oracle WebLogic server with Oracle Access Manager and Oracle API Gateway for illustrative purposes) are:

  1. GET/Access protected Customer Portal. A non-authenticated user requests access to a protected Customer Web Portal.

  2. Redirect to Login page. There is no OAMAuthn cookie, so the user is redirected to the login page.

  3. Enter credentials and submit login form. The user enters their credentials and submits the login form.

  4. Validate credentials in IDStore. Oracle Access Manager validates the user credentials in the IDStore (Oracle LDAP or Oracle Unified Directory installed with Identity Store).

  5. IDStore responds success. The IDStore returns success to Oracle Access Manager.

  6. Respond with OAMAuthnCookie. Oracle Access Manager responds with the OAMAuthnCookie to Oracle Webgate.

  7. Set OAMAuthnCookie and redirect to portal. Oracle Webgate sets the OAMAuthnCookie and redirects the user to the portal.

  8. Land on portal index.html page. The user lands on the portal’s index.html page.

  9. index.html loads IdP initiated Federation. The index.html page loads the IdP-initiated federation.

  10. Post SAML assertion with returnurl. Oracle Access Manager posts SAML assertion with returnurl.

  11. Lookup user from the SAML attribute. Oracle Access Manager checks with Oracle LDAP to look up the user from the SAML attribute.

  12. Return success. Oracle LDAP returns success.

  13. Set OAMAuthnCookie. Oracle Access Manager sets the OAMAuthnCookie.

  14. Redirect to portal landing page. The user is redirected to the portal landing page.

  15. Click on QUOTE link within iFrame that points to REST service. The user initiates the REST invocation process by clicking the QUOTE link, which points to the REST service.

  16. Validate authorization for QUOTE link URI. Oracle Webgate validates authorization for the QUOTE link URI.

  17. Validates OAMAuthnCookie. Oracle Webgate validates OAMAuthnCookie and sends the information on to Oracle Access Manager.

  18. Authorized and returns OAM SAML assertion. Oracle Access Manager authorizes and returns OAMSAML assertion to Oracle Webgate.

  19. Send REST request and SAML to WLS Servlet. Oracle Webgate sends the REST request and SAML to the Oracle WebLogic server.

  20. Send SAML assertion with URI. Oracle WebLogic server sends the SAML assertion with URI to the Oracle API Gateway.

  21. Validate SAML, extracts username, sends REST with call header. Oracle API Gateway validates SAML, extracts the user name, and sends a REST call with the header to Siebel REST.

  22. Return result. Siebel REST returns the result to the Oracle API Gateway.

  23. Return result. Oracle API Gateway returns the result to the Oracle WebLogic server.

  24. Return generated HTML page. Oracle WebLogic server returns the generated HTML page to the portal.

  25. Display generated HTML page. The portal displays the generated HTML page to the user.

  26. Click Logout to terminate Siebel session. The user clicks Logout to terminate the Siebel session.

  27. Trigger OAM logout URL. The portal invokes the Oracle Access Manager logout URL.

  28. OAM triggers Logout URL to terminate the session. Oracle Webgate invokes the Oracle Access Manager logout URL to terminate the session.

  29. Oracle Webgate redirects to final Logout page. Oracle Access Manager redirects Oracle Webgate to the final logout page.

  30. User lands on logout page. The user lands on the logout page.

For more information about each step in this process, consult the supporting documentation for your Web application server (for example, Oracle WebLogic), identity management solution (for example, Oracle Access Manager), and gateway (for example, Oracle API Gateway).

Note: For information about using OAuth with Siebel REST, see Siebel REST API Guide.

About Oracle API Gateway Role in Single Sign-On Authentication Process

The role of the gateway in the SSO authentication process is to act as the Assertion Consumer Service. The gateway validates the SAML token generated by the ID provider. All requests that are targeted to Siebel REST/SOAP must point to the gateway. The SOAP/REST end point is mapped to the gateway end point and vice versa. It is recommended to implement two-way TLS (Transport Layer Security) between Oracle API Gateway and Siebel REST as shown in the following image.

Note: You can use any gateway to process the assertion responses. For information about installing Oracle API Gateway, see https://docs.oracle.com/cd/E39820_01/doc.11121/gateway_install_docs/content/install_gateway.html.
Oracle API Gateway Role in Single Sign-On Authentication Process: There is a Gateway component (Policies, which map OAG end point to Siebel end point) and a Siebel component (Siebel REST/SOAP end point) in this image. There is a bidirectional arrow, labeled 2 way TLS, going from the Gateway component to the Siebel component.
Note: For information about using OAuth with Siebel REST, see Siebel REST API Guide.

Security Adapter Configuration When SSO is Enabled

Siebel offers multiple ways to communicate Siebel user identity to Siebel. Siebel understands user context only by the use of a user ID (for example: SADMIN). So if an Identity Provider (IdP) passes an email as an ID to Siebel (for example: SADMIN@oracle.com) , then it is Siebel’s responsibility to map that ID to a Siebel user ID. Nothing changes for Siebel Object Manager when SSO or federation is in place. The authentication flow remains the same in Siebel for both SSO with SAML (federated SSO with Security Assertion Markup Language) and non-SSO. A trust token is used instead of a password in SSO cases. The selection of a security adapter is guided by implementation constraints.

About Using an LDAP Security Adapter When SSO is Enabled

When using an LDAP security adapter, LDAP is implemented to map IDs using a single database user. This eliminates the need to maintain a large set of database users for Siebel. LDAP validates users by checking the mapped Siebel database user credentials. In SSO cases, LDAP uses a trust token as the password and this password is common for all users.

  • If different attributes are propagated from an IdP or used for login, then configure and use an adapter-defined user name. In the case of SSO with SAML, a directory lookup is required to map the adapter-defined user name to the Siebel user ID. For more information, see Configuring Adapter-Defined User Name.

  • Optionally, LDAP can be used to store Siebel user responsibilities as roles in a directory attribute instead of in the Siebel database (for example, if you want to share the information). For more information, see Configuring Roles Defined in the Directory.

For production environments, it is recommended that you use an LDAP security adapter to maintain Siebel users.

About Using a Database Security Adapter When SSO is Enabled

When using a Database security adapter, a separate database user must be created for each Siebel user. In SSO cases, database authentication can use a trust token as the password. When using this configuration, the trust token must match the user password for each database user. So if configuring a database security adapter where the value for trust token is HELLO, then all database user passwords must be set to HELLO for this scenario to work. Creating all database users for Siebel with the same password as trust token may be less practical than using LDAP in some use cases.