Single Sign-On Authentication

This chapter describes how to implement Web Single Sign-On (Web SSO) and Federated Single Sign-On (Federated SSO) for user authentication. It includes the following topics:

Note: If you are using the Siebel Self-Service Applications available with Siebel CRM Release 8.1, then see Siebel Self-Service Application Deployment Guide for additional information on Web Single Sign-On user 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:

Web Single Sign-On (Web SSO). This solution includes the following use case:
- Web SSO for interactive user interfaces. See the following topics:
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.
- SSO with SAML for interactive user interfaces. For more information, see the following topics:
  - Federated Single Sign-On Authentication Process for Interactive User Interfaces
  - About Oracle API Gateway Role in Single Sign-On Authentication Process
- SSO when Siebel REST and Siebel Web services are used in a portal application. For more information, see the following topics:
  - Web Single Sign-On Authentication Process When Using Siebel REST and Web Services in Portal Application
  - About Oracle API Gateway Role in Single Sign-On Authentication Process
- Identity provider-initiated SSO. In this case, the portal application links to Siebel REST and Web services. The portal acts as an Identity Provider (IdP) and initiates federation. For more information, see the following topics:
  - Identity Provider-Initiated Single Sign-On Authentication Process
  - About Oracle API Gateway Role in Single Sign-On Authentication Process
    
    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

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.

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.

Web Single Sign-On Authentication Process

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

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

A user attempts to access the Siebel client (A).
The SSO authentication service intercepts the user request and determines if the Siebel resource is protected (B).
- 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.
The user enters credentials at the client that are passed to the Web server (C).
The third-party authentication client on the Web server (C) passes the user credentials to the third-party authentication service (B).
The authentication service 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.
The Siebel Application Interface passes the authenticated user’s user name and the value for the Trust Token parameter to the security adapter. The user name can be the Siebel user ID or another attribute (E).
The security adapter provides the authenticated user’s user name to a directory, from which the user’s Siebel user ID, a database account, and, optionally, roles are returned to the security adapter (F).
In addition, the security adapter 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.
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.

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.

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

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.
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

Configure the Web SSO session timeout to be five minutes and restart the Web servers.
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.
Access the Siebel URL for the Web server from the same browser used in the previous step.
Basic authentication should be required.
Enter valid Siebel user credentials.
The Siebel application should be displayed.
Leave the browser window open and idle for more than five minutes.
Refresh the browser window using the Refresh button.
You should be prompted to enter user credentials.
Enter valid Siebel user credentials.
The Siebel application should be displayed.
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.

Table Symbolic URL Parameters

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.

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 figure shows part of a 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 (Part I)

The following figure shows the remainder of 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 (Part II)

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

GET/Access protected Siebel Portal. A non-authenticated user requests access to a protected Siebel Web Portal.
Redirect to Login page. There is no OAMAuthn cookie, so the user is redirected to the login page.
Enter credentials and submit login form. The user enters their credentials and submits the login form.
Validate credentials in IDStore. Oracle Access Manager validates the user credentials in the IDStore (Oracle LDAP or Oracle Unified Directory installed with Identity Store).
IDStore responds success. The IDStore returns success to Oracle Access Manager.
Respond with OAMAuthnCookie. Oracle Access Manager forwards the OAMAuthnCookie to Oracle Webgate.
Set OAMAuthnCookie and redirect to Portal. Oracle Webgate sets the OAMAuthnCookie and redirects the user to the portal.
Portal Home page. The user accesses the portal home page.
There is no step 9 in the Web SSO authentication process shown in the figures in this topic.
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.
Validate authorization for QUOTE link URI. Oracle Webgate invokes Oracle Access Manager to validate authorization for the QUOTE link URI.
Return SAML assertion. Oracle Access Manager returns SAML assertion to Oracle Webgate.
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.
Send SAML assertion with URI. Oracle WebLogic server sends the URL with SAML assertion to the Oracle API Gateway.
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.
Return result. Siebel REST returns the result to the Oracle API Gateway.
Return result. Oracle API Gateway returns the result to the Oracle WebLogic server.
Return generated HTML page. Oracle WebLogic server returns the generated HTML page to the portal.
Display generated HTML page. Siebel Web portal displays the generated HTML page to the user.
Click Logout to kill Siebel session The user clicks Logout to kill the Siebel session.
Trigger Oracle Access Manager logout URL. Siebel Web Portal invokes the Oracle Access Manager logout URL.
Oracle Access Manager triggers logout URL to kill the cookie and session. Oracle Webgate invokes the Oracle Access Manager Logout URL to kill the cookie and the session.
Oracle Webgate redirects to final logout page. Oracle Access Manager redirects Oracle Webgate to the final logout page.
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 and is not supported by Oracle. For non-Linux platforms, the module must be compiled. The mode_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/3.3/securing_apps/topics/saml/mod-auth-mellon.html and https://github.com/Uninett/mod_auth_mellon.

Federated Single Sign-On Authentication Process for Interactive User Interfaces

The following figure 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

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

A non-authenticated user requests a Siebel interactive UI protected by Oracle Webgate.
Oracle Webgate intercepts the request and redirects the user to Oracle Access Manager for authentication.
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.
The tenant's IdP processes the SAML AuthN request and authenticates the user if required.
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.
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.
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 figure shows an identity provider-initiated SSO authentication process.

Identity Provider-Initiated Single Sign-On Authentication Process

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

GET/Access protected Customer Portal. A non-authenticated user requests access to a protected Customer Web Portal.
Redirect to Login page. There is no OAMAuthn cookie, so the user is redirected to the login page.
Enter credentials and submit login form. The user enters their credentials and submits the login form.
Validate credentials in IDStore. Oracle Access Manager validates the user credentials in the IDStore (Oracle LDAP or Oracle Unified Directory installed with Identity Store).
IDStore responds success. The IDStore returns success to Oracle Access Manager.
Respond with OAMAuthnCookie. Oracle Access Manager responds with the OAMAuthnCookie to Oracle Webgate.
Set OAMAuthnCookie and redirect to portal. Oracle Webgate sets the OAMAuthnCookie and redirects the user to the portal.
Land on portal index.html page. The user lands on the portal’s index.html page.
index.html loads IdP initiated Federation. The index.html page loads the IdP-initiated federation.
Post SAML assertion with returnurl. Oracle Access Manager posts SAML assertion with returnurl.
Lookup user from the SAML attribute. Oracle Access Manager checks with Oracle LDAP to look up the user from the SAML attribute.
Return success. Oracle LDAP returns success.
Set OAMAuthnCookie. Oracle Access Manager sets the OAMAuthnCookie.
Redirect to portal landing page. The user is redirected to the portal landing page.
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.
Validate authorization for QUOTE link URI. Oracle Webgate validates authorization for the QUOTE link URI.
Validates OAMAuthnCookie. Oracle Webgate validates OAMAuthnCookie and sends the information on to Oracle Access Manager.
Authorized and returns OAM SAML assertion. Oracle Access Manager authorizes and returns OAMSAML assertion to Oracle Webgate.
Send REST request and SAML to WLS Servlet. Oracle Webgate sends the REST request and SAML to the Oracle WebLogic server.
Send SAML assertion with URI. Oracle WebLogic server sends the SAML assertion with URI to the Oracle API Gateway.
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.
Return result. Siebel REST returns the result to the Oracle API Gateway.
Return result. Oracle API Gateway returns the result to the Oracle WebLogic server.
Return generated HTML page. Oracle WebLogic server returns the generated HTML page to the portal.
Display generated HTML page. The portal displays the generated HTML page to the user.
Click Logout to kill Siebel session. The user clicks Logout to kill the Siebel session.
Trigger OAM logout URL. The portal invokes the Oracle Access Manager logout URL.
OAM triggers Logout URL to kill the session. Oracle Webgate invokes the Oracle Access Manager logout URL to kill the session.
Oracle Webgate redirects to final Logout page. Oracle Access Manager redirects Oracle Webgate to the final logout page.
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 figure.

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

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

6Single Sign-On Authentication