5 Steps to Operationalize Self-service Application Integration in PingCentral

Identity security done right includes keeping things as simple as possible. Available as on-premises software hosted in a dedicated tenant, PingCentral makes it easier than ever to onboard and manage applications across your organization. PingCentral is an operating portal that enables self-service, centralized management of application resources in PingFederate and PingAccess, freeing up significant time and resources so your teams can deliver even more strategic business value while rapidly modernizing your legacy infrastructure.

PingCentral can streamline the adoption of PingFederate across your enterprise, ultimately accelerating your digital and cloud transformation. Here are the five steps we recommend you take to roll this out in your enterprise:

1. Identify use cases and resource priority

2. Get PingFederate and PingAccess in shape

3. Set up PingCentral

4. Educate non-IAM experts

5. Enable other teams to add PingFederate and PingAccess features to their applications with self-service options

    

One of the best ways to ensure success with PingCentral is to include the right line-of-business (LOB) stakeholders from the beginning. Get insights on your key stakeholders’ most common use cases, and ensure you understand what it would take for them to adopt self-service app integration. 

With the input from your internal customers as a guide, identify the use cases that will benefit your organization the most. Categorize and prioritize your customer-facing, partner-facing, and internal resources, including all the vendor SaaS apps, and group them by user and authentication type so you can see what types of OAuth, OIDC, and SAML authentication methods will be used most frequently, as well as how LOB users describe their needs.

Start reviewing your authentication policies in PingFederate and PingAccess, and create example OAuth/OpenID Connect clients or SAML connections that use Policy Contract. You'll also need to ensure consistent configurations of authentication policies, policy contracts, and attributes on each target environment of PingFederate and PingAccess. Also, here is a bit more detail on leveraging extended properties to templatize your policy trees and selectors:

Additional Attributes from Data Stores

PingCentral doesn't support custom calls specific to an app (e.g., an OGNL expression referencing a specific directory group as part of attribute mapping for a SAML connection). All of the attributes exposed in the PingCentral attribute-mapping wizard are from the primary authentication policy contract (APC). Here's the cool thing: Nothing prevents you from mapping additional attributes to that APC and making them available to any application for mapping. 

We recommend taking all the additional attributes from any data source you need and mapping those to your policy contract rather than directly to the service provider connection as part of the attribute mapping. We've seen some of our large customers use this approach to accomplish flexible attribute mapping that is still simple for delegated users to consume. In general, we don't recommend mapping custom data sources directly to an individual application, as this prevents reuse.

Adding Connections to Specific Selectors

PingFederate can be used to create extended properties (user-defined metadata) that will be part of the data model and JSON for any client or connection you create. Additionally, PingFederate has a selector type that is based on the values of extended properties. This means you can build a flow chart with as many levels and branches as you want leading to specific adapters and authentication policy contracts. Any client or connection is mapped into its rightful place in this policy flow only through APCs and extended properties, which means no explicit connection needs to be made. Please take a look at these steps.

Step 1: Turn on extended properties in PingFederate.

Step 2: Build your authentication policy to use the Extended Properties selector.

Once you've gotten PingFederate in shape, it's time to set up PingCentral. Deploy it on a server with network connections to all your PingFederate environments. Next, you'll want to set up SSO so your developers and administrators can sign in to PingCentral using your established single sign-on. This is set up by configuring PingCentral as an OIDC client in its applications properties file so that you don't need to use the local user store; you can pre-provision application ownership, and users can leverage their corporate credentials.

Then, in PingCentral, you'll add all your different PingFederate environments, such as dev, staging, and production. You’ll also need to build applications and connections in PingFederate that are imported into PingCentral as templates that reflect the most common use cases so that you have a clean set for application owners to select from when they open their PingCentral console to add a new application or connection.

Another step that will help accelerate getting up and running with PingCentral is getting the applications already in PingFederate into PingCentral and provisioning the right application owners for these existing apps. Although this can be done manually, we recommend doing it through a script via API calls to PingCentral.

Step 3: Create a client or connection that specifies the extended properties values you want to use in a template.

You already have a set of folks who fulfill application teams' requests for authentication and single sign-on with PingFederate. These requests can include adding new applications, making authentication configuration changes, promoting to new environments, rotating client secrets, and performing other tasks that will be handled in PingCentral moving forward. The folks who usually help with these application team requests are the ones you should turn to as you declare an official PingCentral onboarding team. They are likely folks who are on the security team, or they could be in an adjacent operations group. 

Communicate to these individuals that they are officially part of the PingCentral onboarding team and what their role at this stage encompasses. Get everyone on your onboarding team (especially anyone who wasn't involved in the first three steps) knowledgeable on PingCentral functionality and the templates, environments, resources, and owners you've configured.

Once the team is up to speed, everyone on the onboarding team should try using PingCentral to fulfill application teams' requests for a set period. Sign in as an application owner and see if you can do what you would be expecting application owners to do when you turn PingCentral over to them. Another important goal is to see if you can stop using the PingFederate administration console for the majority of the application teams' requests. 

This onboarding exercise will hopefully give you a lot of quick learnings so that you can:

• More quickly handle common requests

• Understand which templates are used the most

• Validate appropriate configurations on each target PingFederate environment

Now it's time to start delegating administration to your application owners outside of the onboarding team. You'll want to start with your most IAM-savvy application teams, those with the highest degree of IAM knowledge and the highest volume of requests (the ones who rely on your services the most). Once these teams are adopting self-service and giving you feedback, their frequently asked questions can help you refine your templates and internal education to better guide the rest of your enterprise. 

Continue rolling out PingCentral delegated administration in manageable waves as necessary so that you can smooth out any rough edges in the transition and have time to address questions. And be sure to use two-way feedback channels with application teams. Some organizations have found a monthly "office hours" session aids in communicating and managing the change, helping to get the rest of your organization all aboard the PingCentral express.

Learn more about PingCentral here: https://www.pingidentity.com/en/pingone/pingcentral.html