Microsoft’s Azure/Entra ID documentation is some of the worse I’ve had to deal with.
I already had Azure SSO working with a web application and a potential new customer wanted to see it working with a yubikey. What should have been a simple couple-hour project took me all day. Documentation at Microsoft and yubi were both out-of-date, screenshots had no relation to current reality, and having to sift through information meant for giant enterprises vs just getting a yubikey to work with with a simple account for SSO just was painful…
This was before AI started being useful. I wonder if it would go better now.
It's only in the last few months that Claude and ChatGPT have consistently started referring to it as Entra instead of Azure Active Directory, a name change that happened in 2023, presumably as newer training data has been used in the more recent models.
I've terraformed the Keycloak end of this. I think MrParker's terraform provider might have actually become the default because it's GitHub location is redirected under the Keycloak org. It's extremely good, and makes dealing with Keycloak a lot easier.
The Azure end is a pain and I leave that to someone else. (Sorry Pete)
That's good news. That provider is quite good and is 10000% easier than using kcadm.sh for everything. (I'm surprised the provider is as good as it is given how awful Keycloak's API docs are!)
Man, how true... There were one or two things that I wanted to do outside of Terraform because I didn't want secrets in the terraform state. This involved using terraform to execute a go binary with some parameters. The go program created SAML or OIDC clients, wrote the client ID/Secret to AWS Parameter Store and outputs an External Secrets manifest. Everything was easy apart from the Keycloak part. i ended up getting part of the answer on a Chinese blog which I had to Google Translate, and another on the postman docs (not the Keycloak docs)
I did the same years ago, but with Okta. It was just as much of a pain as it is with Azure.
To complicate things, since this was for Kubernetes cluster auth via a local IdP, Keycloak was an intermediate IdP. This made passing claims and roles even more challenging than usual.
I already had Azure SSO working with a web application and a potential new customer wanted to see it working with a yubikey. What should have been a simple couple-hour project took me all day. Documentation at Microsoft and yubi were both out-of-date, screenshots had no relation to current reality, and having to sift through information meant for giant enterprises vs just getting a yubikey to work with with a simple account for SSO just was painful…
This was before AI started being useful. I wonder if it would go better now.