-
-
Notifications
You must be signed in to change notification settings - Fork 15
Wrong user used in second step #14
Comments
Hey @cornelinux ! Thanks for the report! I'll look into that and try to tied the realm/username to the corresponding "session". A hidden HTML form field can be a feasible solution. Thank you for that suggestion! 😉 |
Hi sbidy, I was working/debugging with cornelinux on this issue. Let me know if you need me for any testing etc, as I have a team of 25 colleagues more or less just sitting and waiting to test (and use the plugin when it works) this plugin for ADFS/privacyidea. Thank you in advance! Best regards, |
I'm still working at the issue at the moment 😉 ... maybe a fix is coming today. |
…alm to the ID3A. Version riesd from 1.3.2 to 1.3.3 - install script also updated with new version!!
Please check the 1.3.3a version - I added the username and realm to hidden input fields and use this for the OTP request to the ID3A. This should fix the problem. !! -> the install script should be updated too (changed version number) !! |
Hi @sbidy
I think it must be session_user in the parameters and not username .Thx Cornelius PS: I added a quick pull request :-) |
Bug fixed with last commit but still not in the last release (1.3.3). |
Hi @sbidy |
Sorry for the delay 😞 ... pre-Christmas-stress 🎄 ... |
We realized that a wrong username can be used in the authentication request of the second step.
We configured a service account to do triggerchallenge to send SMS.
Observation
We observe the following:
UserA enters his windows credentials. We see a
validate/triggerchallenge
call in privacyIDEA for UserA. The user receives the SMS on his phone.On another browser a UserB enters his windows credentials. We see a
validate/triggerchallenge
call in privacyIDEA for UserB. The user receives the SMS on his phone.Now UserA enters his OTP value. But now an API call is sent to privacyIDEA
validate/check
with the username UserB. Of course authentication fails.Analysis
Obvious the
IdentityClaim
you are using are not bound to the right session or is only a current snapshot.The
username
is currently defined as a member variable of the Authenticator Class. Obviously ADFS does not create a new instance of the class on each request or the variable is shared over all instances.privacyIDEA-ADFSProvider/privacyIDEAADFSProvider/Adapter.cs
Line 22 in f7823a0
Thus the second user trying to authenticate will overwrite the username causing the first user fail to login.
One possible solution
I think a possible solution could be to add the username and realm as hidden fields to the login form and also read the username from the HTTP request just like the otp value.
Please drop me a note, if you need any more information or assistance.
The text was updated successfully, but these errors were encountered: