I've just happened to notice that using
springSecurityService.reauthenticate(userid, password)
for manual user authentication (in a controller) succeeds regardless of the value for password, i.e. correct password, wrong password, null password, etc.
Am I missing something?
The declaration of springSecurityService's method is
void reauthenticate(String username, String password = null)
so at first I was pretty confident that a password check was in place.
Config
Grails 3.2.4
Spring Security Plugin (core) 3.1.1
The reauthenticate method updates the current Security context with UserDetails instance found by the email you provide to the reauthenticate method. It does not perform any validation as it is an internal call. It also removes the user from the user cache to force a refresh at next login.
So if you do not pass the password parameter, it is going to use the password from the UserDetails instance and set the authentication context with these details.
Have a look at the code here
I hope this helps.
Related
I use AWS Cognito as the authentication provider in a React application. I noticed an issue with the Reset Password flow:
Imagine I forget my password and request a password reset. Cognito sends me an email with a security code. Then, I remember the password and don't want to change it any more. I can't because even if I log in with the correct password, it still sends me to the Set New Password page. It seems like a security concern because anyone can force other users to reset their password as long as they know their email address.
Is that by design in Cognito or is it a bug in my use of Cognito?
You will want to verify how the forgot password/authentication flow have been implemented within your app. The Reset Password page should not send the NEW_PASSWORD_REQUIRED MFA challenge, nor change the user's status to need a new password in the user pool.
The ForgotPassword API call generates the reset code for the user, whereas the ConfirmForgotPassword API call accepts the code and allows the user to change the password. These API calls do not change the user's status for resetting their password, or create the NEW_PASSWORD_REQUIRED MFA challenge.
For completeness, there is no way to cancel the password reset code once it's been sent out. The code is valid for 24 hours, although sending another code will invalidate the first.
I am using WSO2 Identity Server 4.1.0 to perform basic authentication. It is possible to call the AuthenticationAdmin webservice, which contains a 'loginWithRememberMeOption'. The user will then obtain a 'rememberMeCookie', with which he can log in, even if his session (JSESSION) has expired.
I have learned that the loginWithRememberMeOption also has a timeout: 7 days, and that this time cannot be modified: WSO2 Authentication, adding/modifing timeout to the RememberMe cookie
The AuthenticationAdmin service also provides a 'logout' operation. Unfortunately, this operation will only invalidate the session. So if a user has a rememeberMeCookie, he will still be able to login: WSO2 AuthenticationAdmin Logout
The question is, how do I logout a user that has obtained a rememeberMeCookie? Preferably using the AuthenticationAdmin?
As I understand there is no direct way to logout a user with a remember me cookie.
I went through the code. Once you login with remember me option, a UUID is generated. Refer org.wso2.carbon.core.services.authentication.AuthenticationAdmin.loginWithRememberMeOption(String, String, String) method in AuthenticationAdmin
The cookie is then saved in database. When you login with remember me cookie, the cookie is checked from the user store. Refer org.wso2.carbon.user.api.UserStoreManager.isValidRememberMeToken(String, String). You can check the JDBC implementation.
So, in order to logout, you might have to clear the cookie from the user store.
Please report a JIRA issue, if you think it might be useful to add a method to clear the cookie.
I'm using openDJ LDAP server for authentication process of a Java based project using JNDI.
Most of the other things like password expired, invalid credentials can be handled using exceptions. (using the understandable message in exception, or using the error codes in some occasions)
ds-cfg-force-change-on-add and ds-cfg-force-change-on-reset attributes are set to true in the password policy.
But when a newly created user logs in or, when a user logs in after a password reset by admin no exceptions occur.
Can somebody tell me how to handle this.
One alternative in this case is the password policy request and response controls (example) defined in draft-behera-ldap-password-policy, supported by OpenDJ LDAP SDK and other SDKs. You pass the request control to the directory server, and you get back a response control.
The response control indicates whether the password needs to be changed, why a requested password modification could not complete, how much time remains before expiration, etc.
I'm using the Auth module for managing users inside Kohana.
When I use the login($username, $password, $remember) method it succeeds validating the user but then when I ask if the users is logged in (logged_in() method) it returns false.
What am I missing here?
Thanks in advance.
The only thing logged_in does for the default Auth driver is check if there is an active session with a proper key that points to a logged in user.
Your question is too global to be able to give a direct answer, but it might be that the problem stems from improper Cookie settings. Your session will always be saved in a Cookie and if the cookie path and/or domain are not properly setup, then the session will be invalid and Auth::instance()->logged_in() will return false.
Check this link for setting up cookies in Kohana: http://kohanaframework.org/3.2/guide/kohana/cookies
I am setting up my own CAS. A authentication handler was written and username/password are authenticated against a MySQL db. I also add signup page and related logic.
Now I would like to let user automatically log on when he/she has registered as a user. How to achieve this?
The comment above is incorrect - CAS clients do not have access to the cookie, only the CAS Server does - CAS is not a shared-cookie protocol.
If you only have a single site, you can just create a session on the client, using the standard mechanisms for Java, Ruby, whatever platform you're using.
If you want to create an SSO session for login to multiple applications, basically you need to:
Create a SSO session (via the CAS server)
Redirect to the CAS Server
Have the user redirected back to your application.
To accomplish the first one, you likely will want to modify the CAS LoginFlow to allow you to authenticate the user, either via one-time token or a similar mechanism.
Here is my implementation. The idea is borrowed from class org.jasig.cas.web.flow.AuthenticationViaFormAction.
In my web controller handling unlock request which is often from a registration email of a new user.
String oneTimeAuthToken = this.userManager.generateOneTimeAuthToken(userEmail);
UsernamePasswordCredentials credentials = new UsernamePasswordCredentials();
credentials.setUsername(userEmail);
credentials.setPassword(oneTimeAuthToken);
String tgt = centralAuthenticationService.createTicketGrantingTicket(credentials);
ticketGrantingTicketCookieGenerator.addCookie(request, response, tgt);
log.debug("Current user was unlocked and logged in.");
The fundamentals behind this is to create a temp password-like token to authenticate. Of course, userManager should clear this token automatically once authentication is successful.
Hope this is clear. Let me know if you observe anything wrong.