LDAP identity provider: fix support of an associated Shibboleth auth provider

[jouvin]

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. The problem is that the LDAP identity provider requires the user to exist in LDAP to create its identity, something that is not true if remote users are authenticated through Shibboleth (e.g. eduGAIN).

The original approach to fixe the issue was by addding a new identity provider boolean configuration parameter, auth_data_if_identifier_missing: if True, create the identity from the AuthInfo object (returned by the Shibboleth auth provider) if the user is not found in LDAP. When False, the identity provider behaviour is unchanged. After some discussion it was decided to implement basically the same code as a variant of the LDAP identity provider that fallbacks to AuthInfo contents if the identifier cannot be retrieved from LDAP.

**Note: for this configuration to work, it is also necessary to define the attribute to use to build the identifier, adding an entry in PROVIDER_MAP that defines it, with something like:`

# shib-sso is the Shibboleth auth provider, ldap is the LDAP identity provider
'shib-sso': {'identity_provider': 'ldap', 'mapping': {'identifier': 'mail'}}

This PR has been tested successfully at IJCLab.

[jouvin]

@ThiefMaster I decided to add the support for non local users as an option in the standard LDAP provider as it is really a one line difference. I think it could interest others. It is not clear for me if we should also set support_get and support_refresh to False when accepted_users=all.

[ThiefMaster]

This isn't needed in the end, because you can rename fields via the auth-to-identity-provider mapping. See this Indico forum post for an example

[jouvin]

@ThiefMaster I updated the PR (and its description) to remove the identifier_field parameter handling from the original PR as an alternative way of doing it exists as you said in #42 (comment). But I believe the other part of PR is still required if you want to be able to support remote users through Shibboleth/eduGAIN. Unfortunately I cannot reopen the PR and thus the updated source branch is not reflected here...

[ThiefMaster]

I think the PR can be reopened if you force-push commit 6489fd9 to the branch (since that was the last commit before it was closed). Once it's open you can force-push your new commit again.

git push -f whatever 6489fd9f2:ldap_configurable_identifier

[jouvin]

It is what I did... but it seems it was not enough... Is it because I also rebased on the last master?

[ThiefMaster]

Yes, you need to push that exact commit to the branch. Then I can probably reopen it (you probably can't do it yourself since it was closed by a maintainer). Afterwards you can rebase and forcepush as much as you want again.

[jouvin]

Ah ok, I misunderstood...

[jouvin]

Done!

[ThiefMaster]

there we go, now you can forcepush your latest version

[jouvin]

I push a new approach to the problem described, as per our offline discussion, that implement by default the access_useres=all behaviour, without the need of an additional parameter. It provides a new variant of the LDAP Identity Provider that can be selected with identity type ldap_shibboleth.

Test in progress at IJCLab...

[jouvin]

Test done successfully at IJCLab (rebuilding manually the wheel after cherry-picking the commit on top of v0.4.9).

[ThiefMaster]

great, let's just apply the name change i mentioned on mattermost and this is good to go

[jouvin]

Names for class and identity provider type updated (as well as the comment) to make it more general...