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. PeopleTools supports Azure, Okta, and Ping as authorization servers.
Before you attempt to configure service applications for the supported authorization servers, ensure that you complete the registration on those servers because some details of the registration are required to configure the service applications.
Access the Create OAuth2 Service Apps page (select ) and select the Add a New Value tab.
Field or Control |
Description |
|---|---|
OAuth Name |
Specify a name for a service application. |
Authorization Server |
Oracle supports the following OAuth 2.0 server providers:
|
This section describes the case where PeopleSoft is the provider of the service.
Access the Service Application page (select ) and select the Resource Only button.
Based on this selection, the necessary fields are displayed for the administrator to populate.
This example illustrates the fields and controls on the Service Applications - Resource Only page. You can find definitions for the fields and controls later on this page.
Term |
Definition |
|---|---|
Authorized Endpoint |
It is an HTTP endpoint that clients can use to identify a user or obtain an authorization code (which is then later exchanged for an access token) to be able to post to their website. The metadata endpoints for the different authorization servers are listed here. The metadata endpoint is where the authorized endpoint is published.
Note: If the system is upgraded from PeopleTools 8.58, the system administrator should ensure to enter the configuration data that is applicable to the specific OAuth server in use, because these values may change over time. |
Token Endpoint |
It is an HTTP endpoint that clients can use to obtain an access token. The metadata endpoints for the different authorization servers are listed here. The metadata endpoint is where the token endpoint is published.
Note: If the system is upgraded from PeopleTools 8.58, the system administrator should ensure to enter the configuration data that is applicable to the specific OAuth server in use, because these values may change over time. |
Issuer |
The issuer of the token. |
Scope |
This identifies the type of requests allowed. Valid choices are:
|
Scope URL |
This is an auto-generated URL based on the information defined on the Integration Broker Service Configuration page for Target Locations. |
Primary Audience |
This is the primary recipient where the token is processed. In this case it is the secure REST target location as defined on the Target Locations page. The administrator can append additional information to the URL to make it specific for a service operation. |
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 specified:
Cloud Site location used to validate OAuth2 token passed into REST Listening Connector:
ig.JSONWebKey: cloud site's JSON Web Key
ig.JSONWebKey=https://IDCS.tenant.instance.com/admin/v1/SigningCert/jwk
OAuth2 Client used for creating JWT-Bearer during Assertion Grant Type in HttpTargetConnector:
ig.AssertionKeyAlias=Client's KeyAliasName
ig.AssertionKeyPassword=Client's KeyAlias Password
Authorization Server used for Resources — currently supports IDCS, Azure, Okta, and Ping:
ig.AuthorizationServer:OAuth Server Type
ig.AuthorizationServer=IDCS
Service Operation Configuration
These instructions are applicable for the supported authorization servers: IDCS, Azure, Okta, and Ping.
For REST provider service operations, additional options are available in the Req Verification drop down list box on the Service Operations Definitions page 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 ) and select the Client Only button.
This example illustrates the fields and controls on the Service Applications - Client Only page. You can find definitions for the fields and controls later on this page.
Term |
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. |
Authorization Grant |
The Authorization Grant drop-down options are available only for the IDCS authorization server. 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:
For Azure, Okta, and Ping, Authorization Code is the only available authorization grant. See Authorization Grant Types for more information. |
Refresh Token |
Refresh tokens are credentials used to obtain access tokens. Refresh tokens are issued to the client by the authorization server and are used to obtain a new access token when the current access token becomes invalid or expires, or to obtain additional access tokens with identical or narrower scope (access tokens may have a shorter lifetime and fewer permissions than authorized by the resource owner). Note: The OAuth server needs to be configured to generate a refresh token along with an access token. |
Authorized Endpoint |
It is an HTTP endpoint that clients can use to identify a user or obtain an authorization code (which is then later exchanged for an access token) to be able to post to their website. |
Token Endpoint |
It is an HTTP endpoint that clients can use to obtain an access token. |
Issuer |
The issuer of the token. |
Redirect URl |
The URL is auto-generated based on the REST Target Location entry under Service Configuration. This URL should be copied and entered for IDCS to make the appropriate callbacks. |
Scope |
This identifies the type of requests allowed. Valid choices are:
|
Scope URL |
The scope URL is specific to the different authorization servers: For IDCS, the scope URL is auto-generated based on the information defined on the Service Configuration Target Locations page. See Using the Target Locations Page to Set Target Locations for Services. For Azure, it is defined as Azure Resource-Client-ID. |
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. This is applicable only to the IDCS authorization server.
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 ) and select the Client and Resource button.
This example illustrates the fields and controls on the Service Applications - Client and Resource page. You can find definitions for the fields and controls later on this page.
Term |
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. |
Authorization Grant |
The Authorization Grant drop-down options are available only for the IDCS authorization server. 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:
For Azure, Okta, and Ping, Authorization Code is the only available authorization grant. See Authorization Grant Types for more information. |
Refresh Token |
When you select the check box, it saves a refresh token to use when access token expires and retrieves an updated access token. Note: The OAuth server needs to be configured to generate a refresh token along with an access token. |
Authorized Endpoint |
It is an HTTP endpoint that clients can use to identify a user or obtain an authorization code (which is then later exchanged for an access token) to be able to post to their website. |
Token Endpoint |
It is an HTTP endpoint that clients can use to obtain an access token. |
Issuer |
The issuer of the token. |
Redirect URl |
The URL is auto-generated based on the REST Target Location entry under Service Configuration. This URL should be copied and entered for IDCS to make the appropriate callbacks. |
Scope URL |
The scope URL is specific to the different authorization servers: For IDCS, the scope URL is auto-generated based on the information defined on the Service Configuration Target Locations page. For Azure, it is defined as Azure Resource-Client-ID. |
Primary Audience |
The primary recipient where the token is processed. In this case it is the secure REST target location as defined on the Target Locations page. The administrator can append additional information to the URL to make it specific for a Service Operation. |
This information in this table provides the options for each grant type.
The following authorization 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.
|
Grant Type |
OAuth Server |
User Credential Required during Request |
Trusted by Using Certificate |
User Context in Access Token |
Allowing Refresh Token |
Browser Interaction |
|---|---|---|---|---|---|---|
|
Authorization Code (3–legged) |
IDCS, Azure, Okta, and Ping |
Y |
N |
Y |
Y |
Y |
|
JWT User Assertion (2–legged) |
IDCS only |
N |
Y |
Y |
Y |
N |
|
Client Credential (2–legged) |
IDCS only |
N |
N |
N |
N |
N |
For more information about grants types, see the product documentation for Integrating and Extending Oracle Content and Experience in Oracle Help Center.