Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

PingIdentity as on OpenID Connect (OIDC) provider.

quovadis
Product and Topic Expert
Product and Topic Expert
‎02-21-2022 1:54 PM























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.



Pre-requisistes:

  • Access to Kyma runtime on SAP BTP (Free-tier, Free-trial, etc.)

  • Access to PingOne identity platform (https://www.pingidentity.com/en/support/faq.html#trial)


Disclaimer:

  • The ideas presented in this blog are personal insights thus not necessarily endorsed by SAP.



  • This is not a tutorial. Please note all the code snippets and gists are provided “as is”.

  • This is a playground only. All the x509 certificates, bearer access and refresh tokens and the likes have been redacted.

  • Images/data in this blog post may come from trial sandbox, sample data, or demo systems. Any resemblance to real data is purely coincidental.

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:

Goto Connections/Applications/New Application/Advanced Configuration/OIDC Configure:



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.

On a side note, you may watch any public youtube video describing this process for instance:




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:

  • PingIdentity supports OpenID connect protocol with a variety of grant types to authenticate users (authorization code, implicit, client credentials, etc.)

  • Different grant types can be combined together.

  • As we have enabled the authorization code grant type, we need to provide a redirect URI.




















WHAT HOW
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.


Conclusion


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...

 



Troubleshooting


Caveats:

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.



 

Labels:
Labels in this area
Popular Blog Posts