I implemented two step verification in a ASP.Net MVC page which uses Web Security by doing the following logic:
1) When the user login's first time and when clicks Next in the Login page,he is validated-
if (Membership.ValidateUser(model.UserName, model.Password))
{
......// Encrypt the password and storing it in a session
......// Then redirect to step 2 verification page...
}
and he gets redirected to 2nd step verification page where he would be asked to enter a security Q. If he gets it correct then a new cookie(Cookie2) is created,
and the user is logged in using-
.......//Decrypt the password
_webSecurity.Login(username, decryptedpassword, false)
and then he is redirected to his home page.
2) Next time when he tries to login to the app, there is a check to see if the cookie(Cookie2) which is created in the 2nd step is existing or not. If it exists, then he is redirected to the Home page directly and if its not existing then he is again asked to enter security Q.
So if we see the implementation here, i am actually logging the user into the app only if he gets 2nd step verification valid. In order to implement this, i am creating a cookie and storing the password in a session.
Can anyone let me know if we can code this in a better way?I am guessing we can do this without using sessions and cookies.
Any ideas/suggestions are most welcome.
Thanks,
WH
Related
Scenario:
I have two application to which login is done using pingfederate single sign service.
1.User try to login into first application but as user is unauthenticated user is redirected to login page of pingfederate (universal sign in page). User logs into the first application.
2.User try to login into second application as user was already authenticated by single sign service pingfederate provide application with necessary information(information required to set session) and user is redirected to second application.
Problem:
When User logout from first application then user gets logout successfully. At this point pingfederate knows about all open application and send then logout callback. So it sends logout request to second application. Second application handles the logout request and clears the session. But user stays on the same page. user is not redirected to the login page
Question:
How can be this be implemented that when we receive logout request redirect user to login page?
The way SLO is supposed to work for SP-Init SLO is:
You click logout at the FIRST SP application.
You are redirected to the IdP with a LogoutRequest.
The IdP then sends you, serially, to all the other SPs with
LogoutRequests. Every one of those must provide a SAMLResponse back
to the IdP with a status.
The IdP, after receiving the final status, must send the
user/browser back to the originating SP with a SAMLResponse with the
final status, which the SP acts upon.
In IdP-Init SLO, it's basically only step 3.
Here's the kicker, though, and I think gets to the heart of your question. If a single one of those SP's "misbehaves", i.e., does not respond to, or support, SLO (there is no requirement for them to support SLO), then it will break the "chain" of logouts, if you redirect to it! The IdP will redirect off to the SP, and the there the browser will stay. Once the chain has been broken, there is no way to get it started again.
I discussed this problem in my blog post "SLO - Proceed With Caution", a bit more than a year ago. Ultimately, with many of the big-name SP's out there not supporting SLO, there's not much of a reason to do it - it's just going to give you, as an SAML administrator, a black eye. Or heartburn. Or both.
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 have page where are secured by session. In case session does exists, then navigate to login page. This works fine.
Now, Let's say I am at some page like abc.aspx. Session does not exists. System navigates to th login page. So, once login, can i navigate the user to the page which was originally requested ?
Usually it is performed by adding the requested URL as a query parameter to Login page URL http://fakehost/Login?retUrl=originalpage
so app code can redirect it back. Forms authentication mechanism does it for you.
yes you can however it would be recommended to add a ReturnUrl querystring which contains the page they came from or need to go to after they logged in. you can also use Request.UrlReferrer I believe which gives you the page they came from but means if for example they came from google to your site to login and you redirect, it would go back to google.
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 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.