Siebel REST API Guide > Overview of Using the Siebel REST API >

About Configuring OAuth 2.0 for Authentication

The Siebel REST API can use the OAuth 2.0 protocol for authentication to securely identify applications before connecting to the Siebel Server.

In general, the Siebel REST API layer contacts the OAuth server over a secure channel (for example, HTTPS) to validate the access token received or obtain additional token information. The Siebel Server only requires a USERID to establish a Siebel Server session since authentication takes place outside of Siebel in either SSO or OAuth, and does not require password.

The following prerequisites are required on the Siebel side before configuring OAuth for authentication. You must install and set up the components, including OAuth 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.

• The Siebel Object Manager must be configured for SSO when OAuth is enabled for authentication. The related security adapter is also required. 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 TrustToken parameter defined for the custom security adapter. For more information about configuring SSO, see Siebel Security Guide.
• The Siebel REST API layer contacts the OAuth server over a secure channel to validate or get token information. To enable HTTPS, the required certificates from the OAuth server must be installed in the environment where the Siebel REST API is hosted. To bypass HTTPS (the secured channel), you can set the ValidateCertificate parameter value to FALSE in the siebsrvr.properties file. Oracle does not recommend disabling the secured channel in production. For more information about the siebsrvr.properties file, see Configuring the Siebel Java Web Container.
• The following parameters must be set in the siebsrvr.properties file:
  • SingleSignOn. The SingleSignOn property must be set to TRUE to implement SSO.
  • AuthenticationType. The AuthenticationType property must be set to OAuth to implement OAuth authentication
  • TrustToken. The TrustToken value must be the same as the security adapter TrustToken parameter value.
  • OAuthEndPoint. The OAuthEndPoint value is the URL of the OAuth Service Provider end point for Access Token validation.
  • ValidateCertificate. The ValidateCertificate parameter is required to bypass the HTTPS secured channel. Oracle does not recommend setting the value for this parameter to False during production. Rather, you should set the value at the point when it is required to bypass the HTTPS secured channel.

For more information about the siebsrvr.properties file properties, see Configuring the Siebel Java Web Container.

While the customer authentication flows vary depending on your business needs, Oracle supports all OAuth 2.0 authentication flows. This topic contains a few sample authentication flows. In all authentication flows, the Siebel REST API layer extracts and validates the Access Token when the authentication type value is OAuth. Customers must generate the authorization and access code. The Siebel Server handles only the resource server initiated flow and any remaining flows must be implemented by the customer.

Client Credentials Grant Authentication Flow

The client credentials grant flow represents an application that calls another application or service, without end user intervention. In this example, the client server application makes a call to the Siebel resource server to request business information. Since there is no end user intervention, the client is pre-authorized to have access to the resource.

Figure 2 is an example of the Client Credentials Grant Authentication Flow

Figure 2. Client Credentials Grant Authentication Flow

The steps in client credentials grant authentication flow process shown in Figure 2 are:

1. The business client application makes a call to the Siebel Server to request some business information by passing an access token. Since there is no end user intervention, the client is pre-authorized to have access to the resource.
2. The request is redirected to the OAuth server for authentication.
3. The OAuth server returns an access token.
4. The client server sends a request to the resource server. The request includes the access token in the HTTP header. Siebel looks for USERID from the token to establish a Siebel Server session.
5. The Siebel server validates the access token with the OAuth server.
6. If the access token is authorized by the OAuth server, then access is granted to the Siebel resource.
7. The Siebel Server returns the requested resource.

Web Server Authentication Flow

In the Web server authentication flow, the client application is running on the client server. In this case, an end user accesses an application, which needs to fetch data from a resource server on behalf of the end user, but without the end user providing his credentials to the application. The user has to provide his consent for the client application to access resources in the resource server. In this use case, all the code resides in the client server and it is not visible to the end user. For the OAuth server, you can use Oracle Access Manager and Oracle Webgate, or any other Web application and gateway depending on your business needs.

Figure 3 is an example of the Web server Authentication Flow.

Figure 3. Web Server Authentication Flow

The steps in Web Server Authentication Flow process shown in Figure 3 are:

1. A user initiates a request to the client application.
2. The request is redirected to the OAUTH server (for example, Oracle Access Manager) for authentication.
3. The OAuth server sends a login form to the user to grant access.
4. The user enters their credentials and the OAuth server determines whether to grant access.
5. The OAuth server determines if user consent is required.
6. If user consent is the required, the OAuth server sends a consent form to the user.
7. The client server grants access.
8. If access is granted, the OAuth server sends an authorization code.
9. The client application requests an access token from the OAuth server.
10. The OAuth server sends the access token.
11. The client application sends a request to the resource server and includes the access token in the request header.
12. The resource server sends a request to the OAuth server to validate the access token.
13. The OAuth server validates the access token.
14. The resource server sends a response with the requested information to the client application.
15. The client application sends the requested information to the user.