Excuse me for my poor english.
It's possible get all thread requests from an ASP.NET application?
I don't need execute the complete logout of current user if in same time another clients are authenticated with this same username. Perhaps I could query another request threads for know if I need do that.
I will try simplify the question... Can I know all actives requests from ASP.NET application in a IIS server on C# code?
Now I try get the threads of WebDev.WebServer40.EXE process, but don't seems the requests threads.
I think you are approaching this wrong. You cannot log out a user in the middle of a session since http is stateless and the users credentials are always sent as part of the request, be it a cookie, a Bearer token or some value in the Authorization header.
Performing a logout as part of a single request is therefore not really feasible.
To me it sounds like you want to unauthorize the user without necessarily unauthenticating the user. That is, the user id is still connected to the request, but you no longer want to grant the user access to whatever resource, that was available to the user a moment ago.
This decision is made at a unique point in time, so all requests concurrently with the time you made the decision that the user is now unauthorized will behave differently depending on whether the authorization was checked before or after the unauthorization. New requests are sure to be denied though.
A http request should not take longer than milli seconds or sometimes seconds. Are any ressource you are protecting so important that it cannot live with this inconsistency window, you probably shouldn't expose it via http.
But if you want to make this rather (and perhaps unnecessarily) complex mechanism to unauthorize already authorized request, you should make it as a http handler executing as the last part of the aspx pipeline. It should look at the user id and some kind of shared blacklist maintained by the authorization system.
I think you should live with the inconsistency though. But be sure to separate authentication (who) from authorization (what the user can do).
I did look different possibilities. The best option perhaps is use the System.Web.Administration dll and WorkerProcess.GetRequests method. The main problem is that dll only works with IIS7 version o superiors. Exists some way for get something similar in IIS6? For me the most important is get the current request theads managed by server and know the credentials of each thread and internal info.
Related
I currently have a .net core application that uses Identity Server 4 to authenticate users. We have two different applications; an MVC portion of our site that users can login to, and a SPA that users have to login to as well. Is it possible to make it so that anytime the user logs out of one of those areas, that it logs out of both?
This is the main idea of Single Sign-On. Not only single login, but also single logout. Identity Server 4 fully support this, but you just need to configure both your clients (the MVC app and SPA) with their proper configurations. This is the official documentation about signing out. It works.
EDIT
PS: Have in mind that Identity Server does not invalidate the access token, once you are logged out. In other words - if you, by any chance, still have the access token, you will be able to use it, as long as it is valid (its validity period has not expired). This is why usually the access token is set to have a shorter lifetime.
There are 2 front channel ways to acheive this and I'd recommend using both.
1) Front channel log out which uses an endpoint registered against each client. When you sign out of IDS4 (assuming it's implemented properly) it will make a request to the registered endpoint for each app that was signed into during the current session. http://openid.net/specs/openid-connect-frontchannel-1_0.html
2) The session monitoring spec which uses a bit of javascript and cross-domain iframe magic to notify the client app when the user's session changes on the IDP. Using this you can immediately respond to changes and do any cleanup you need to. http://openid.net/specs/openid-connect-session-1_0.html
As mentioned in m3n7alsnak3's answer this will not invalidate any JWT access tokens (you can use the revocation endpoint to revoke refresh or reference tokens however). Therefore I'd recommend having the client applications to the best job they can of clearing up any state they can, i.e. clearing all cookies, session/local storage etc.
I am trying to prevent multiple concurrent sessions for a user using ASP.NET Core and CookieAuthentication middleware.
Any tips on how to do this?
Ideally, once a user signs in, the app would invalidate and effectively "sign out" all other existing cookies issued for that user. Then, the old sessions would be redirected to the sign in page on the next interaction with the server. So far, I have not found a way to do this.
I have been trying to figure out a way to use a custom validator as described in the documentation.
Thanks!
This is how I've handled it (using ASP.NET Core, but that is irrelevant): To do this you need to maintain state somewhere that is accessible to your server(s). You can store a session ID in a database when the user logs in. Each web app client should hit a heartbeat url (e.g., every few minutes). The back end for the heartbeat checks the session id in the database. If it is the active one for the user, then all is good; otherwise it clears the cookie. If you are using a persistent connection to the client (websocket) then you can push a message to the client to indicate the session is no longer valid.
If you need to be sure that no other action by the user's other session can take place once a new session has started, then you'll need to check the session (as described above) on every call. ASP.NET Core's middleware capability is perfect for this.
I am confident my application is coded correctly (at least mostly), as it works about 98% of the time. However, about 2% of the time, I get what appears to be a valid auth token, but when I go to post a photo, I'm getting the following error "(OAuthException - #200) (#200) User must have accepted TOS". I have retry logic, but it gets the same error three times (so it's not a freak communication glitch).
I use the URL facebook.com/dialog/oauth to get the token, and then I use the C# Facebook client (Post method).
The other questions I've seen posted with this error appear to involve consistent failures, indicating an application error.
Is it possible that a person is shown the permissions page (on Facebook) and rejects it, so the user is then redirected back to your website, but with the Oauth error - which you need to handle.
Basically, I want to log in via Facebook, but I don't accept their conditions (eg. you might be asking for too many things). Thus I'll reject the login, and the source website (you) needs to handle the refusal.
After finally reaching someone at Facebook to talk with, it appears this may be an issue on their side- given the massive parallel processing needed to handle their user base, it is possible the auth token provided was not replicated to all other servers by the time my app (from a different location) tried to use the token.
The suggestion provided by Facebook was to allow more time in the retry process- while it is usually handled within a minute, sometimes it can take up to 30 minutes to replicate to all servers.
So according to the documentation for the SOAP api for Salesforce, if I log in and start a process that takes 1 minute before I log out, then someone else logs in with the same credentials and begins another process that takes 30 seconds before logout, when the second user logs out, it will kick out the first user as well.
Does the REST api have this issue? Is there a way around it?
The answer of your question is YES, REST Api has the same issue.
From official documentation:
If multiple client applications are logged in using the same user,
they all share the same session. If one of the client applications
calls logout(), it invalidates the session for all the client
applications. Using a different user for each client application makes
it easier to avoid these limits.
The only way that salesforce recommends us to avoid this is creating new users.
You could make your own central service to manage the unique session, and give the active access token to clients, but this approach is away force.com platform solutions.
This is really a session management issue more than any specific API you want to call using that session. that said, you have 2 easy options.
a) don't call logout, just let the sessions expire based on inactivity, that way if the session happens to be shared by 2 different integrations it won't cause a problem.
b) switch to OAuth to do your authentication, and give each integration its own OAuth client/remote access entry. (sessions are not shared between different oauth clients).
I have an un-ideal application and without going into the ins and outs this is what is needed.
A 3rd party app needs to make a request to a page which will return data. Because I have Forms Authentication enabled this request always ends up being sent to the login page. I have therefore set it so that all users can see this page even though they are not logged in. What I want to do in the Page Load or similar is to check querystring parameters which the 3rd party app can send and validate it against FormsAuthentication.
When this 3rd party app makes its request a user has already logged on so I was wondering is it possible that I can check something against the currently logged in user to see if it matches the 3rd party request?
What I need to also do is send that information from the logged in user to the 3rd party app so that when it makes its request it matches up with the logged in user.
I may get down votes for this, but I'm going to answer anyway because if one of my co-workers asked me this question, I would read them the riot act. (I won't read you the riot act because I'm not responsible for your systems or the security of your data.)
I see from your first sentence that you realize this may not be the best idea because it is an "un-ideal" application.
I know that what I'm about to suggest will result in duplicate code and add to maintenance down the road, but when you balance that against short-circuiting the authentication mechanism or tampering with a well-known and trustworthy mechanism to weaken it so as to allow another application to use a "back door" (which is what you're really talking about doing here - creating a back door for this other application but attempting to use querystring parameters as part of the login mechanism) it is really the lesser of two evils to have more code and more to maintain.
So... Have you considered, and is it a possibility for you to set up another method for this other app to get the data? You say that it is just getting data, so why not have a separate web services project or some other project appropriate. Even another web site application would be a better solution to what you're proposing.
Even if this data is not what you would call "Sensitive" I still think trying to build in a back door is a bad idea. It may not be a critical issue on the current application, but not coding for security is a habit, and once you do it in one area, you're more likely to take unnecessary risks elsewhere.