Use username mapper to resolve username when creating a default user #40
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.
This pull request originates from the situation where I had the
force
option enabled in the firewall and then wanted to control the username resolving by setting my own list of attributes on thelight_saml_sp.username_mapper
configuration.This wasn't working and it turned out that the username mapper was never used when the
LightsSamlSpAuthenticationProvider
wants to create a default user. In fact, the logic used in thecreateDefaultUser
method looks very similar to the logic of theSimpleUsernameMapper
. As far as my interpretation of this bundle goes there's no necessity why this logic should be duplicated and could possibly cause unexpected behavior, as described above.That's why I'm proposing to use the username mapper for resolving the username when a default user should be created. In my opinion this change has three main benefits:
SimpleUsernameMapper
, this will most likely not affect current implementations.Would like to know what you think of it!