Returns ExtendedGeorchestraUser
object when createUserInLdap
set to true
#114
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.
Considering the following configuration scenario:
createUsersInGeorchestraLdap
set to trueThen the resolved
GeorchestraUser
should be anExtendedGeorchestraUser
, in order to have a behaviour coherent with the geOrchestra LDAP authentication (via the classic login form provided by the gateway).Without doing so, users externally authenticated will resolve as a classic GeorchestraUser, leading to missing http headers and breaking some geOrchestra applications (e.g. datafeeder, which requires the
sec-orgname
provided only when resolving to anExtendedGeorchestraUser
).This also refactors the
LdapConfigProperties
toGeorchestraGatewaySecurityConfigProperties
, as the object is not only about LDAP, but also nests some other configureable features (OIDC, ...).Documentation has been updated to describe / explain the behaviour.
Tests:
IMPORT
role, being externally authenticated, I was able to import a dataset following the datafeeder wizard.