Hi,
We have a setup where users authenticate through eduGAIN (Shibboleth auth provider) and identities are retrieved from AD LDAP (LDAP identity provider, in fact the new ldap_or_authinfo variant implemented in Flask Multipass 0.5.2). So far we have been mapping eduGAIN users to LDAP identities by using the email retrieved from AuthInfo to match a LDAP/AD identity using the mail field in AD/LDAP. Because this email is not necessarily the real email of the user (for some reason, it can be a deprecated but still working email), I’d like to move this email used for matching identities and use another LDAP attribute, physicalDeliveryOfficeName. It is easily done by defining in the LDAP identity provider configuration the mapping for email as physicalDeliveryOfficeName.
The problem is the group membership resolution. From what I have seen (and was explained by @thief in several posts), it relies on a user having one of his identifiers matching the email (or uid?) of a LDAP user where the email is the mail attribute. How this will work if the email retrieved from eduGAIN is not matching the mail attribute value (but the physicalDeliveryOfficeName)? Is the AD email stored in the identity when the identity is resolved?
I made a few tests but could not come to a definitive conclusion as it is very difficult to disentangle the various matches. The only way to be sure would be to manage to have a failing match for a user but I didn’t succeed to have one!
Thanks in advance for any light on this!
Michel
Hi,
Despite some progress (thanks to offline discussions with @ThiefMaster !), I’m still struggling with some of our users after doing the change described above. During my tests before the change I was able (I thought I was!) to assess that the email matching was using the LDAP attribute defined for Indico email aattribute, in our case (in the mappings section of the identity provider):
'email': 'physicalDeliveryOfficeName',
But I have a user failing to get the access honoured since the change and I was only able to restore its access by restting the LDAP mail attribute to its previous value. For this user no identifier was matching the LDAP mail attribute (only the physicalDeliveryOfficeName) and the Indico username was different from the AD userid.
Reading LDAP groups authorization, I tried the different checks suggested and was surprised to see that the member list of the group involved in the access control cannot be listed, despite it works for hundred of users… Not sure what does it mean but the suggested checks for group membership don’t work even for the users having in fact access to the restricted pages, so it’s probably something different. On the AD side this group is made of nested groups, may be this the reason…
Michel
For the record, the end of the story… Thanks to @ThiefMaster , I realized that to achieve my goal it was necessary to redefine the LDAP attribute used as the Indico uid in the identity provider config, instead of redefining tehe LDAP attribute interpreted as an email. LDAP group membership assessment checks that one of the user Indico identifiers matches the LDAP attribute used an an Indico uid in LDAP users. There is no need to change de email mapping, mail can be kept.
Depending on the auth provider config, doing this change may add a new identifier (with the confirmation question at the first login after the change) to the user account.
Michel