we have a working SAML2/SSO connector against Entra ID. The contact groups are extracted as claim from the SAML requests and assign users to the contact groups properly.
We have faced a situation when a user is member of a contact group and we’d like to remove the contact group. We have removed the user from the group in Entra ID. But looks like we cannot remove the user form the contact group until the user logs in and the group membership is not updated. There is no sync of groups/users as in case of the LDAP-Connector.
How to deal with such situations, if a user cannot login (left the company etc) and the contact group should be removed?
Thanks, @paulosantanabr!
Please note that we don’t want to remove users but a contact group. And I wonder if user preferences would survive through their removal and recreation. I’d like to avoid this workaround, but thanks anyway for your proposal
Another approach is to modify the SAML connection removing the contact group, in the next connection it would be removed if its managed by the connection. Be aware that custom bookmarks and custom views can be checked in Customize Menu, you can check if the user has created them.
When testing that feature I used the option to “Map value to specific groups” which worked great in our scenario. But getting back to your case, I had this situation in the oposite way, in our environment we need to map contact groups manually but using the SAML connection we need the user to first login to Checkmk to allow the account creation. To avoid waiting for the user we enabled the LDAP integration which creates user during sync and then after applying the needed contact groups we just use the option to migrate users from LDAP to SAML.
We have 33 contact groups and didn’t want to map them manually when we migrated from LDAP/AD to SAML SSO/Entra ID.
I think there are gaps in CMK’s implementation of SAML2-based authentication backend or rather user/group/role management. One is like you mentioned that users are created first when they login. And the other one is how to deal with changed user membership w/o user’s explicit interaction with CMK.
Maybe somebody from the developers could take care of those?
If you would like to suggest an improvement, please consider describing it in the ideas portal, so the Product team could see it, and other users could show their need of the feature by voting for it.
This is not a flaw in CMK’s implementation, it is performing exactly as to how a federation works with either SAML(2) or OpenID-Connect.
When a/the user interacts (as in is required to authenticate) the application redirects the user to the IDP to authenticate via the way it was configured.
After a successful authentication the IDP will send all (configured according to contract) data about the current state of the user.
The Application then ‘absorbs’ this information into its own back-end for use.
As the IDP is the authoritative source the application should create/modify/update the user accordingly.
This is beyond both SAML and/or OpenID-Connect, remember its an authentication- and part provisioning (on interaction) method.
There is no implementation/channel in either method to let an application know if someone leaves a/the company ( ie. delete user in data-sourse).
All because its triggered via a user-login.
If you want to have everything in sync all the time (lifecycle management), then you will have to implement something that dredges the authoritative data-source (like LDAP(s)) with relevant information, and let CMK absorb it from there (potentially via API), or look for an Identity-Management solution which will handle it for you.
If neither is an option then manual removal of ‘company-leavers’ is the only way.
The issue that I can see is rather that I cannot remove not needed contact groups that the users are still members of until they re-login after I have changed their group membership in Entra ID. A solution could be to break this dependency and to force the removal of contact groups in CMK backend anyway.
Ok, i’ll be out on a limb as to what i write below, because my setup/lab env is too small to have faced this, and i’m using RAW Edition.
Question(s):
I am assuming you can not remove a/the contact-group because it still has members?
The users present in those (wanting to remove/obsolete) contact-groups are either ‘dead’ (as in left company), or in the authoritative data-source are no longer a member of a/this group ?
If both the above are true, then manual removal of a/the user in a contact-group created via a/the federation should be possible.
After the contact-group is no longer populated manual removal of the contact-group should then be possible.
From my view (as someone who works with (meta-)directories a (contact-)group is an item that acts like a container, which can have sub-items (subordinates), and to inhibit a mis-click/delete it checks if it has sub-ordinates.
At current i will assume that CMK treats contact-groups and users/members in this way.
If subordinates are present it will not allow you to delete, if no subordinated it will be deleted.
So in this you need to clear the subordinates (members/users) prior to be able to successfully removing a/the contact-group.
For those users still active, once they login (if the federation is configured correctly) it will get corrected.
So in my personal opinion, no harm is done in manually getting rid on them in a to-be-deleted contact-group as they are no longer a member of it in the data-source (Entra ID).
If this is not it, i’d happily look further, but then i’ll need time to setup something on my lab-env to do so.
SAML provides authentication and authorization and if authentication is successful can trigger just-in-time (JIT) provisioning of user accounts, if the user doesn’t exist and the Service Provider (SP)/application(checkmk) permits this to occur.
To support what you are looking for, checkmk would need to support the “System for Cross-domain Identity Management” or SCIM. When SCIM is supported, your IdP will provision and de-provision users and groups in the configured SP/application.
