Technical Articles
Keycloak. An open source IAS with SAP BTP, Kyma runtime.
|
|
  |
Keycloak.org. The Open Source (IBM/Redhat) Identity and Access Management with SAP BTP, Kyma runtime. Keycloak can be deployed in a variety of ways. I opted for the container deployment. First I tried out a docker deployment. That’s very simple but I ended up having an IAS running locally on my laptop. That was not ideal. Eventually I chose to deploy it with SAP BTP, Kyma runtime. which is the SAP’s managed kubernetes cluster offering. That was even simpler and virtually required almost no effort but locating the deployment yaml file in the keycloak public quick-starts github repository. |
Good to know:
|
Keyclock as a public cloud Identity and Access Management service.
|
After the successful deployment the only thing left was to create an API rule to expose the keyclock admin console to the public internet. Once logged into the admin console you may want to change the admin password. Then you are required to create a realm to host your client applications (=your service providers). Good to know:
If you are familiar with setting up a trust with any other IAS like SAP IAS, Azure AD, etc you will quickly understand how to set up your clients and establish trust between keycloak as the IdP and your SPs. There is one feature however, that caught my attention, namely the encryption of saml assertions. It is turned on by default, so if your trusted application does not support encryption with saml assertions you may need to turn it off. Good to know:
|
Adding your own provider keypair.
In order to make it a little bit more realistic first I added my own keypair with my own x509 certificate (and its private key) to sign the saml assertions with.
After having done this my own x509 provider key will be included in the exported keycloak saml metadata.
Establishing trust (SAML WebSSO).
To start with, I set up the trust between keycloak and SAP BTP Cloud Foundry sub-accounts. That was really very straightforward and was down to exchanging the saml metadata descriptors between a keycloak realm (=IDP) and a CF sub-account (=SP) as depicted below:
Having keycloak trusted on a sub-account level the trust is automatically extended to the likes of kyma runtime console and subscriptions like SAP Integration Suite and Business Application Studio on the subaccount level.
Last but not least, I also set up keycloak as the SAML WebSSO identity provider with the likes of SAP Analytics Cloud and SAP Live Data Connector.
In either case it was super simple and uneventful.
Good to know:
- Having your own x509 provider offers you the possibility to re-use it for other authentication and authorization flows like for instance the OAuth2SAML bearer assertion flow. This will enable you to sign your own SAML bearer assertion tokens with the same provider as the WebSSO SAML responses produced by keycloak.
That will also make housekeeping and rotating of x509 providers an easier task going forward.
As an example we can show it with SAC App Integration (left) and a CF sub-account (right):
Next steps.
|
As Keycloak supports OpenID connect protocol with the implicit flow I shall be exploring ways of achieving of an automatic OIDC login following a successful SAML WebSSO login. The rationale behind is to be seamlessly able to obtain an already logged user’s JWT token that can be further used to propagate that user’s identity. |
__________
Further reading.
Keycloak SAP blogs
Quovadis SAP blogs |
