Sorry. From you answer it seems indico uses uuid internally, but the ldap search filter is always based on email.
Is there any search for ldap groups with the uuid attribute, in ldap search filter?
I think you are misunderstanding something: If a user logged in via LDAP, Indico has their UUID. This will be used for the group membership check.
We make am additional call to find other UUIDs related to emails the user has on their account, but as long as one check succeeds that’s fine!
Ok, I understand.
Maybe something related to our configuration? We use shibboleth for auth and ldap for authorization and groups. This is our config:
# Authentication and Authorization
_ldap_config = {
'uri': '********************',
'bind_dn': '*************',
'bind_password': '**************',
'timeout': 30,
'verify_cert': False,
'page_size': 1500,
'uid': 'infnUUID',
'user_base': 'ou=people,dc=infn,dc=it',
'user_filter': '(objectClass=person)',
'gid': 'description',
'group_base': 'ou=groups,dc=infn,dc=it',
'group_filter': '(member=*)',
'member_of_attr': 'memberOf',
}
AUTH_PROVIDERS = {
'shib-sso': {
'type': 'shibboleth',
'title': 'INFN-AAI',
'attrs_prefix': '',
'callback_uri': '/login/shib-sso/shibboleth',
}
}
IDENTITY_PROVIDERS = {
'ldap': {
'type': 'ldap',
'title': 'LDAP',
'ldap': _ldap_config,
'mapping': {
'first_name': 'givenName',
'last_name': 'sn',
'email': 'mail',
'affiliation': 'o',
'phone': 'telephoneNumber'
},
'trusted_email': True,
'default_group_provider': True,
'synced_fields': {'first_name', 'last_name', 'affiliation', 'phone', 'address'}
},
'shib-sso': {
'type': 'shibboleth',
'title': 'SSO',
'identifier_field': 'REMOTE_USER',
'mapping': {
'affiliation': 'o',
'first_name': 'givenName',
'last_name': 'sn',
'email': 'mail',
'phone': 'telephoneNumber'
},
'trusted_email': True
}
}
Thanks
Ah, I see the problem. Since the Shibboleth and LDAP providers are separate, you will never have a user where you have the UUID associated with the LDAP provider, even if they are the same in the end (indico cannot know this).
So in your case it will indeed only match via email, since that’s the only “generic” attribute it has that works across providers…
Ok. So the only way is to keep the indico email updated at every login. How can we do this?
There’s no option to sync emails.
I think if all your Shibboleth users are on LDAP, the best option would be to link the Shibboleth auth provider to the LDAP identity provider in order to have the proper UUID-based link in Indico, which would make the email lookup obsolete. If you want I can share an example how to configure this… Is the REMOTE_USER from shibboleth the same as the UUID you have on LDAP?
REMOTE_USER of shibboleth is the same as the ldap infnUUID. It would be great if you sent us the configuration example.
Could you help us with the right configuration? Thank you a lot
Try this:
# Authentication and Authorization
_ldap_config = {
'uri': '********************',
'bind_dn': '*************',
'bind_password': '**************',
'timeout': 30,
'verify_cert': False,
'page_size': 1500,
'uid': 'infnUUID',
'user_base': 'ou=people,dc=infn,dc=it',
'user_filter': '(objectClass=person)',
'gid': 'description',
'group_base': 'ou=groups,dc=infn,dc=it',
'group_filter': '(member=*)',
'member_of_attr': 'memberOf',
}
AUTH_PROVIDERS = {
'shib-sso': {
'type': 'shibboleth',
'title': 'INFN-AAI',
'attrs_prefix': '',
'callback_uri': '/login/shib-sso/shibboleth',
}
}
IDENTITY_PROVIDERS = {
'ldap': {
'type': 'ldap',
'title': 'LDAP',
'ldap': _ldap_config,
'mapping': {
'first_name': 'givenName',
'last_name': 'sn',
'email': 'mail',
'affiliation': 'o',
'phone': 'telephoneNumber'
},
'trusted_email': True,
'default_group_provider': True,
'synced_fields': {'first_name', 'last_name', 'affiliation', 'phone', 'address'}
},
}
PROVIDER_MAP = {
'shib-sso': {'identity_provider': 'ldap', 'mapping': {'identifier': 'remote_user'}}
}
We have this error at login:
2021-07-13 14:19:26,940 ERROR fac20b236ce74961 indico.flask REMOTE_USER
Traceback (most recent call last):
File "/opt/indico/.venv/lib/python2.7/site-packages/flask/app.py", line 1950, in full_dispatch_request
rv = self.dispatch_request()
File "/opt/indico/.venv/lib/python2.7/site-packages/flask/app.py", line 1936, in dispatch_request
return self.view_functions[rule.endpoint](**req.view_args)
File "/opt/indico/.venv/lib/python2.7/site-packages/indico/web/rh.py", line 324, in wrapper
return cls(partial(func, *args, **kwargs)).process()
File "/opt/indico/.venv/lib/python2.7/site-packages/indico/web/rh.py", line 275, in process
res = self._do_process()
File "/opt/indico/.venv/lib/python2.7/site-packages/indico/web/rh.py", line 245, in _do_process
rv = self._process()
File "/opt/indico/.venv/lib/python2.7/site-packages/indico/web/rh.py", line 316, in _process
rv = self.func()
File "/opt/indico/.venv/lib/python2.7/site-packages/flask_multipass/util.py", line 123, in decorator
return func(*args, **kwargs)
File "/opt/indico/.venv/lib/python2.7/site-packages/flask_multipass/providers/shibboleth.py", line 70, in _shibboleth_callback
return self.multipass.handle_auth_success(AuthInfo(self, **attributes))
File "/opt/indico/.venv/lib/python2.7/site-packages/flask_multipass/core.py", line 213, in handle_auth_success
identity_info = provider.get_identity_from_auth(auth_info.map(mapping))
File "/opt/indico/.venv/lib/python2.7/site-packages/flask_multipass/data.py", line 52, in map
raise KeyError(next(iter(missing_keys)))
KeyError: u'REMOTE_USER'```Try remote_user instead, I just realized we convert those keys to lowercase in the shibboleth auth provider.
Great, it works but asks confirmation of new account to user. Is it possible to avoid this confirmation at login?
Yes, update all existing identities to point to ldap instead of shib-sso.
Running this in indico shell should do the job:
for identity in Identity.query.filter_by(provider='shib-sso').all():
if not any(id.provider == 'ldap' for id in identity.user.identities):
identity.provider = 'ldap'
db.session.commit()
OK it works!!! Thank you very much for everything
Just FYI, Indico 3.0 supports native SAML (without the need for Apache/shibd) and the usecase we talked about here is covered in the docs.