I'm calling a stored procedure to change the username. This works and the username is changed.
After I change the username, Membership.GetUser() returns null. I check User.Identity and it still has the old username and is authenticated.
First I tried calling this function (which is also called when the user first logs in)
public void Authorize(string username)
{
FormsAuthenticationTicket authTicket = new FormsAuthenticationTicket(1, username, DateTime.Now, DateTime.Now.AddDays(5), true, string.Empty);
string encryptedTicket = FormsAuthentication.Encrypt(authTicket);
HttpCookie authCookie = new HttpCookie(FormsAuthentication.FormsCookieName, encryptedTicket);
authCookie.Expires = authTicket.Expiration;
HttpContext.Current.Response.Cookies.Add(authCookie);
}
Then I tried adding Membership.ValidateUser(username,password) before calling the Authorize function (since it's a test account and I do know the password) but it didn't make any difference.
Then I tried this:
FormsAuthentication.SignOut();
FormsAuthentication.SetAuthCookie(txtUserName.Text, false);
I'm confused that after I call FormsAuthentication.SignOut(), the User.Identity.IsAuthenticated is still true. Is that not supposed to be updated until after the page reloads?
I read this http://forums.asp.net/t/939408.aspx/1 which makes me think my problem is User.Identity.Name never getting updated. How do I make that happen?
Membership.GetUser() will only work for an authenticated user. Otherwise, it's going to return null. To verify you're dealing with an authenticated request call "User.Identity.IsAuthenticated" on the page. If you've got an authenticated request, but Membership.GetUser() is still returning null, then that means the username associated with the authenticated user can't be found in the Membership datasource. Verify the username of the authenticated user with "User.Identity.Name".
If you're calling one of the Membership.GetUser() overloads which takes the username and it's returning null, then that user doesn't exist in the Membership datasource (or we've got a bug). One way to easily verify this is to try a Membership.CreateUser() with the same username. If this doesn't throw an error because of a duplicate user, then you know the user never existed in the first place.
Membership.GetUser() should have never worked for an anonymous user. No support was built into Membership for handling this case.
Any changes to the FormsCookie, user account, are not reflected in the User.Identity property until the next request. This property is set by the membership provider at the start of the request when the cookie is validated. Any changes you make will be seen by in any subsequent requests.
You can manually replace User.Identity with a principal of your own, but this requires implementing your own membership provider.
Related
I would like to manually send a password reset request to a specific user (not the one currently logged in) from within a controller. I did some digging around in the Laravel code and it seems like I should be calling postEmail(Request $request) in ResetsPasswords, but I can't seem to figure out how to get access to the right PasswordController instance to call it.
Seems like you are admin, so from your end, you can set a column in database (is_active), and change that to 0, and check when user logged in if is_active == 0. If it's 0, allow him to set a new password, then make a hash of new password and change is_active to 1
I successfully implemented JWT as a authentication filter in my web application. When user's login is successful, I am creating a new JWT and assigning userName in the sub field of JWT.
In the subsequent request's I am using userName in the JWT sub field to identify the user. But what if the user changes his userName in the update section of the application. Is there way, I can update the value of sub field in JWT ?
What I am thinking!
I am thinking of getting the existing JWT in the RestController and after updating the userName, I will update the JWT with new userName and again send back to the client. Is this fine or is there a better approach?
I think I should refresh the token after update is done and send back the refreshed token back to client.
#RequestMapping( value = "/account", method = RequestMethod.POST )
public ResponseEntity<?> updateAccount( #RequestBody UserDetailsBean userDetailsBean, HttpServletRequest request,
HttpServletResponse response )
{
try
{
UserAccessDetails accessDetails = getLoggedInUser();
UserDetailsBean updatedUserBean = userService.updateAccount(userDetailsBean, accessDetails);
// send updated jwt incase of mobile number update by user
response.addHeader(SecurityConstants.HEADER_STRING,
SecurityConstants.TOKEN_PREFIX + refreshJWT(updatedUserBean.getMobileNumber()));
return buildResponse(updatedUserBean);
}
catch( DataException e )
{
return buildError(e);
}
}
private String refreshJWT( String subject )
{
return Jwts.builder().setSubject((subject))
.setExpiration(new Date(System.currentTimeMillis() + EXPIRATION_TIME))
.signWith(SignatureAlgorithm.HS512, SecurityConstants.SECRET).compact();
}
This is working. If anyone has a cleaner and industry standard approach please specify.
If you allow your users to change their usernames, they should also have an immutable user id that can be used to identify any data or activity associated with a given user. Otherwise, any time a user changes his or her name, you will either lose the ability to audit the user's past actions or you will have to update all references to that username in the database. What's worse is if there are references to an old username in the database and another user takes that username -- now you have data from one user now being associated with another due to incorrect handling of user identification.
Now with that said, the sub claim should contain this immutable user id. You can create a separate claim for the mutable username. When a username is changed, you now only need to change a single field in the database (assuming that only the users table references this mutable username). You could then use the refresh token retrieve a new token that would contain the latest username that could then be used by your API as needed.
Using this approach, you should be careful to only use the username claim for display purposes, not for identifying the logged in user due to the fact that it is mutable. The sub claim containing the user id would serve the purpose of identifying a user.
It is also important to note that this solution requires no special logic for "updating the sub claim." You would be using the same logic that you're already using to generate a token for a supplied refresh token.
Having worked my way through this tutorial:
http://bitoftech.net/2015/02/16/implement-oauth-json-web-tokens-authentication-in-asp-net-web-api-and-identity-2/
I now have the solution standing upright and I can issue JWT tokens (what I think of as 'login') and authenticate requests by passing in those tokens during subsequent calls.
What I'm not clear on is how the [Authorize] attribute is:
Recognising a user as authenticated
Retrieving a user from the database
Making that user available to my code
How I would add to the authentication process if I wanted to (perhaps including extra authentication logic after the exiting logic)
[EDIT] I understand that JWT tokens are being used to identify the user but I don't understand 'how' this is taking place. I also understand the middleware is doing it, but the workings of this are not clear.
with the [Authorize] attribute an AuthorizationFilter will added to the filter chain before the controller is called. This article illustrates that.
With the call to ConfigureOAuthTokenConsumption (Step 6 in the tutorial) you give the middleware the information it needs to validate and process tokens.
the authentication, i.e. check username and password, happens only before the token is issued in
public override async Task
GrantResourceOwnerCredentials(OAuthGrantResourceOwnerCredentialsContext context) {
...
ApplicationUser user = await userManager.FindAsync(context.UserName, context.Password);
...
}
the AuthorizationFilter will only see the token and rely on the information in the token itself
this blog post gives you an example how you can access the username:
var currentPrincipal = ClaimsPrincipal.Current;
string userName = "Anonymous";
if (currentPrincipal.Identity.IsAuthenticated)
{
userName = currentPrincipal.Identity.Name;
}
the middleware gets the information from the token
you can add you own logic either before the token is issued in GrantResourceOwnerCredentials or add your own AuthorizationFilter if you need additonal logic when you receive the token. The blog post linked under 3. shows an example for that.
I am trying to create a suitable authentication check for a CakePHP service. Currently it appears that the user session is created initially during login, but never checked beyond this during a single session.
eg. Renamed the username, changing the password or ID in the user's database entry has no effect on the session.
Is there a preferred method for this type of, constantly checked, authentication? Essentially the user should be confirmed access at every request.
My current solution would involve extending the AuthComponent and storing a hash of the user data (including the encrypted password) and checking this at every request. I also considered storing the session ID in this same token, but noticed that CakePHP does not even use the session_start() function.
This functionality appears necessary for me, and I would have thought others would also require such a solution. I have yet to find Cake documentation or community solutions similar to what I need.
Well, you can use isAuthorized() function from AuthComponent. It's being called with every request.
public function isAuthorized($user){
return true; //allow the user to see the page
}
You can debug($user) to see the actual data and if you want "new" information from your database, you can always get them like this:
public function isAuthorized($user){
$current_user_from_database = $this->User->findById($user['id']);
if($current_user_from_database['User']['username'] != $user['username']){
$this->Session->setFlash('You\'ve changed the username. Please, login again.');
$this->redirect($this->Auth->logout);
return false;
}
return true;
}
Look at the API for more info and from the PDF book. You can look at this video about AuthComponent too. It's great.
If you need any more information or help, feel free to ask.
Btw. you have to configure AuthComponent in your Controller if you want isAuthorized() function to get called with every request.
If Session.timeout will work correctly with a setting of zero minutes, you're set. http://book.cakephp.org/2.0/en/development/sessions.html
I need to be able to call the built-in [HttpPost] Logon method (in the Account Controller) from a GET request. Basically, a new account would be assigned a temporary password, delivered via email. The user clicks on the link in the email (containing a userid and temp pw in the URL), which would be handled in the account controller in the MVC app. I'm not sure how to handle this. Is it possible to redirect from a GET action method on the controller, to the POST logon action method? How would this be done while maintaining the HttpContext object? It seems that this wouldn't be doable outside of just creating a new GET logon method with the user and pw strings params and recreating the logic (using MembershipServer and FormsService objects) that's in the POST method.
EDIT: For anyone following this post, the solution I wound up implementing is:
Using #Shyju's recommendation in a comment, I created a new GET action method to respond to the email link, that returns a "Register New User" view containing hidden inputs for the passed user\pw and a submit button.
The view posts back to the normal logon method. If the user or pw has not been altered, the user will be authenticated
I added a global action filter that tests for the user object property "MustChangePassword". If true, it redirects to the change password action method. This will happen for any method of any controller, except the account controller (so you can actually hit the logon, chg pw, and other methods)
Then in the "ChangePassword" POST method, a successful pw change will reset the "MustChangePassword" property to false.
You can create a unique string (use Guid) for each user and send that as the query string for the link in the email. In the GET action validate that against the user table & Temporary Password table and get the user record and consider that user as logged in user.