PingCentral: 5 Steps to Operationalize Self-service Application Integration
Identity security done right includes keeping things as simple as possible. With our latest product launch—PingCentral—we’re making it easier than ever to roll out identity services across your organization. Released October 1, PingCentral provides a centralized IAM operating portal to expose self-service features for many common identity management tasks, freeing up significant time and resources so your teams can deliver even more strategic business value while rapidly modernizing your legacy infrastructure.
5 Steps to Operationalize PingCentral
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:
- Identify use cases and resource priority
- Get PingFederate in shape
- Set up PingCentral
- Use with onboarding team
- Delegate to non-IAM experts
#1: Identify use cases and resource priority
One of the best ways to ensure success with PingCentral is to include the right line-of-business (LOB) stakeholders from the beginning. Sit down with some of your key stakeholders, application teams, app developers, business users and detractors, and interview them to determine their needs and current pain points with IAM services. Get insights on their most common use cases and make sure 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.
It’s also a good idea early on to understand the current limitations of PingCentral. Today, it works with PingFederate only, but PingAccess and PingDirectory support are on the roadmap. Another important point to note is that the orchestration automation helps you move configurations of specific apps among instances of PingFederate in different environments, but it does not automate the rollout and configuration of PingFederate itself; Ping’s Docker images can enable that type of orchestration.
#2: Get PingFederate in shape
One of the most commonly asked questions I receive is what versions of PingFederate work with PingCentral. The answer is that you need to be on PingFederate 9.2 or newer.
Start reviewing your authentication policies in PingFederate and create example clients or SAML connections that use Policy Contract. (It’s how PingCentral does attribute mapping for SaaS.) You’ll also need to ensure consistent configuration of authentication policies, policy contracts and attributes on each target environment of PingFederate. Also, here is a bit more detail on leveraging extended properties in the JSON to templatize your policy trees and selectors:
Additional Attributes from Data Stores
PingCentral doesn’t support making custom calls specific to an app (e.g., an OGNL expression referencing a specific AD 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. Here's the cool thing: Nothing prevents you from mapping additional attributes to that APC and making them available to any application for mapping.
So I would recommend taking all the additional attributes, from whatever data source you need, and mapping those to your policy contract rather than directly to the SP connection as part of the attribute mapping. This is the approach I've seen some of our large customers use to accomplish flexible attribute mapping that is still simple for delegated users to consume. In general, I don't recommend mapping custom data sources directly to an individual application, as this prevents reuse.
Adding Connections to Specific Selectors
This is supported today with PingCentral 1.0 and PingFederate 9.3! PingFederate 9.3 added a new feature 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 9.3 has a new 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 and let us know what you think.
Step 1: Turn on extended properties in PingFederate 9.3.
Step 2: Build your authentication policy to use the Extended Properties selector.
Step 3: Create a client or connection that specifies the extended properties values you want to use in a template.
Step 4: Create a template in PingCentral based off of that client or connection.
Step 5: Now when an app owner creates a new app based on that template, it will be automatically linked to the right APC/selector(s) in your PingFederate authentication policy, without any manual steps needed!
#3: Set up PingCentral
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 that your internal users can log into PingCentral using your established single sign-on. This is set up by configuring an OIDC connection in the 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 PingFederate instances in different environments, such as dev, staging, production, etc. You’ll also need to build 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 API.
Another step that will help accelerate getting up and running with PingCentral is to get the applications that are already in PingFederate into PingCentral, and provision the right application owners for these existing apps. This can be done manually, but we recommend doing it through a script.
#4: Use with onboarding team
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 normally 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 that you’ve configured.
Once the team is up to speed, then everyone on the onboarding team—yes, even you—should try using PingCentral to fulfill app teams’ requests for a set period of time. Log 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 at least 80% of 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
#5: Delegate to non-IAM experts
Now it’s time to start delegating administration to your business stakeholders 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 app 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.
Webinar: 5 Simple Steps to Transform Your Business
On November 12, I presented a webinar with Dan Ricke, Information Security Manager for Cyber Security Technology Services at BlueCross BlueShield of Tennessee, sharing this 5-step map to operationalizing PingCentral.
In this webinar, Dan gives you a glimpse of their actual plans to roll out PingCentral, freezing their internal automation/customization roadmaps in favor of leveraging PingCentral’s powerfully simple templates and APIs. Click here to watch the webinar replay.
