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's the only deployment file required as the ingress is taken care of by the kyma istio side-car.
You can deploy keycloak on a trial kyma runtime cluster. This makes it very affordable for everyone. However, please consider the content of kyma trial cluster tends to being wiped out every time the extension period of 30 days terminates!
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:
A realm is like a tenant. And this how keycloak supports multi-tenancy.
The master realm should only be used for housekeeping, admin assets configuration (like the admin console for instance.) and realms management.
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:
The encryption of saml assertions is a paid feature of Azure AD and
SAP IAS does not support the encryption of saml messages.
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.