We have an ASP.NET MVC application that uses Forms Authentication to create and validate the authentication ticket (cookie). The log on flow is very special, not just username/password, but it ends with a call to FormsAuthentication.SetAuthCookie(userId, false) to create the cookie. So a standard cookie is created, it is just how it is created that is special.
We will also have to integrate with a couple of other web sites that are not neccessarily .NET based or not possible to customize via some kind of Single Sign-On that do not require any modification on the other sites. All sites are behind the same UAG/ISA Server.
Is it possible to setup some kind of filter in UAG/ISA Server that can validate the Forms Authentication cookie created by the ASP.NET MVC application? If it is not OK it should redirect to the log on page in that application? If it is OK it should just let the request through. For example, would it be possible to use a ISAPI filter with UAG that does this? We can use the same machineKeys on the UAG server and the ASP.NET app server (I guess that is required to start with)
I don't know much about UAG and I'm also interested in alternatives to UAG. In fact, what we really need is just something that works as a perimeter protection for all those sites and that can utilize the already existing log in flow/cookie.
Related
We have a TYPO3 CMS to manage user base and as a portal for various user-specific information. We also have a separate ASP.net C# application used for charting visualization with many of the same users with a separate admin backend . Looking to get rid of login portion ASP.net application and use TYPO3 session authentication. Idea is for the user to be able to click a link within their Typo3 frontend and get directed to the ASP.net application which can then authenticate with the Typo3 session and act in accordance. Just wondering if my best bet is to write something in the ASP.net app to get the TYPO3 session cookie (is that possible?) or if I have to do something clunky like oauth2/other service
I would write a TYPO3 authentication service that contacts your ASP.NET app via one of known protocols (REST?) or even custom protocol and checks authentication. If it is successful, the normal TYPO3 authentication process goes on.
It is not enough to simply set a cookie during the authentication. There are other things that has to be done for the user to be "set up" as logged in.
I am trying to share authentication and authorization between different web applications (asp.net application and a MVC4 Application).
I read that you should set the machine key and those values to be the same between the sites. I have done this and the authentication is working properly.
But now in the MVC Application i want to use the Authorize attribute to make sure users can only see what the are supposed to see. This is not working.
I also checked.
When I call User.IsInRole("Admin") from the ASP.Net application(this is where the login is done) the value returned is true, but then when navigating to the MVC application the same call returns false.
It seems that the roles is not being shared across the application, is it possible to get is working or should i Create a custom Authorize Attribute ?
thanks in davance
The more applications you have, the more problematic it is to share the forms cookie. And ultimately, if two applications are on different domains (something.foo.com and somethingelse.bar.com) this won't work as you can't force your browser to submit a cookie to two different domains.
This only works if you have manual control over your forms cookie and issue it for .yourdomain.com top level domain and you have your applications in subdomains (app1.yourdomain.com, app2.yourdomain.com). And this could be a serious restriction.
What you could possibly do is to externalize your authentication, i.e. create a separate web application with the sole goal to authenticate and authorize your users. You pick one of Single Sign-on protocols (WS-Federation, OAuth2, OpenID) and federate your application environment around this authentication provider.
It possibly sounds difficult, especially if this is new to you but if you invest your time, there are only benefits.
We have two old websites in Classic ASP and few websites in ASP.NET 2.0. Our new development is in ASP.NET as well and gradually we might be moving our Classic ASP sites to .NET as well. All these websites use same back-end database.
For now we are planning to move our user authentication to a single server and start using Single-Sign-On(SSO). I am not able to decide what would be the best or right way. Our asp.net websites uses FormsAutentication with CustomMembership and RolesProvider i.e. we use our custom tables instead of default aspnet_membership tables.
Ways I can think:
1: Use Webservice: I can move the authentication code to a webservice and all of our sites can use it. But I am not sure how the Single-Sign-on fits in when we have ClassicASP sites involved.
2: I heard of DotNetOpenAuth: Our external users are created by our internal staff. They can only login using the username/password we provide. So they cannot login using Google,Yahoo or any other username/passwords. So I am not sure if DotNetOpenAuth fits in our case. I saw SSO sample in DotNetOpenAuth download but have no clue how to begin.
If anyone can point me in right direction please. I have gone through various articles and docs but not getting a clue where to begin.
Well, it could be that one of passive single sign-on protocols could be your choice. You can choose between the WS-Federation, SAML protocol or Shibboleth but the first one, WS-Federation is easily supported on .NET with the Windows Indentity Foundation subsystem.
The way WS-Federation works is that it you externalize the authentication/authorization to a separate web application (so called Security Token Service). Each of federated client applications (so called Relying Parties) rely on the information provided by the service.
The basic control flows is like this:
the client points his/her browser to a RP application
the browser redirects (302) to the STS
if STS was visited and the user is already logged into the STS go to 5.
STS shows the login page and validates the user
STS returns to the browser a page containing a signed XML token with all the auth information as well as a tiny javascript to redirect to the RP application
the RP application picks up the token and creates its own authentication based on the provided information
WIF gives you tools to build both STSes and RPs easily and integration of legacy application is also simple - you can either make an effort to handle the protocol at the legacy application level or provide a "brige", a .NET application using WIF which relies on STS and passes the auth information to the legacy application.
What is also great is that with WIF you still stick with old, good notions like Forms Authentication and Membership Providers - it could be a preferred choice of STS implementation.
The WS-Federation protocol itself not only provides the single sign-on but also lets you easily handle single sign off (which is not supported by some other protocols like openid).
Read more on the topic in this book:
http://www.amazon.com/Programming-Windows-Identity-Foundation-Dev/dp/0735627185
Checkout this guide on "Claims-based Identity and Access Control".
The chapter 3 especially: "Claims-based Single Sign-on for the Web and Windows Azure" (Azure is not a requirement).
It well explains the modern Microsoft's way of implementing a single sign-on strategy.
Plus, this TechNet article helped us a lot to get started with WIF and ADFS 2.0.
I have an ASP.NET web service that I can access via a windows program but now I want to secure the web service. I can secure the web service using forms authentication. How do you access the secured web service from a windows forms application?
Although this is not the right approach, tt is theoretically possible to use forms authentication in the manner you describe. This could be accomplished by either:
Using a WebRequest to send your requests in raw form to the web service. This will involve inspecting the response, extracting the relevant forms-authentication fields, and sending a response back which logs the user in. This will generate a cookie which you must send along with each subsequent response to the service
Generate the FormsAuhentication authentication cookie yourself. This is complex as it involves synchronising the machine key on the calling application, and artificially manipulating the headers being sent to the machine hosting the service.
Display the forms-authentication form for the user to log in to at the beginning of a session requiring interaction with the web-service. You can then harvest the generated cookie and present it to the service in HTTP headers as in option (2).
As you can see, these methods are highly complex, and are fundamentally a hack to use forms-authentication where it was never intended.
Microsoft intended us to use either Windows authentication, or SSL certs to secure access to ASP.NET web services. See HTTP Security and ASP.NET Web Services on MSDN.
If you are able to use WCF, then a few more options present themselves, including the ability to build a custom authentication mechanism into the SOAP, with some support from WCF.
For the most part, securing web services is one of the trickiest parts of the job. Many live solutions which I have seen are compromises such as the ones above.
It seems the answer is no. Forms authentication is a cookie-based mechanism, and your WinForms app won't be able to hold and relay the cookies (without some serious workarounds, if at all).
A potential workaround that I wrote up when researching your question attempted to use a NetworkCredential object, but that didn't work. Also tried was the ClientCredentials in .NET 4.0.
var ss = new MySecureWebService.MyServiceSoapClient();
ss.ClientCredentials.UserName.UserName = "abc";
ss.ClientCredentials.UserName.Password = "123";
string asmxReturn = ss.HelloWorld(); //exception returned here
The console app was still presented with the login html page when calling the webmethod.
Other Suggestions
If you have the source to your web service, extract its logic out into an assembly of its own. Reference that assembly in your WinForms app, and it's just as if you're calling the web service.
I understand that your goal is to reuse the app that's deployed, but the next best thing would be to use the same logic/implementation via .dll reference.
This might help: http://dotnetslackers.com/articles/aspnet/Securing-ASP-Net-Web-Services-with-Forms-Authentication.aspx.
HI have the following scenario:
1) i'm authenticated against some aSP.NET web site and my session time out expires in 24 hours.
2) after several time I would like to run query against asp.net Web Service located on the site using existing authentication.
What should I add to cookie Container? I how do sent existing cookie to Web service?
Thank you in Advance.
Danny.
A web service call is just an http call so it will come under the existing authentication.
I am assuming here that you are issuing this from the browser?
If not - e.g. if you are doing it from a console application, then you will have to interact with the site as if you were a user. Some more details are her http://www.ksingla.net/2006/08/sample_forms_authentication_test_in_csharp/
Basically you need to issue a post to login to the login page - track all of the cookies etc - and then start issuing your WS calls with those cookies.
Another option is here http://en.gli.sh/Blog/post/NET-Interoperability-Between-Smart-Client-and-Internet-Explorer-Using-Cookie-based-Authentication.aspx which is reading the correct cookie info from the windows machine you are on - relies on you being logged into the website and also trusted to be able to get to that file.
Alternatively you can look into implementing WSE or WCF solution.