Using Hybrid flow and back-channel logout, and trying to single sign out multiple user sessions when the user signs out of one session.
If I use the same browser, then I have no problem SSO the user, one client redirects to IDSRV4 logout page, and IDSRV4 invalidates the session, sends a back channel logout request to the client and the session cookie "idsrv.session" is deleted from the browser. Client 2 then makes a request and notices that there is no authentication cookie and redirects to IDSRV4 for login.
When I open Client 1 and Client 2 in different browsers, Single Sign On fails to work, and the user must enter credentials in each browser (expected, since the browsers do not share cookies).
However, I would like to still be able to invalidate all sessions of the user when they log out of IDSRV4, and send back channel logout requests to each client
I have tried implementing the LogoutSessionManager/CookieEventHandler in each client (that's how the back-channel is working in the same browser). However, IDSRV4 never sends the Logout request to the second client, only the one that initiated the log out request. But since the logout request deletes the "idsrv.session" cookie, then the other client is effectively "logged out."
I have thought about implementing a state server as described in this SO IDSRV4 question, but have not yet started because the terminology of "lazy-signout" and triggering a challenge is new to me and I haven't researched them enough quite yet.
Any and all help, or ideas are appreciated. Thanks
Related
SignalR is working great except on every other page load, I get:
The error in the start and abort are
Unrecognized user identity. The user identity cannot change during an active SignalR connection.
At this point, though, if I do a ctrl+f5, it works great.
I'm on IIS 7.5 which means it's not using web sockets, if that matters.
Is it possible that another request that completes after SignalR's /negotiate request but before the /start request is setting a cookie that is changing the user's IPrincipal?
SignalR's /negotiate request returns a "connectionToken" (among other things) which serves as an anti-CSRF token. Every subsequent SignalR request includes the connectionToken in the query string, and the server verifies that the same user that requested the connectionToken is making the new request. If the user not the same , SignalR will respond with a 403.
As Marcel N. pointed out, this could also be caused by a user's session expiring, because that would effectively cause the user to log out. I think it's pretty unlikely that the session would consistently expire between the /negotiate and /start request however.
I need to sign in to a site, I can do this via an url such as url.com/ssorequest?parameters=123. If this is typed in the address im signed in in and gets redirected to the portal.
Now Im supposed to do this through a http post request programmatically but I cant get it to work, I get redirected to a sign in form instead of the portal, ie I dont get signed in.
I used Fiddler to find out what the difference between the two methods was. I found that a couple of behind-the-scenes get-requests were different. The browsers get-requests sends cookie data to the server and fiddlers post-request does not.
When I use fiddler to repeat the browsers first call it doesnt send the cookie data either. So it only works when I do it via the browser window. Unless I use breakpoints in fiddler and tamper with the requests to include the cookie data.
Q: Why does it behave differently from the browser with both http post and when the request is done from Fiddler?
Q: Is there any way to tamper with the requests going out programmatically in my C# app without writing my own Fiddler application?
Most probably you have encountered an anti-forgery cookie. It works in a way to ensure that you are signing in using the page that was first requested and loaded in the browser and the cookie is valid for one request only and hence the fiddler will not be able to log in if you run the same request again.
Using C#, you first have to request the sign-in page and get the cookies provided with this page in a cookie container. Next time, when you post the page along with data, you have to make sure that the cookie is attached with the request.
Edit:
Step1: Browse any page on the site. This will initiate the session. It will also give you the session cookie.
Step2: Request the sign in page. send the cookie obtained in step one along with sign in page so that it can recognize the session. This step is critical. At this stage, there can be either of two things depending on the security system site is using. Either it will send a security cookie along with session cookie or it will add a hidden variable in the form along with a value which serves as security token. Make sure that you get this token/cookie.
Step2: Post the login information on the sign in page (or whatever page the form action leads to) along with the cookie/token obtained in step 1. If it is a token, include it in your post data along with login information or if a cookie, add it to request.
What type of security maintained in any website or web application. After login, Whenever we copy the address from address bar and paste it to the other browser , the page cannot be open or we get redirected directly to login page. But same address can be opened in same browser. So I want to ask that,how the security is maintained and what it called??Thanks in advance.
If you are using Forms Authentication the whole security model is based on cookies. So when a user logs in an authentication cookie is emitted for the session of the browser. This cookie is then sent along on each request. The cookie could be persistent (i.e. stored on the local disk) and will survive browser restarts or it could be not-persistent in which case it only lives in the memory of the browser.
This cookie contains an encrypted value of the currently logged in username, which allows the server to decrypt this cookie and recognize this user.
When you move on another browser, there is no cookie being sent, so from the server's perspective the user is not authenticated and it gets redirected to the login page if he tries to access some protected resource.
Cookie
Browsers work with cookie and authentication is mainly (almost always) done via cookie. The procedure is this way:
You go to a website by entering the URL of the site into the address bar.
Browser checks to see if there is any cookie (key/value pair) set for that URL
If there is any set cookie, browser sends those cookies alongside HTTP Request.
That website checks for that cookie, before letting you see the requested content (before sending you back the response)
If you have the cookie, it responds.
If not, it redirects you to another page (login page) where it can ask your user name and password (most simple authentication mechanism).
When you provide your user name and password, it simply sends you a cookie (authentication cookie).
We have a client application running on each users computer that has a link to the associated web application.
A recent requirement is that if the user is logged in on the client application that they should be able to click the link and be automatically logged in on the web application.
Our web application is encrypted using SSL. Our client application is in Silverlight.
Is there a way to achieve this securely?
Our first naive thought was simply to embed the username and password in the url for the site, but obviously this is not secure because it is visible in the history and via the back button.
Attempt two involved simply converting the password segment into Base64 as to obscure it from view and trust in the SSL to encrypt it.
I'm still not happy. Ideally we would want to use some sort of time based token that expires within minutes of being used.
Where do we start?
If this becomes overly complicated (special hardware) or requires the user to do anything other than click the link-button then the feature will be dropped.
Perhaps you could make an authenticated web service call from the client application to the web application to obtain a token when the user clicks on the link, and then append the token to the querystring? Then the user is logged into the web application using the token, which is then immediately invalidated (valid for one-time use only).
I have an application which uses 2 web sites (so I guess that is 2 applications...). The user logs on via a https website and is then diverted to a unsecure http website application on successful logon (using forms authentication). I (and others) have started getting the message
"The current web page is trying to open a site in your Trusted sites list. Do you want to allow this?"
when the user is redirected.
Is there a way to stop this in the server configuration or in the code ?
Thanks
If the user is accountable for any actions performed on the "unsecured site", it should not be unsecured. It's not safe to authenticate a user on HTTPS, then let them perform actions using that authentication over HTTP.
If someone is not worried about a man-in-the-middle, it doesn't make sense for them to use HTTPS at all. On the other hand, if a man-in-the-middle attack is a possibility (and in general I assume it is) then sending the session identifier cookie (or other credential) obtained via secure login over an insecure channel allows an attacker to steal it and forge requests to the service.
I think what you are doing at login is to post the login information from the secured page to the non-secured page, which in turn pops up that message.
What you could have done is for the secured login to post to a secured page, then redirect from there to the non-secured page. That should remove the message.
That message appears to be IE's trusted sites warning. There is no way to control it from a remote server, nor should there be as it would be a security risk.