Configuring Service Applications

The Authorization Server supported by PeopleTools is IDCS (Oracle Identity Cloud Service).  The Oracle Identity Cloud Service REST APIs provide a way to integrate Oracle Identity Cloud Service with REST clients so that they can manage users, groups, applications, and settings, and perform federated single sign-on (SSO) and authorization in the cloud.

This section describes the case where PeopleSoft is the Provider of the Service. The only authorization server currently supported by PeopleTools is IDCS.

Access the Service Application page (select PeopleTools > Security > OAuth2 Administration > Service Applications) and select Resource Only button.

Based on this selection, the necessary fields are displayed for the administrator to populate. The administrator would also log into IDCS in order to configure IDCS. For more information on Oracle Identity Cloud Service (Oracle’s Server), see product documentation for Oracle Identity Cloud Service on Oracle Help Center.

Image: Service Applications - Resource Only page

This example illustrates the fields and controls on Service Applications - Resource Only page. You can find definitions for the fields and controls later on this page.

Service Applications - Resource Only

Field or Control

Definition
Tenant

The URL address to the authorization server.
Issuer

The issuer of the token.
Scope

This identifies the type of requests allowed. Valid choices are readwrite, read, write.
Primary Audience

The primary recipient where the token is processed. In this case it would be the secure REST target location as defined on the Service Configuration page. The administrator can add additional information on the end of the URL to make it specific for a service operation.
Secondary Audience(s)

The secondary recipient(s) where the token is processed. The administrator ensures that a select number of different service operations can be invoked with URLs specific to each service operation. The administrator adds these additional URLs.

Gateway Configuration

For configuration as a Resource, the integration.properties file needs to be updated with additional OAuth 2.0 information. The following properties must be filled out:

  • ig.CloudSite: This is the URL to the authorization server.

  • ig.CloudPublicKey: This is the authorization server’s public JSON Web Key.

  • ig.AuthorizationServer: Authorization server used by provider (Only supports IDCS).

Service Operation Configuration

For REST provider service operations, there will now be additional options available in the Req Verification drop down list box for:

  • OAuth2 Authorization: The integration partner must pass a valid access token.

  • OAuth2 Authorization and SSL: The integration partner must pass a valid access token and transmit the service operation using SSL encryption.

Consumer REST calls requiring a token will be supported by the security framework if the authorization server is IDCS (or Microsoft Azure for authorization code only.). For any other authorization server, it will be up to the developer to make the necessary calls to obtain an access token.

The administrator creates a Service Application and registers information from the provider’s authorization server.

Access the Service Application page (select PeopleTools > Security > Administration > Service Applications) and select Client Only button.

Image: Service Applications - Client Only page

This example illustrates the fields and controls on Service Applications - Client Only page. You can find definitions for the fields and controls later on this page.

Service Applications - Client Only page

Field or Control

Definition
Client ID

The API key value generated when you registered your application with the OAuth server.
Client Secret

The secret key value generated from the OAuth server.
Tenant

The URL address to the OAuth server.
Issuer

The issuer of the token.
Authorization Grant

Applications can request an access token to access protected endpoints in different ways, depending on the type of grant type specified in the client application. A grant is a credential representing the resource owner's authorization to access a protected resource.

Currently PeopleSoft supports the following grant types:

  • Authorization Code (3-legged)

  • Assertion (2-legged)

  • Client Credentials (2-legged)
Refresh Token

When the box is checked, it will also save off a refresh token to use when access token expires to retrieve an updated access token.

Note: Note that the OAuth server needs to be configured also to generate a refresh token along with an access token.
Redirect URl

The URL will be auto-generated based on the REST target location entry under Service Configuration.  This is the URL that needs to be copied and entered in IDCS for IDCS to make the appropriate callbacks.
Scope

This identifies the type of requests allowed.  Valid choices are readwrite, read, write.
Scope URL

This scope URL is copied to the resource built in IDCS. This is auto-generated URL based on the information defined on the Service Configuration Target Locations page.

Grant Types Supported

The following grant types are supported:

  • Authorization Code - 3-legged-OAuth: This grant type is used when you want to obtain an authorization code by using an authorization server as an intermediary between the client application and the resource owner.

  • Assertion - 2-legged-OAuth: This grant type is used when you want to use an existing trust relationship expressed as an assertion and without a direct user approval step at the OAuth Authorization Server.

  • Client Credentials - 2-legged-OAuth: This grant type is used when authorization type is limited to the protected resource s under the control of the client or to protected resources registered with the OAuth Authorization Server.

For more information about grants types, see the product documentation for Integrating and Extending Oracle Content and Experience from the Oracle Help Center.

Gateway Configuration

For configuration as a client (consumer), when using the assertion grant type, the integration.properties file needs to be updated with additional information.

The PeopleSoft private keys (client) used to retrieve the access token are:

  • ig.AssertionKeyAlias: The alias name defined for the private key enter into the key store.

  • ig.AssertionKeyPassword: The password defined for the private key.

For the case where the client is actually calling the same resource (local REST integrations), the administrator can select the Application Type as Client and Resource.

Access the Service Application page (select PeopleTools > Security > Administration > Service Applications) and select Client and Resource button.

Image: Service Applications - Client and Resource page

This example illustrates the fields and controls on Service Applications - Client and Resource page. You can find definitions for the fields and controls later on this page.

Service Applications - Client and Resource

Field or Control

Definition
Client ID

The API Key value generated when you registered your application with the OAuth server.
Client Secret

The Secret Key value generated from the OAuth server.
Tenant

The URL address to the OAuth server.
Issuer

The issuer of the token.
Authorization Grant

Applications can request an access token to access protected endpoints in different ways, depending on the type of grant type specified in the client application. A grant is a credential representing the resource owner's authorization to access a protected resource.

Currently PeopleSoft supports the following grant types:

  • Authorization Code (3-legged)

  • Assertion (2-legged)

  • Client Credentials (2-legged)
Redirect URl

The URL will be auto-generated based on the REST Target Location entry under Service Configuration.  This is the URL that needs to be copied and entered for IDCS to make the appropriate callbacks.
Scope URL

This scope URL is copied to the resource built in IDCS. This is auto-generated URL based on the information defined on the Service Configuration Target Locations page.
Primary Audience

The primary recipient where the token is processed. In this case it would be the secure REST target location as defined on the Service Configuration page. The administrator can add additional information on the end of the URL to make it specific for a Service Operation.

This information in this table provides the options for each grant type. 

Grant Type

Credential

Trusted

User Context

Refresh Token

Browser Interaction

Authorization Code (3–legged)

Y

N

Y

Y

Y

Client Credential (2–legged)

Y

N

N

N

N

JWT Assertion (2–legged)

N

Y

Y

Y

N