I have a website created with ASP.NET and a web service, both using FormsAuthentication (which validates the user's credentials against Active Directory - LDAP).
When I call an action method of this web service for the first time I am redirected to the site's web page that actually logs the users into the system. When I'm logged in I will be redirected to the web service (ReturnUrl), but I'm guessing something gets lost in the way, because I'm getting an InvalidOperationException (in the client), containing the .asmx definition.
This happens on the first call only, the next calls work fine (since I'm going to the right place).
What am I missing here?
How should I redirect from the web site to the web service? Can this be done?
Thanks in advance.
Your web service call is doing a Post, then redirecting via a Get request after authentication. The default response from an ASMX is the .wsdl definition. You can't do web service authentication like this programmatically.
If you are using Active Directory, why not use Windows Authentication and suppress the login?
Related
I have a nodejs app running using iisnode in a sub directory for a .net application (umbraco actually).
The .net application is using forms authentication and I want to secure the iisnode application using the same mechanism as the .net application.
I've tried registering modules with the iisnode app but it doesn't even seem to fire the event handlers. Is it possible to do this?
It seems that creating an HttpModule to intercept nodejs requests is impossible. However, I did find a way to get the authentication information I was after.
I created some middleware in my nodejs (expressjs) app that picks up the headers from the request (including the cookies) and make a request to a specially created url on the asp.net application using those same headers.
This url simply returns the user info for the user specified in the cookie (if the cookie is present). If I get back some information then I know the user is logged in. No information means they are not logged in and I redirect to the umbraco login page.
I have an ASP.NET 4.0 WebForms site that is running on a IIS6/Server 2003 instance. The site itself does not permit anonymous access and uses IIS basic authentication before the user can get to the Forms authentication screen. However, there are two site nodes below the site level, that are virtual directories which DO permit anonymous access (for requesting static images by other machines).
A new request required me to route those requests to a different page and examine the URL being requested and perform different tasks. I’m using a MapPageRoute method in the Global.asax file and the route clears through Forms authentication with a web.config setting <allow users="*" />. Obviously, that works great locally, but when deployed to the IIS6 machine basic authentication kicks in before the request gets routed.
Is there a good way to "fake" or create a virtual directory node in IIS6 and grant it anonymous access so that the routed url request can execute?
This might not work for everyone, but since in my case HTTP Authentication was primarily instituted just to prevent people from multiple attempts at the login page, I actually removed Basic Authentication from the site and all virtual directory nodes.
Then I added it just to the ~/[loginpage] that was being used. Since forms authentication was in use all unauthenticated users are re-directed to the login page and then get the basic authentication. Since the routed page request needed to be public I just added it as an exception to the Web.config. The routed values have to meet a very strict criteria to even be executed by the page logic and everything else is returned as a 404 by the handler.
Obviously this means that the asp.net dll is executing before IIS basic security when requests are redirected to the login page, but in this case I think it is fine.
I have a bunch of websites that are setup identically to use a WIF identity provider. I've recently moved the business logic out of the web applications and into a Web Api service application. This runs in a different virtual directory to the other sites. The idea being that browser will put the data into the page AJAXy.
The issue I have is with securing the web API. It seems that WIF single sign-on works okay with traditional sites. The user can access one website, get redirected to the identity provider, login and get redirected back to the website they wanted. When they access another site they also get redirected back to the identity provider but needn't log in as a FEDAUTH cookie exists so they automatically get authenticated and redirected to the second site.
This doesn't work for the Web Api scenario because when the browser perhaps makes a GET to it, the Api will return a redirect to the calling javascript when it should be expecting JSON.
Is it even possible to secure Web Api with WIF?
Not sure whether I got you right, but it seems like the main problem is that javascript/ajax does not support http redirects.
A possible solution could be to simulate the redirection with a sequence of seperate calls in ajax:
Check whether you are authenticated on your web api site (by a dummy ajax call).
If this is not the case:
Call your sts over ajax and grab the security token out of the "wresult" form field.
Call the login site on your web api site and pass the security token as "wresult" data.
Dominick Bayer wrote a few blog posts about securing rest services. For further reading have a look at http://www.leastprivilege.com/. (Especially http://leastprivilege.com/2009/09/11/adding-a-rest-endpoint-to-a-wif-token-service/ and
http://leastprivilege.com/2010/05/05/thinktecture-identitymodel-wif-support-for-wcf-rest-services-and-odata/).
The following presentation from TechDays might also be interesting: http://www.microsoft.com/showcase/sv/se/details/ffc61019-9756-4175-adf4-7bdbc6dee400 (starting at about ~ 30 minutes).
I have an asp.net app. It has a page that requires authentication. The authenticated user can view the page because he/she is authenticated. The page makes a jQuery Ajax call to a WCF service. The WCF service checks that the user is authenticated via HttpContext. I have a user that is using WinXP and IE8. This user can authenticate to the page, but when the Ajax call is made from the page to the wb service, the user recieves my "session not authenticated" message on the page, generated by the service and displayed on the page. When I use the same OS/browser combo, the page and service work just fine, as expected; no errors.
What option in this user's IE settings would cause this behavior?
It turns out that I was just being stupid and was violating the "same origin principle". My service was at mydomain.com and my user was probably on a page at www.mydomain.com. The service would fail because the domains didn't match completely. So, I setup some re-write rules on the server so that no matter what variant of the domain that was requested by the browser, it would always re-write to www.mydomain.com. Then, I simply set the the service call to the that domain (or in this case, just used window.location.hostname), and all problems were resolved. Big "D'oh" moment.
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.