-
Notifications
You must be signed in to change notification settings - Fork 5.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Authenticating SAML user by UserDetailService #7550
Authenticating SAML user by UserDetailService #7550
Conversation
Added support for authenticating a SAML user by UserDetailsService. This enhances the AuthenticationProvider by adding UserDetail metadata to the principal and also set authorities like roles. Closes spring-projectsgh-7465
@herrminni Please sign the Contributor License Agreement! Click here to manually synchronize the status of this Pull Request. See the FAQ for frequently asked questions. |
@herrminni Thank you for signing the Contributor License Agreement! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you very much for contributing. It's much appreciated
I will work with you through this review.
OpenSamlAuthenticationProvider provider = new OpenSamlAuthenticationProvider(); | ||
if (this.userDetailsService != null) { | ||
provider.setUserDetailsService(this.userDetailsService); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like that you can explicitly set it. In addition to this, what if there is a
@Bean
UserDetailsService
in the context. We should pick up that bean too
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hello Fillip,
thank you for your review!
I like your idea of automatically using the UserDetailsService from @Bean
registry, if this is present.
However my implementation of manually setting (or maybe overriding) to a specific UserDetailsService was explicitly intended by me:
This way you would be able to have two different UserDetailsServices at the same time and handle SAML authentication in a different way. For example, you could explicitly create a new User as a sideeffect, if that one was not known in a local database. The other UserDetailsService could be used to only authenticate already known users an authenticate by username+password.
Maybe we could combine your and my idea:
User the spring @Bean
UserDetailsService as default and also be able to overrride it with the method I already included (setUserDetailsService)?
@@ -40,27 +45,43 @@ | |||
public class SecurityConfig extends WebSecurityConfigurerAdapter { | |||
|
|||
RelyingPartyRegistration getSaml2AuthenticationConfiguration() throws Exception { | |||
//remote IDP entity ID | |||
// remote IDP entity ID |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nothing wrong with reformatting as part of a PR.
Would you be able to put that into a separate commit, one that doesn't change functionality, so that reviewers can focus on what actually changed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi Fillip,
I used the suggested formatter config for Eclipse, which is part of spring-security from the file etc/eclipse/eclipse-code-formatter.xml
.
Reverting the automatic formatting for the files I changed would have been too much manual work, and I had many local test-builds that failed because of the formatting. So I decided to commit the files with all the automatic changes from the eclipse-code-formatter that went through the test.
.assertionConsumerServiceUrlTemplate(acsUrlTemplate).build(); | ||
} | ||
|
||
private UserDetailsService userDetailsServiceMockup() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We'd like to keep the samples to bare minimum.
I will work with you to find a better place for this configuration and how to test it (I'm working on that right now)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, it just felt right for me, to add a sample.
Feel free to create a second example, that just uses the UserDetailService.
Let me know, if I can help!
Wow I was looking exactly for it! |
@herrminni are you still planning on working on this PR? |
@mballoni As you can see, I replied to the review comments of @fhanik |
@herrminni Thank you for pointing it out! @fhanik fixing the merge conflicts would be enough for this PR or should we look deeper into some of those feedbacks? |
I think we'll be able to simplify this PR a lot after these two get merged
Those two PRs will get us
Once those two get through, we can rework this one, is that ok? |
Thank you for your quick response @fhanik . Yes, that works for me. I appreciate. |
@fhanik hi! Thank you, I appreciate your patience. |
hi @mballoni - yes, please pick it up. I'll work with you on the review process. |
Can I know when this will be get released? |
@mballoni If you're still interested, take a look at the Oauth2Login implementation. The user details get loaded here[1] Creating an implementation that makes similar choices to this implementation will make the code base easy to follow. I'm closing this PR as the code has diverted away from this. We can attach the work to: [1] Lines 116 to 117 in 3b89754
|
Added support for authenticating a SAML user by UserDetailsService.
This enhances the AuthenticationProvider by adding UserDetail metadata
to the principal and also set authorities like roles.
Closes gh-7465