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.
Related
I have 2 web applications, one is ASP.NET MVC 5 + WIF hosted in IIS, another is a web service based on WCF and self-hosted. Both of them are under same domain (so there are no security issues to change cookie format) and referring to the same STS (in same security realm), so theoretically if one user already authenticated, he should be able to access other entities within same security realm without authentication.
However, these 2 websites are using different session token format. For ASP.NET MVC 5 project, it uses WIF implemented standard security session token and serialized to cookie; for WCF web service, it uses its own token/cookie format.
Then we have a problem.
When user navigates from ASP.NET MVC website to WCF web service, because WCF web service cannot recognize WIF session token (FedAuth and FedAuth1), so it redirects user to STS and login again, that is not the biggest problem, the biggest problem is, after use logged in, and POST raw SAML2 token back to WCF web service, WCF web service creates its own format token and tries to set client cookie, it actually doesn't work, I guess maybe there are already FedAuth and FedAuth1 cookie in header so header cannot accommodate more tokens (4K limit?)? Having thought about this for a while, there are are several solutions come into my mind:
Unifying token format. I need to subclass SecurityTokenHandler (maybe also need to subclass CookieHandler), use the same token format that WCF service uses, so when jumps to WCF web service, it can recognize the session token. That needs to dig deep into FAM and SAM.
Force re-login. I can clear FedAuth and FedAuth1 cookies before navigates to WCF web service, it is acceptable that user needs to login again, this is a short term fix, but how can I capture this navigation away event and clear cookie? The only way I think I can do is before I change window.location.href, use jQuery.cookie to clear cookie, I am not sure if it is the correct way, this is my first question.
Adding a cookie translation layer between ASP.NET and WCF, use WIF session token in ASP.NET website, and when jumps to WCF web service, change the token format. But for this solution I don't know how to capture the jump action and how can I get raw SAML2 token? May be I can save it in WSFederationAuthenticationModule_SecurityTokenReceived event handler? But how to deal with multi tokens from multi users and multi sessions?
Are there other better suggestions?
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?
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).
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.
Here's the situation, I've got a console application that needs to run once a day and make a few requests to pages that require authentication to view. The pages are hosted in a really basic ASP.Net Web Application.
So, I know that in order for the requests to go through successfully I have to authenticate with the server. So I've hooked up the console application to the ASP.Net Membership Provider I'm using for the web app and it successfully determines if a set of a credentials are valid. However, after calling Membership.ValidateUser() any requests I make just get the login screen. After doing some reading it seems that this is because I'm missing the important cookie information that persists my login or what-have-you.
I'm using a basic WebClient to make the requests and then reading/discarding the result.
So the meat of the question is this: Is there a simple way to validate the login information and hold on to it so that I can make the requests successfully, or is this the exact same case as the other two questions I found that require the WebClient to make a "manual" login request to the login.aspx page and try to hold on to the cookie from there?
The questions I'm referencing are:
Authenticating ASP.NET MVC user from a WPF application
and
Login to website and use cookie to get source for another page
With FormsAuthentication the webserver has to generate a Forms Authentication Ticket for you. The best (only?) way to do this is to log into the site, so I'd just log in like the other questions.
If the intent is to send data to the server and/or get data from the server, then the most logical architecture is probably to create a web service using either ASMX or WCF. Then configure the service to use a security token, such as a username token or a SAML token. This will make the client less likely to break when the server code changes its data model.
Otherwise, if you wish to use only a basic WebClient, then you will have to find a way to pass your credentials to the login page and retain the login cookie that is returned from the login request. Then, make sure that the login cookie is included on all subsequent requets, similar to the Stack Overflow question that you referenced, "Login to website and use cookie to get source for another page".