Shibboleth auth provider: return an identifier if identifier_field params is defined #41
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The Indico documentation suggests that it is a good idea to use an LDAP identity provider, when you have one like AD, with a Shibboleth auth provider, to benefit from the group definitions coming from LDAP. Unfortunately it doesn't work because the LDAP identity provider is expecting the auth provider to return an
identifier
attribute in theAuthInfo
object (as does the LDAP auth provider) but the Shibboleth auth provider doesn't.This PR proposes to use the
identifier_field
parameter, normally used by identity providers, in the Shibboleth auth provider params as an indication that theAuthInfo
identifier
attribute must be defined (with the Shibboleth attributed defined by the value ofidentifier_field
). If this parameter is undefined, the behaviour of the Shibboleth auth provider is unchanged.This PR has been tested successfully at IJCLab. Note that the limitation is that every user authenticated through Shibboleth must has a matching account in LDAP (AD in our case). Supporting authentication for local and remote users through Shibboleth (eduGAIN for example) and using LDAP as the identity provider requires a modification of the LDAP provider (or a custom one) to build the identity from
AuthInfo
attributes provided by Shibboleth when there is no LDAP match...