In this workflow, you'll sign on to the PingOne environment created when you first signed on to your account, and use the admin console to create an admin Worker app. You'll also assign the Environment Admin role at the Organization level to the Worker app. This is the only role that can be assigned at the Organization level. The Organization-level Environment Admin role gives you permissions to all existing PingOne environments as well as any new environments that are added.

This is the only workflow for which you'll use the PingOne admin console. The remaining workflows use only the PingOne APIs.

The result

You'll have a Worker app with Organization-level admin permissions that you can use to make PingOne API calls on your behalf in any PingOne environment.

Sign on to the PingOne admin console. For more information about the PingOne admin console, see Accessing the admin console home page.

In the admin console, add a Worker app connection to PingOne:

1. Select Applications --> Applications.

   

2. Click the + icon next to Applications to add a new app.

3. In the Application Name field, enter an application name, and select Worker as the Application Type.

   

4. Click Save. The Roles tab is then displayed on the application information page.

In the application information page for your new Worker app, you'll assign the roles that grant admin-level permissions to the Worker app.

1. In the Roles tab, click Grant Roles. The best practice is to ensure the roles assigned to the Worker app are limited to only those necessary. For this workflow, grant the roles and permissions as shown.

   1a. Assign the Organization Admin role as shown. This role is needed to create a new environment:

   

   1b. Expand the Environment Admin role:

   

   1c. Click the Organization checkbox for the Environment Admin role, and note the information displayed:

   

2. Click Save.

3. The roles and permissions you've granted are then displayed. They should look like this:

   

When you subsequently call Management API requests, as you will in steps 2-5 of the next workflow to create a test environment, you'll see one or more of these PingOne role icons beneath the request title:

Role	Icon	Abbr.	Can Assign
Organization Admin		ORG	Environment Admin
Environment Admin		ENV	All roles except Organization Admin
Identity Data Admin		IDA	Identity Data Admin, Identity Data Read-Only Admin
DaVinci Admin		DVA	DaVinci Admin, DaVinci Read-Only Admin
Custom Role Admin		ROLE	None
Application Owner		APP-O	None
Identity Data Read-Only Admin		IDA-R	None
Configuration Read-Only Admin		CFA-R	None
DaVinci Read-Only Admin		DVA-R	None
Client Application Developer		APP	None

For example, in the request documentation to GET all applications for an environment, either the Client Application Developer or Environment Admin role is required to call the request:

For some requests, multiple roles have permissions necessary to call the request. As long as your Worker app has at least one of the roles shown for the request, the Worker app can make the call.

While still in the application information page for your new Worker app, you'll get the Worker app credentials, and enable the Worker app.

1. Select the Overview tab. The general information for your Worker app is displayed. In particular, you'll see the Environment ID, and the credentials for your Worker app: the Client ID, and Client Secret.

   

(The Connection Details information isn't shown here for brevity.)

1. Copy the Client ID and Client Secret values for your Worker app. You'll need these credentials when obtaining an admin access token in the subsequent workflow to create your test environment.

2. Also copy the Environment ID. You'll need this because this is the environment in which you created the Worker app. When you need to get an access token for your Worker app, as you will in the next workflows, this is the environment you'll specify for the request.

3. Click the toggle at the upper right to enable the application. The Worker app is saved, and you can now close the application information page.

You're now all set to use the PingOne APIs in the next workflows.

In this workflow, you'll first get an access token. This enables you to call the subsequent requests in this workflow. Although you created an environment when you first signed on to your PingOne account, you'll create an additional, new environment to use here, and for any subsequent testing you might want to do. You'll then create a Population resource, and a new user for this population. Finally, you'll assign the new user a password.

A new environment includes several PingOne resources automatically created for the environment (such as, a default sign-on policy, password policy, a default population, and defined notifications templates). This workflow uses the environment's default sign-on policy and password policy to simplify the workflow.

The result

• You'll know how to get a PingOne access token for your Worker apps. For security purposes, access tokens have a 1 hour expiry, so you'll use this request often.

• You'll now have a PingOne environment that you can use for testing, without impacting your initial environment.

• You'll know how to create populations, users, and assign users to populations, as well as how to assign user passwords. This is useful when you're creating initial admin users. When creating or importing large numbers of users, you'll use different techniques. See Where to go from here for the documentation references.

If you choose to use Postman

If you don't already have a Postman installation, you can install the free version. See Download Postman.

1. Import or fork the Postman collection Create your test environment into your Postman installation by clicking the Run in Postman button below. You'll use this collection for this workflow:

   

2. When you open the Postman collection, ensure that you select PingOne Postman Environment Template for use with the collection:

   

3. Refer to Postman and the PingOne APIs as needed for important information.

If you choose not to use Postman

If you'd rather not install Postman, this guide doesn't limit or constrain you in that respect. Each Postman request is documented, and has a dropdown list to show the coding language to use for the request. (This is also true for our Platform Reference API documentation.)

You can use cURL (the default) and call the request from your command line, or select one of the other coding languages in the dropdown list, copy the request into your IDE, and call it from there.

In this workflow, you'll test the new environment you created by setting up a Web app for users to perform single sign-on (SSO) to PingOne. You'll do this by creating an OIDC Web app, getting the new Web app's secret, and making an authorization request to the PingOne authorization server. Then, you'll make flow orchestration requests to submit your test user's credentials, get an authorization code, and exchange the auth code for an access token.

The result

• The sign-on workflow returns an access token, enabling a PingOne user (in this case, the user you've created in the prior workflow to create a test environment) to SSO through a Web application. The PingOne authorization and authentication APIs perform the following actions:

  • Query the PingOne authorization server to initiate the sign-on flow.

  • Start an authentication session and return a flow ID that tracks the user through the sign-on steps.

  • Prompts the user to submit their username and password.

  • Verifies the user's credentials, and issues an authorization code in response.

  • Exchanges the authorization code for an access token that signs on to the user's account through the Web application.

• By completing the sign-on workflow, you've verified that the new environment, the test user, the Web application, and the authentication actions that you've created are functional.

If you choose to use Postman

If you don't already have a Postman installation, you can install the free version. See Download Postman.

1. Import or fork the Postman collection Simple SSO into your Postman installation by clicking the Run in Postman button below. You'll use this collection for this workflow:

   

2. When you open the Postman collection, ensure that you select PingOne Postman Environment Template for use with the collection:

   

3. Refer to Postman and the PingOne APIs as needed for important information.

If you choose not to use Postman

If you'd rather not install Postman, this guide doesn't limit or constrain you in that respect. Each Postman request is documented, and has a dropdown list to show the coding language to use for the request. (This is also true for our Platform Reference API documentation.)

You can use cURL (the default) and call the request from your command line, or select one of the other coding languages in the dropdown list, copy the request into your IDE, and call it from there.

Now that you've successfully completed the workflows:

• You can use the requests in the workflows to:

  • Create more users in a population, and get the PingOne prompt using the web app you created for the new users.
  • Reset a user's password.
  • Change or add the attributes for the Web app.

• You know how to get a PingOne access token, so you might want to choose some use cases to try out from the PingOne Workflow Library.

• If you're using Postman, or plan to, see The Postman Platform collection, and Postman and the PingOne APIs for important information.

• You'll find more background on PingOne concepts and architecture in the topics in PingOne for Developers Foundations.

For further information related to the workflows you just completed, see these topics:

The create a test environment workflow

Background information related to the create a test environment workflow:

• Access tokens and ID tokens

• Environments

• Environment Management

• Populations

• Users

The API requests you used in this workflow:

• Token (authorization_code) (CLIENT_SECRET_BASIC)

• Create Environment

• Create Population

• Create User

• Set Password

The SSO workflow

Background information related to the SSO workflow:

• Application Management

• Application Operations

• Application Secret

• Authorization and authentication

• OpenID Connect/OAuth 2

• Flows

• Access tokens and ID tokens

The API requests you used in this workflow:

• Token (authorization_code) (CLIENT_SECRET_BASIC)

• Create Application (OIDC Protocol - Web App)

• Read Application Secret

• Authorize (authorization_code)

• Read Flow

• Check Username/Password

• Resume Flow

• Token (authorization_code) (CLIENT_SECRET_BASIC)

The PingOne Platform Postman collection

The Postman public collection for the PingOne Platform includes the requests for all create, read, update, and delete (CRUD) operations for the PingOne Platform APIs, the PingOne MFA APIs, the PingoOne Neo APIs, and the PingOne Protect APIs. The downloads also include a PingOne Postman environment template to help you assign values to variables in the request URLs.

Description	Retrieve
Postman requests for the PingOne platform API. Includes all environment variables. No example responses to make it easy to get started.
Postman requests for the PingOne platform API. Includes all PingOne documentation and example reponses. No environment variables are included.

The PingOne Postman environment template

The Postman collection uses variables in the request URLs to specify UUIDs for PingOne resources within your organization. When you click the Run in Postman button, the environment variable template downloads and installs automatically. Using this environment template, you can associate your PingOne resource UUIDs with the common variables used in many of the requests.

POST requests that create a resource and return a resource ID, include a script in the Postman Script tab, that automatically adds a resource variable to your active Postman environment template and uses the newly created ID as the value.