Rate this page

Ping Identity Data Governance Broker Client Developer Guide

In this guide, we’ll discuss what you need to know to write applications that take advantage of the Ping Identity Data Governance Broker’s authentication and resource server capabilities.

What is the Data Governance Broker?

The Ping Identity Data Governance Broker is really two sets of services in one:

  • An authentication server with a rich set of features, from simple username/password login, to social login using popular identity providers such as Facebook and Google, to multi-factor authentication using one-time passwords.
  • A resource server providing APIs for accessing and managing user data, as well as related data.

Both services are backed by a powerful policy engine that ensures that your organization’s access control rules are enforced consistently. By centralizing both user data and access control logic, the Data Governance Broker:

  • Shifts complexity away from your applications, allowing you to focus on your specific requirements as a developer.
  • Reduces your organization’s security and privacy risks.

And by providing a single, consistent view of user data, your application is insulated from schema changes in the backend data stores where the user data resides.

What does this mean for your applications? At a high level, the Data Governance Broker allows your applications to:

  • Authenticate end users using the OpenID Connect standard.
  • Authorize your applications to access user data using the OAuth 2 standard.
  • Work with user data using a rich set of simple APIs based on the SCIM standard.

First concepts

From a client protocol perspective, the Data Governance Broker’s authentication server is an OpenID Connect provider. A Data Governance Broker client only needs to know how to formulate an OpenID Connect request and how to interpret the response. All details of authenticating a user are handled by the authentication server.

The Data Governance Broker’s resource server is a SCIM provider. Using an access token obtained during authentication, a Data Governance Broker client can search, create, update, and delete user data and related data using the simple SCIM REST API.

Behind the scenes, the Data Governance Broker acts as a bridge to user data stored at the user store. The user store may be comprised of multiple data stores of arbitrary types, though an LDAP-based Ping Identity Directory Server always acts as the primary data store to handle password-based authentication. These details are irrelevant to applications, however, which need only interact with the Data Governance Broker through its simple OpenID Connect and SCIM APIs.

Data Governance Broker architecture

A Data Governance Broker may interact with other external systems. For example, the Data Governance Broker may allow a user to authenticate using an account hosted by an external identity provider, such as Facebook. Or the Data Governance Broker may require users to provide a second authentication factor by verifying a one-time password code sent via Twilio. Again, these interactions are handled by the Data Governance Broker so that your application can focus on its own business logic.

Let’s take these terms and break them down into a table of actors. We’ll be referring to these entities throughout the documentation.

Actor Description
Client Also called an application or a relying party. This is the software that you write. It relies upon the Data Governance Broker’s services to provide some benefit to your end users or your organization. Typically, it needs the Data Governance Broker to authenticate a user, and it needs to read or modify data belonging to the end user on that user’s behalf.
End user Also called an identity or a resource owner. An end user is the subject of an applications’ requests to the Data Governance Broker. The Data Governance Broker asserts to an application that an end user is who she says she is, and it acts as a gatekeeper to that user’s data.
Authentication server In some contexts, this is also called an authorization server or an identity provider. An authentication server securely confirms an end user’s identity, acting as a single sign-on service for applications. It also authorizes an application for access to user data.
Resource server A resource server serves data to clients, typically data belonging to end users. Using authorizations granted by the authentication server in the form of access tokens, the resource server ensures that data access is limited according to organizational policies and end user consent.
User store The data store or collection of data stores containing user data or other data. The Data Governance Broker acts as a gateway to this data.

Next steps

To continue learning about the Data Governance Broker, move on to Basics. This includes a Quick Start guide, which will show you how to install and set up a Data Governance Broker for development.

Read the API references if you’d like to explore the Data Governance Broker’s APIs in detail.