ASP.NET MVC ActiveDirectoryMembershipProvider user stays logged in even when password has changed - asp.net-mvc

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

Related

Is there anyway to identify Asp.net identity token expiry timeout event or idle timeout event.?

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

Auth0: How to enable silent authentication in Hosted Login Page?

I'm using hosted screen of Auth0. I want the following scenario to work-
Let's say I have 2 apps- app1 and app2.
One of the users signed in by providing email+password in app1.
User then navigated to app2.
Auth0 detected that the user has already signed in, so it redirects the user back to app2 WITHOUT having her signed in again.
But what I'm facing is this screen-
How can I save my user this additional click? How do I implement silent authentication? I know that you have to pass prompt=none to /authorize api, but since I'm not manually calling the api, how do I make the lock call /authorize with prompt=none?
What you want is silent SSO which is related to SSO but kind of independent.
The key is in the prompt param. This needs to be none in order for the user to not be prompted for login when he's already logged in Auth0's Authorization Server ("central SSO").
One annoying thing I found is that prompt is taken literally, so if the user is not logged in yet, he will not be prompted to login (you'd think it'd make sense to prompt the user when not logged right?).
In this case SSO will redirect to your app's /authorize with an error like "authentication required" and you'll have to handle it by redirecting the user to your /login endpoint again but passing prompt=true so that it knows that this time he'll have to pass prompt=true to Auth0's hosted login page.
To make things a bit uglier, currently passport-auth0-openidconnect seems to ignore the params you pass to the strategy unless you monkey patch one of the methods involved (I created a PR for it, don't when will be approved and/or if makes sense).
Essentially:
Pass prompt=none
If user is already logged in, he will silently be logged in your app as well
If user not logged in, user will be redirected to your app with "login required" error
In that case you'll have to pass prompt=true
I know it's a bit fiddly but I hope this helps you :)
PS: Another thing to bear in mind - I now just found out that it works perfectly when using Github as connection but when using google-oauth2 it blows up complain about the prompt param :|

Anonymous sign in persistence

I’m creating application that uses Firebase. I want to allow users to register in application optionally, so user can use my application for year for example and never register.
If user wants he may register (and we will link anonymous login to new account), but that must be an option not required feature.
Now I can use FIRAuth.auth()?.signInAnonymouslyWithCompletion(), all working is okay except if session will expire and app will be closed. I can’t sign in again with that UID, so all user’s data is lost.
How can I signIn with same UID or make that anonymous authentication (users hate that requires registration on each application)?
P.S. You may say that I need custom authentication, but as I read for that I need custom authentication server, I have only app and Firebase server.
#Frank van Puffelen posted correct answer:
The session for your anonymous user should not expire as far as I
know. The access token will expire, but will auto-refresh.

Locked out users can login if they have Auth Cookie

.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.

DotNetOpenAuth Login without asking credential in second Time (if less then 10 to 15 Sec)

I'm using DotNetOpenAuth. I configured my application with Custom form authentication with Gmail OpenID through (DotNetOpenAuth). I can successfully login to my app. But say for eg. i logged out from application and click login (with in 10 to 15 Sec) its not redirecting to gmail login. It generated authentication token by itself without asked from user.(I hope something is cached OpenID)
I used PAPE
request.AddExtension(new PolicyRequest()
{
MaximumAuthenticationAge = TimeSpan.Zero
});
And also tried to configure in web.config.
<openid cacheDiscovery="false">
Is there any workaround for the same.
NOTE : Once i logged out i used to clear ALL Session and call FormAuthentication.SignOut()
With OpenID, you as the relying party cannot force the login policy for the user at their Provider. You can request that the provider relogin the user as you have with the PAPE extension, but the Provider may still ignore that.
The cacheDiscovery setting is irrelevant to pass-through login, so I suggest you remove that entry as it will simply slow down all logins.
I think you're mistaken when you say it's not redirecting to Google. If you look at the logs, or what your browser's URL bar, Google.com should be redirected to, but at that point Google decides the user has a login session and avoids prompting them to login again, and redirects the user immediately back to your site.

Resources