-
Notifications
You must be signed in to change notification settings - Fork 48
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
Redirect user to Idp or continue flow if already signed in #312
Conversation
…already signed in and re-authentication is required
Hello Felix, thanks for the PR and the effort you put into this. I looked into the issue description that you have provided in #309 and think I get where this is heading to. I see a few challenges with the approach that you have taken in the PR. While I think it may work for your special case (can't say for sure, because of missing tests), for this extension we need to take a broader look at for a more generic solution. I especially see the following:
There are too many open questions for me and I come to the conclusion that this needs a more thorough upfront design. I think this would be a good feature request, indeed. Best regards PS: Please also respect the contribution guidelines for this repository, especially upfront discussion and testing. |
|
||
final UserModel user = authenticationFlowContext.getAuthenticationSession().getAuthenticatedUser(); | ||
if (loginHint == null && user != null) { | ||
loginHint = trimToNull(user.getEmail()); |
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.
This is hard coded to the email address, but needs to respect authenticator configuration. Try to use something like user.getFirstAttribute(context.config().userAttribute())
.
Thanks for your feedback, I'll answer your concerns the best I can.
Makes sense, I'll make sure to add tests once we've agreed on a solution and you are right that it only handles the case where "bypass" login page is configured. The final solution should handle both cases.
So basically a conditional call "attempted" based on if it's required or alternative?
With the solution in this PR it would follow the same flow as if
I don't think this is something that Keycloak injects or checks out of the box when it requires re-authentication, so is this something that should be handled by this extension?
It would have the same issue as when
Do you have any solution in mind to solve this, my main issue with the existing behavior is that the user needs to input their own username when they are already signed in and I don't think that makes any sense. So I'm open to suggested solutions that would solve this and work in more than just my use-case.
Sorry about that, I thought that showing code might clarify the problem I'm facing, it was not intended as a finalized PR. |
@BlackVoid thanks for your reply. I just don't have the time to deal intensively with your comments right now. Give me a few days and I'll come to you with a suggestion. |
With reference to the PR on the Keycloak project (see above), these points are better handled upstream within Keycloak itself and do not need to be implemented within this extension. |
No worries @sventorben, there is no hurry from my side to solve this, just something I discovered while testing various use cases with the extension. Once we have decided on a suitable solution I'd be happy to implement it. |
Implement username persistence on the login form to improve user experience by eliminating the need for users to re-enter their usernames during the reauthentication process. Relates to #312
I'd rather go with something like this: d672d83 I will add some integrations test when I find some time and can add the feature to one of the next releases once done. |
I tried your solution and I think it will work great. One issue I noticed is that the code change breaks when not signed in. In order to try the solution I made the |
Hi @sventorben Just wanted to check when you think your change can be merged and if there is anything I can do to help with getting it ready. |
@BlackVoid I am currently working on a larger refactoring to support some other upcoming features. I need to delay this issue until that refactoring is done and then reapply the changes. I think this should be done by the end of this month, but can't promise for sure. |
Okay, thank you for the update. Good luck with the refactoring. |
Implement username persistence on the login form to improve user experience by eliminating the need for users to re-enter their usernames during the reauthentication process. Relates to #312
Implement username persistence on the login form to improve user experience by eliminating the need for users to re-enter their usernames during the reauthentication process. Relates to #312
Implement username persistence on the login form to improve user experience by eliminating the need for users to re-enter their usernames during the reauthentication process. Relates to #312
Closing this as it should be fixed with #366 |
Solved #309
Trigger redirect to IdP or continue to next authenticator if user is already authenticated and keycloak requires re-authentication ex. when using application initiated actions.
This change results in the user being redirected to the IdP or IdP selection page if or if the user is using a password only, then it's sent to the next authenticator. If it's the username-password form then the user is prompted to enter the password only instead of having to enter the username again.