PingIdentity as on OpenID Connect (OIDC) provider.
In the previous instalments I demonstrated how to implement OpenID Connect (OIDC) applications with Keycloak and AzureAD Identity Platform leveraging Kyma functions.
This brief is to focus on PingOne identity platform acting as an OpenID Connect (OIDC) provider to allow to create OIDC applications for user authentication.
PingIdentity is a popular, enterprise-grade identity management platform.
Kyma functions offer a first class, enterprise-grade cloud native development and workload orchestration experience.
Let’s see how these two can work together in tandem as a powerful cloud native integration instrument.
Putting it all together
The OIDC protocol supports a number of grant types that can be implemented to authenticate a user with the preferred one being the authorization code grant type which is readily supported by PingOne identity platform.
After gaining access to PingOne administration console
1. Create an OIDC application with PingOne identity platform.
|That’s a relatively straightforward operation that you can perform from your PingIdentity admin console using a new application wizard, as depicted below:
A simple 4-step wizard would open inviting you to create application profile, to add redirect uris, to grant user resources access authorizations (scopes) and last but not least to map user authentication attributes like email address, user name etc.
After completing the wizard the newly created application would appear in the applications list.
PingIdentity admin console offers full control over the application’s settings and its life cycle.
Each application can be entirely disconnected (disabled) and/or its settings be amended at any point of time at the discretion of the platform administrator.
Good to know:
|a. Get OIDC provider metadata.||We can discover PingOne OIDC provider metadata by appending the /.well-known/openid-configuration suffix to the provider environment (tenant) path as follows:
Please refer to the following gist for more details.
|b. Retrieve a user JWT with PingOne OIDC provider||
This has been done programmatically. I opted for simplicity and did it in nodejs with the openid-client library as an inline kyma function.
This is shown in the following gist.
|c. Use an API Rule to expose a user JWT kyma function endpoint||
Last but not least let us leverage the power and simplicity of a kyma function…as shown here.
Let’s expose a function’a user JWT endpoint via an API rule and eventually generate a user’s JWT by calling the /openid endpoint as shown here.
Good to know:
- The code snippets and gists are provided “as is”. I personally used this code as a template to help me implement virtually any OIDC provider.
- For the sake of brevity I omitted the refresh token logic from the presented code snippets.
- If you would like to off-load this coding effort you might want to consider existing public libraries for instance: https://github.com/oauth2-proxy/oauth2-proxy
- For any production use the API Rules must be protected with for instance… a JWT token.
I hope you have enjoyed reading this blog. As usual, you may include comments in the comments section below.
PingIdentity resembles to some extent our own SAP IAS. For instance, applications and users management are quite a straightforward task. It is also easy to upload your own certificate keypairs for SAML assertion signing and/or encryption.
Furthermore, the concept of an environment can be assimilated to a SAP IAS tenant.
As the PingIdentity trial period is relatively short I did not have time to explore its more advanced features like for instance the federation or the on-premise LDAP connectivity.
Overall, all the concepts and terminology from the pingOne documentation are rather consistent and comparable to the experience you may have gained with other identity platforms like: SAP IAS, Okta, Keycloak and AzureAD, etc…
I did not find any simple way to add my own public x.509 certificate keys to the predefined JWKS array of my OIDC application.
Apparently that’s somehow doable with the Ping Federation server
On the other hand a custom certificate keypair can be easily assigned to a SAML application for either assertion signing and/or assertion encryption.