Implementation of Client Credential Grant Type in PingFederate
This topic describes the manual steps for authorizing access to resources and authenticating resource owners using the OAuth Client credential grant type. Here, OAuth client is the service provider with PingFederate as CAS. Windchill server is the resource server. As the LDAP protocol is replaced with OAuth protocol, Windchill is required to use OAuth/token based authentication to invoke APIs.
Pre-Requisites
All subsections here assume that the Central Authorization Server (CAS), Windchill, and the client application have been configured for OAuth. Windchill must be configured as a Resource Server using OAuth. The OAuth Client must be registered as a Service Provider.
Windchill User for Client Credentials Grant Type
The Windchill principal used with client credential grant type is a machine identity intended to represent a non-interactive client machine used to integrate with Windchill. It represents a non-human identity and must be defined in LDAP like any other user. However, this user should be used only for integration purposes. The process to associate the client credential in Ping Federate to an identity in Windchill is explained below.
Use of the machine identity must be controlled to ensure it is managed securely. The identity, client id and secret should be managed by the Windchill administrator and should not be shared. Specific actions in Windchill are not expected to be completed by a machine identity and should not be expected such as:
No direct login to Windchill application with this identity account.
No password should be set in LDAP. Credentials are managed through SSO.
Any UI activity or operation should not be performed by this identity.
ESignature or workflow tasks providing human approval or confirmation should never be assigned to this identity.
Pre-requisite Steps for PingFederate Client Credential Registration
Follow the steps below in PingFederate for the client credential registration:
1. Create extended property — Create serviceprincipal property at SYSTEM > Extended Properties.
2. Access token mapping — Create a new access token mapping at APPLICATIONS > Access Token Mappings. Select context (client credentials) and default access token manager.
3. Contract fulfilment — Configure the contract fulfilment with user attribute as serviceprincipal that is configured as extended property in step 1.
Client Registration Steps in PingFederate
Follow the steps below in PingFederate for the client registration in CAS(PingFederate):
1. Create new client at APPLICATIONS > OAuth > Clients > Add Client. Provide Client ID and Name.
2. Select Client Secret in client Authentication.
3. Generate client secret and copy it to secure location for further use.
4. Set grant type client credential.
5. Set default access token manager to default.
6. Create an Windchill user that is used as a service account. Set this Windchill user name as serviceprincipal property value mentioned above.
Access Token Request from the Authorized Application
The OAuth client should obtain the access token by submitting a POST request to the authorization server's token endpoint. Note that the request body must have the application/x-www-form-urlencoded content type. The request URI details are:

#URI
POST <CAS_SERVER_TOKEN_URL>
#Request Headers
Content-Type: application/x-www-form-urlencoded
#Request Body
grant_type= client_credentials&client_id=<CLIENT_ID>&client_secret=<CLIENT_SECRET>&scope=<scope>


#Example of the URI
POST https://<host>:<port>/as/token.oauth2
Content-Type: application/x-www-form-urlencoded
grant_type= client_credentials&client_id=sp1-oauth2-client&client_secret=sp1-oauth2-client_1234&scope= WINDCHILL_READ

Parameter
Description
grant_type
The grant type for this flow is client_credentials.
CLIENT_ID
The client ID your generated in your CAS for this web application.
CLIENT_SECRET
This is the client secret you entered in the CAS when configuring this web application.
SCOPE
Must be WINDCHILL_READ when accessing Windchill or WRS.
Was this helpful?