Im quite new to KeyCloak and we are trying to set up a KeyCloak for our developed applications at our organisation.
We currently have a Shibboleth (SMAL) identityprovider and would like to use this idp for SSO logins.
Have successfully deployed KeyCloak on our test kubernetes-cluster and added the keycloak metadata to our idp and added the idp to KeyCloak.
The idp should be set up to release attributes to the KeyCloak (a colleague helped me with the Shibbloeht idp part…)
We are able to initiate a login from KeyCloak and login from the idp but when returning to KeyCloak we get ‘invalid requester’
In the log we get
12:42:35,495 ERROR [org.keycloak.broker.saml.SAMLEndpoint] (default task-314) no principal in assertion; expected: ATTRIBUTE(eduPersonPrincipalName)
Have tried to add mappers for the identityprovider in KeyCloak and different settings for the ‘Principal Type’ and ‘Principal Attribute’ but nothing seems to work… As I said, Im quite new to this and have tried to search for answers and read the documentation but cannot make sense of this…
Could someone please help, how should we configure KeyCloak to receive the attributes from the idp and create / update the user in KeyCloak?
Update, added (updated) mappers for all attributes, eduPersonPrincipalName, displayName… and now when I set ‘Principal Type’ to ‘Subject NameID’ we actually get a form to fill in username, email, first name, last name.
But Username is prepopulated with some hashed or encrypted data… “AA…==” and rest of the form is empty…
Would be great if the form would be populated with data from the idp or directly imported, can that be done, what are we missing?
I also connected a KC to Shib. In KC, I have configured a mapper of Type “Username Template Importer” with configured template value ${ATTRIBUTE.urn:oid:1.3.6.1.4.1.5923.1.1.1.6} which should contain the eduPersonPrincipalName, if your Shib follows standard attribute naming. This does the job to fill the KC’s username with shib’s eppn. You should make shure that the eppn of user never chenages and will never be reassigned to other users. Principal Type Subject NameID should be ok for shib with persistent naming. The cryptic value then is used to link the KC’s users to the shib users.
The eppn should never change / be reused so thats good.
Tried to use the template and now the form is completely empty, and according to my colleague we use “urn:oid:1.3.6.1.4.1.5923.1.1.1.6” for eduPersonPrinicpalName.
I created this Flow to simplify things for my setup. Maybe it is worth to mention, that I hafe sync mode “force” in de IDP Configuration and do not allow users to edit their Attributes. In Realm settings → Login, I have “Duplicate emails” = ON, all others are OFF. I use the classical user model, not the new one, maybe that’s relevant…
I dont think I get the attributes correctly, either there is something missing from the Shibboleht idP or there is something missconfigured in the KC…
Could “NameID Policy Format” have anything to do with the attributes, what should that be set to?
You should check if Shibboleth IdP releases the requested attributes correctly. If I remember correctly, you can see the SAML assertion XML by running keycloak with debug log level.
Have you tried another standard attribute linke Mail, can you import it?
The subject NameID of the SAML data is the (individual) user ID Shib generates for its service providers. It is used to link the Shib’s user to the KC user. Persistent is a good option here. It is separated from the rest of the user’s SAML attributes and has nothing to do with them.
Here’s my KC broker config for the Shibboleth IdP if that helps…
Thanks a lot for the help!
It seems to have been a combination of configuration in keycloak and the idp.
After some changes to the idp as I was told there was some mismatch in the configuration and with the debug enabled in keycloak I saw friendly attribute ‘eduPersonPrincipalName’. So then I could used " principal: Attribute friendly name ‘eduPersonPrincipalName’"
two questions, in the debug it looks like you are using Keycloak running on your server, not in a container. is that right? Second, could you share the overview of all the parts needed for this? Looking in the documentation, I’m not clear if a client is needed for the idp broker and what that client would be. Or any other parts-groups/roles etc.
We run keycloak on a kubernetes cluster so I actually entered the pod to run the commands with ‘kubectl exec’ then I could view the logs with ‘kubectl logs’, there might be another way to do it but this is the way I used.
Well we are going to use this keycloak as a way to authenticate / authorize against java applications and are currently testing it on a test cluster.
So what we are using is our organisations Shibboleth idP, a kubernetes cluster (rancher k3s) with keycloak installed by helm packaged by bitnami (Helm Charts to deploy Keycloak in Kubernetes).
If I have not completely misunderstood how to use keycloak the idea is to add the applications as clients in keycloak and then be able to use SSO to login with the users normal organisation account.
For now we just successfully logged in to keycloak importing the user, next step is to login to one of our applications.