My asp.net mvc 5 application is configured on IIS to require SSL and a client certificate in order to authenticate. I would also like the user to be able to terminate that session explicty by clicking a link/button (SSL session, not HTTP. No HTTP session is ever created).
Closing the browser seems to work with all browsers. If I do this, the next time I try to access the site I will be forced to start a new SSL session (i.e. choose a client certificate to authenticate with). Effectively, closing the browser clears its SSL cache.
If I could do this programmatically on the client, using javascript, that would be great. Or, preferably, I would like to force the server to expire it's end of the SSL session, using C#, that would be better.
This question has been asked twice before, with 0 answers given. I'm trying to get a fresh set of eyes on it, in the hope that PKI authentication is more common now than 2-4 years ago:
IIS - Reset SSL Session Programmatically
Is it possible to close/manage a SSL connection/session on IIS?
A SSL session is either known by client and server or it is not known. There is no API to delete a specific session on the browser, i.e. all you can do is close the browser. The situation is similar on the server side, especially if the stateless session tickets are used to maintain a session. In this case it is not possible to remove a particular session but it is only possible to change the server side secret used to create these tickets which causes all sessions created with this secret to be invalid.
Related
I'm working with an SSL application and I would like to read data from two client certificates.
When a user comes to my site he chooses a certificate and enters a pin, which get cached and used by subsequent requests until Chrome (et al) gets restarted.
Any ideas on how to prompt the user for a certificate for a second time on the same site?
Regards.
A solution that has satisfied my need was to bind the app on two https ports in IIS config. Works on IIS Express also.
More info: I am making two ajax requests on routes that are matched by a single <location> tag web.config. This location requires a certificate, which means user gets prompted when accessing them. Since these two ajax calls go to different ports, user gets prompted on the second ajax call too.
Knowing how to clear the cache would have been nicer for other use cases, because restarting Chrome is not something I would ask my users to do.
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 running into this strange issue where few users of my app plug out their laptops from dock and move to WIFI network while using the application, Now after changing the network when they click on any navigation in the application it takes them back to the login page mentioning the session has expired.
Background: The server where the application is hosted have the load balancer which dynamically routes the incomming request, hence when user goes of from one network to another the old session maintained by the web browser stays open but load blancer identifies it as a fresh request and hence allocate to next available server which requires a login, now if user is fortunate to be routed on the same web server where he was before then all works fine otherwise he is redirected to new web browser.
Please help me resolving the rare scenario issue.
Thanks in advance.
Vishal
This issue depends mostly on your load balancer and the persistence of stickiness.
Some balancers handle the sticky persistence internally, so they have a table between client IP and route. Your case sounds like that.
Now, if you shift the persistence from the internal table to a cookie (or URL appendix), you can tackle the case. By using a cookie, the client will send the cookie on every request and the load balancer can check, whether the requested route is still valid and then serve the request. There is a non-IIS example for Apache (http://httpd.apache.org/docs/2.4/mod/mod_proxy_balancer.html#stickyness_implementation), how they approach stickiness, but the feasibility depends on your balancer.
Since you have load balancing in-place then it is just a questions of whether to store the sessions in Jsession or Cookie, to avoid this issue I suggest your configuration the server to use Cookies. As by default Tomcat 7 (and I believe Tomcat 8) are configured to use Jsession
I'm writing an application which displays a login form before it loads, and it sends a POST request to a web application which I previously developed.
I can send login details off and get returned a 200 message and can recieve data within that request. However I now wish to store this login after the application has closed, to allow the user to not have to login every time they open the application, or in this case when the computer is restarted. (It will run at boot however needs to maintain an application and not a WCF service)
I'm using HTTPWebRequest in C# to handle POST requests to the server, and I can make cookies on the server side. How do I let my application know about these cookies and store them in a secure way to allow persistent login for my entire application? I've looked at a number of ways to store cookies in C# such as these two links:
http://www.c-sharpcorner.com/uploadfile/mahesh/managing-cookies-in-a-wpf-application/
http://msdn.microsoft.com/en-us/library/dd920298(v=vs.95).aspx
However the code in the first link gave me an odd cookie:
"CSCUser2=test-username; android_developer_C:_width=243px; __utma=1.1718972007.1316996246.1316996246.1316996246.1; __utmz=1.1316996246.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); android_developer_reference_lastpage=/C:/AndroidSDK/android-sdk-windows/docs/reference/android/speech/RecognizerIntent.html"
So I'm not sure if that approach is best? Any pointers would be appreciated.
I think the CookieContainer (i.e. the MSDN link) is the correct way to set and get cookies (By the way: note that your question has nothing to do with wpf or mvvm patter. It is a general c# /.net/httpwebreuqest topic).
As for caching credentials on the user machine which can be used in subsequent sessions - there are several ways to do this. You can either store the user password in a secure location, or you can store a session key sent to you from the server. The advantage of the second method is that the session key is limited in time (e.g. one week), and after that they user will have to perform a new login. The session key can be delivered to you from the server out of band as a cookie, or with a specific API. Web applications are using cookies because they have no access to any persistent store, but your wpf application can store the password or the session key anywhere it wants.
I recommend you use the DPAPI to persist secrets on the user computer. Google for c# and DPAPI to see how to do it in .net.
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.