.Net 4.5.1 / MVC 5.1.2 / Identity 2.0.1
Greetings,
I needed a way for administrators to disable (can't delete) user accounts so I set the LockoutEndDateUTC field to a future date and I already had the LockoutEnabled field set to true for all users. There's another SO thread, here, that talks about the same method. This obviously works but only if the user has to enter a username/password.
Here's the problem... If the user has set the auth cookie with the "Remember Me" functionality prior to being disabled, the lockout is not being checked and all subsequent visits are authenticated and the "lockout" is ultimately overlooked.
Firstly, I believe this to be a bug in Identity and I've already logged an issue on codeplex.
Second, Is there a better way to disable a user in version 2.0?
Thank you!
Locked out users are prevented from logging in, but indeed being locked out does not reject existing cookies, otherwise malicious users could cause the real user's cookie to get rejected otherwise. Of course if you do want this behavior, you can just simply call UpdateSecurityStamp on the user who's locked out in your Login action, this will reject existing cookies the next time they are validated against the database.
Related
We have created an Identity server 4 application for single sign-on in Asp.net core 2.0. We use the Microsft Identity framework for login and account related pages.
The client applications are created using .net FW 4.7.1 in MVC 5 which are then connect to identity server for single sign-on purposes (used Identity server 3 in client application).
We have a requirement wherein allow users to log in to the application only from a single device at a time. To achieve this, on user login, we create a unique LoginSessionId and store it in DB. On logout, we just make this session-id null.
If someone else tries to login with the same user on another device, we just check if the LoginSessionId has value. If yes, then we give a message informing the user that he's already logged in on another device and if he wants to kill the other session. If he says yes, we let him login and reset the LoginSessionId with a new one. As for the first device login, we have a check-in place to log out that user if his current LoginSessionId does not match the one in DB, so he gets logged out.
We have also set the AccessTokenLifetime and IdentityTokenLifetime of the identity server-client application to 24 hours. Here is the problem we're facing:
When the 24 hours are up after user login, the user gets logged out since the Token must have expired. But the LoginSessionId mentioned earlier is not reset. Thus when a user tries to log back in, we end up showing the message of another user logged in, which is not really the case. Question is,
Is there is any way to raise the token expiry event so that we can clear the LoginSessionId there?
Is there any common place where we can identify the various reasons due to which user gets logged out. Like was it due to token expiry, or because he was idle for a long time (sliding expiry I think), or if he clicked logout himself etc.
What is the max value that we can set for AccessTokenLifetime and IdentityTokenLifetime.
One needs to implement IEventService and IEventSink in Identity Server 4 to get those evnts.
for more details, you can refer to this link.
link
Is there a way to stop accounts.setAccountInfo from deleting an email if it is the last standing login ID?
Currently if I have 2 verified emails both loginIds and issue 2 requests removing one email at a time (I know I can pass a comma separated list) I end up with an account that can't login anymore as no login Id is left.
Both return 200 ok and no error code.
I've looked for an etag implementation so I can at least force some sort of an optimistic lock but couldn't find support for it.
Any ideas?
This is by design, as in the case a user's email(s) were compromised, there needs to be a way to disable login of the account until the user can have their information updated via a customer service representative. There is no out-of-the-box way for an end-user to use this particular parameter, so, unless a currently logged in user is manually calling the method from the JS console, there is no way for this scenario to accidentally happen.
From the server-side, if you are worried about a specific application from calling this method and require restricting a specific app from accessing this particular API you can assign the application key to a permissions group with restricted permissions. ref:https://developers.gigya.com/display/GD/Console+Administration#ConsoleAdministration-PermissionGroups
If you think this behavior should change, please open a ticket from your Gigya/CDC account dashboard for investigation.
I use MVC(4) with Identity (2.0) and my webapp have a page for admin to manage users.
One functionality of the admins is to inactive(freeze) a user account the way I implemented it:
Add a field in my DB called 'Active' and if the admin is deactivate the user the field value is '0'.
In order not to check for every user in every page of my website is to do it only when the user is trying to log in, so before I let him log in I check this field.
But now I have the problem:
Use-Case example: the admin is deactivate account of user "x" and after 10 min the user "x" enter the site and the site "Remember" him and not ask him to log in so my check will never happens.
if the site is "remember" the user and not asking him to log-in i'm in trouble, i need somehow to sign out the user.
I read about cookies and security stamp and my conclusion is:
I need to change the security stamp of the user in order to prevent the site to "remember" the user and allow him not to log in.
First thing: did i got it right ? change the security stamp of a user and the site wont remember him ?
Second thing: i notice that the security stamp is a guid so i can generate programmatically and insert to the security stamp field of the user, yes ? no ? why ?
If you have a better implementation to the whole thing...ill gladly hear it :)
Thank You
Update: Maybe if i change some field of the user in the database( a field that i'm not using like telephone) it will update the security stamp automatically ?
Update2: Even if i generate manually GUID and put it in the security stamp field(upon the DB) it doesn't force the user to log-out.
I've used javascript to get the logout to happen
<i class="glyphicon glyphicon-log-out"></i> Log off
Even if the User is remembered by the browser, he still needs to be authorized. You can always perform this check on authorization rather than on authentication. That way, even if the user is in the process of browsing the site and the administrator freezes the account, his browsing won't be able to continue, because on the next authorization, he will be logged out and unable to log back in.
Authentication: Who is this person and is he really who he claims to be?
Authorization: Is the logged in person authorized to perform this action or access this resource?
As suggested by James in a comment, I also agree that this can be implemented as a role or a claim. Look into claims with the Asp.Net Identity and I'm sure you'll find the solution much more elegant and flexible.
I am using ActiveDirectoryMembershipProvider in my web app. I authenticate users with their domain credentials like so
if (Membership.ValidateUser(m.Username, m.Password))
FormsAuthentication.SetAuthCookie(m.Username, true);
This works well.
But even when the user's password is changed in active directory, the user stays logged in to the web app?
How can I ensure the user does not stay logged in to the web app if their domain password changes, or their account is disabled etc?
The answer is to periodically (every 30 minutes or so) check User.IsApproved and User.LastPasswordChangedDate to make sure the users credentials are still valid.
To do this you need to manually create the FormsAuthenticationTicket and cookie, rather than using FormsAuthentication.SetAuthCookie.
Put the date you validated the user inside UserData and compare this against LastPasswordChangedDate.
I've implemented this and it works perfectly.
More information here
Check if Active Directory password is different from cookie
I'm not 100% certain, but it sounds like you're unhappy that the user's auth ticket continues to work even though their password changes / account expires.
Once a user has logged in and has a authentication ticket (cookie), the user is not challenged for authentication again until until the ticket expires (set in the web.config file). Here are 2 suggestions for dealing with this problem:
Wait for the auth ticket (cookie) to expire. Upon the next login, the user will
be required to use their new password. Variations of this solution include using session-only cookies so that the user must always login when the browser is closed (recommended for AD authentication).
Write an Http Module that looks for a list of recently updated users and inspects the auth ticket early in the HTTP pipeline. If an auth ticket comes through and matches the list of updated users, you exprire the user's cookie and re-direct them to the login page. Here's a similar question that would help get you started:
How can I force a logout of all users on a web site
I'm designing a small ASP.NET MVC site for a club. Generally, I want users to be able to stay logged in, but what happens if a user's membership has lapsed? Is there any way to "de-authorize" them so that next time they try to view a page, it redirects them to a page telling them their membership has lapsed?
If the timeout defined for the authentication cookie is hit it will no longer be valid and users will automatically be redirected to the login page. If you want to sign them out automatically under some circumstances you could simply:
FormsAuthentication.SignOut();
Why don't you make the expiration of the authentication cookie, the number of days that you want, or their membership expiration date, whichever is sooner, then you get the benefit of getting handled automatically
When you get the user's information from the cookie, you could add a check to see if their membership has lapsed and redirect them to that page.