We have a website, which our users access by getting an STS from ADFS. ADFS issues claims by checking the user's groups memberships in Active Directory. The website uses WIF to access claims and handle authentication.
Is there a way, when a user's AD data changes (e.g. they have all their group memberships removed), to have those changes reflected immediately (same session, at least from the user's PoV) in their claims for the RP? Currently, if we revoke membership in AD, that user's claims for the RP (in their current session) aren't affected. They have the same claims, and access, that they had before the revocation, until the user's ADFS session expires (which could be hours away).
e.g. user U1 logs in to our website W1 via ADFS, browses round a bit, and then has his memberships cancelled in AD. We need U1 to be logged out of W1 automatically within a short time period (minutes). If not logged out, having their claimset in WIF reset to reflect their now-empty AD group memberships would also be acceptable.
Is this possible? All the documentation I can find seems to assume that the website itself (W1) knows when the user should have their session terminated - in our case W1 doesn't know, the "trigger" for session expiry (or at least claims amendment) will be from AD.
Out the box - no.
Claims aren't dynamic - they are only created at logon.
The only way I can think of is for your app. to poll AD every now and then and if the membership is removed, then do an application logout "under the hood".
The next time the user tries to do something, WIF will see that they don't have a session, will go to ADFS to login, ADFS will see that they are still logged in and access will be granted automatically i.e. the whole process will be transparent.
Because the use was logged in again, the claims will be updated and the membership will no longer be a claim.
Related
In MVC5 asp.net - Is there a way to allow user login only if the user has a particular claim in the user database? I'd like to assign a "CanLogin" claim to users in my user database that are allowed to log in at any given time. By removing the "CanLogin" claim, I could effectively lock the users out of the system until further notice.
This would have to work for a first time login as well as cookie login at a later stage if the user has checked "remember my login".
Using authentication filter, you can check the identity.claims property to validate whatever claims are present in the context.
The claims must be added during the login process
Then you can check whether a particular user is enabled or not.
However, if the user database is self maintained, you can just set a disabled flag and then reject the login request, instead of returning such a claim.
The claims are used for Authorization to a particular functionality rather than Authentication to an app. A valid user will have certain claims which can tell what all the user is permitted to do.
I'm trying to configure my Active Directory B2C web app to remember a device after a user has gone through multi-factor authentication.
Currently, each time a user logs in, they are prompted to complete MFA regardless if whether they've just logged in and out.
I know there is a configuration option with non-B2C tenants to set up device remembering, but I haven't been able to figure out how to do this with a B2C tenant.
I ended up creating two sign-in policies. One with MFA and the other one without MFA.
I would initially guide the user through the non-MFA sign in policy and when they were redirected back to my site, I would check for a unique user-specific cookie with a unique user-specific encrypted value I would create for them signaling if they had passed through MFA within the past 14 days. If they didn't have this cookie I found out I could then pass the user to the MFA sign-in policy and it would skip straight through to the MFA portion. Once the user was successful in completing this step, I would create a cookie signaling their successful MFA and set it to expire in 14 days.
Of course you also need handling for cancellations during the MFA sign-in step so you can sign out the user on your website and have other checks in case they opened another tab and went back to your site (since they are technically logged in at this point) to prevent non-MFA approved users from having access.
You could use multiple policies and create a cookie to accomplish this. For example, you could create two nearly identical sign-in policies one of which has multi-factor authentication turned on and the other has it turned off. When the user attempts to log in, check for the cookie. If it doesn't exist, use the multi-factor authentication enabled policy (and vice versa). When the user is successfully authenticated check for the cookie, create it if it doesn't exist, and set it to expire whenever you want it to (e.g. after 14 days).
We are using Gigya to authenticate the user which will provide us with user Id and email. Then we pass the user detail to our CRM Web Service which will return the user data from CRM.
We then need to create a session for the user so that we can identify whether the user is logged in or not. If not logged in then redirect to Gigya for login/register etc.
Now, given that we are not using any ASP.NET Membership or similar, I'm thinking how we are going to secure the member pages. One way I can think of is store the user detail in session. Then check if user detail exists in session, if doesn't exist prompt for login.
I'm also thinking whether:
I can use FormsAuthentication.SetAuthCookie or similar to create a asp.net session
Or is there better way to achieve this.
Also, if I use FormsAuthentication.Logout will it clear all my session and cookies even though I'm not using asp.net membership provider?
Goal:
To be able to create a session for the user
Able to authorize user based on user role which we get from CRM.
Able to logout the user on Lout button click.
First, and this is very very very important from a security perspective.
Authentication != Session.
They are different concepts. Second,
NEVER USE SESSION for AUTHENTICATION
see first rule. FormsAuthentication has nothing. Zero. Zilch. Nada. To do with session management. Nor does it have anything to do with Membership or credential verification. All it does is store a cookie that ASP.NET can decode to verify that the user is authenticated or nor. This cookie is set by your application when it has validated the users credentials.
FormsAuthentication.Logout() does not clear sessions, because as I already said, they have nothing to do with each other. You have to clear the session by calling Session.Abandon().
Session is about storing data for a user, and is not secure. Session is volatile, and IIS can discard it whenever it feels like, for any reason, at any time. You cannot depend on Session to be there from request to the next.
Authentication is encrypted, and strictly about proving the user has been authenticated.
Authentication can transcend sessions. It can be good for hours, weeks, months... Your session is only good for the time you are currently there (if IIS doesn't kill it earlier).
I am creating an asp.net web application with "Remember Me" option during Login and it has an Edit Profile module where users can change their passwords. Here is the scenario.
I logged into the website from Machine A clicking "Remember Me". So I am logged in and since a persistent cookie is created I dont need to login the next time
until my forms authentication times out.
I logged into the website from Machine B using the same account details I used above and from this machine, I changed my password. In this case How can I make the user in Machine A to login again? (Since my credentials have changed). The same scenario can happen if someone gets any user's credential and uses the application.
Thanks
You have to save the last credentials modification date in your database.
When a user try to consult a page of your website, you have to check the date specified in the cookie.
You can also make an AJAX system that verify each minute if any changes are done and, in that case, verify the validity of the credentials.
If the latest date is the "last credentials modification", then delete the cookie and ask the user to log by himself.
Consider the case of forms authentication with persistent cookies.
If the same user logged in using two different browsers or two different machines, when user logs out from one of the browser/machine, wouldn't still he be able to login from the other browser/machine?
Usually, how do web applications handle this case?
I have to agree with Srinivas for the most part. Here is my take on the subject
On Login create an HTTP Only cookie with a guid generated at login this will be your browser/computer key. Closing browser will remove cookie
Get user id
Persist in the pair in user table ex: user:a, key:12345
On subsequent requests authentication algorithm after user has been authenticated
Get the last used key in the db with current user id
Check that the cookie is present, if not then completely unauthenticate
Check that the cookie value is the same as that in the database, if not then completely unauthenticate
With this method any subsequent login will cause a required reauthentication & invalidate any other authentications. In effect forcing the user to use only 1 browser/computer
I usually do it this way : I have a session column in my user table(in database) When the user logs in I store the value Y in it.I change it to N when he logs out.Every time the user tries to log in, I check the value in the corresponding session column and if it is Y I tell the user that he is already logged in and if it is N then I allow the user to log in. But we have to be careful and set the value to N when the user logs out or closes the browser.
Forms Authentication with cookies (regardless of whether they are persistent or not) is browser session based (persistent cookie would of course work across multiple sessions of same browser (on same user account on same machine). So two browser sessions (or two different browsers or browser on two machines etc) would be treated as different scope as far forms authentication is concerned.
So user can make multiple login from different browser sessions and logout in one will not affect other. Its is up to web application whether to allow multiple concurrent logins for same user or not. For example, online banking sites would restrict to only one user session - so if user logs in from different session then earlier session is invalidated (i.e. user is logged out). One has to write custom implementation in ASP.NET to do so - typical implementation would make every user session entry into database (typically required for audit purposes anyway) - so whenever new entry is added, a check is made to see if there is any active session for same user and if yes then that session is marked inactive. Every request would check if current user session is active or not, if not then it would flag such message to user.