I have an ASP.NET site running on Azure at https://[appname].cloudapp.net. I also have an asmx web service running as a subapp in the same instance at https://[appname].cloudapp.net/WebService.
The root site is protected with passive ADFS authentication. Since the web service inherits settings from the root application's web.config, it is also protected.
My problem is that when I make web service calls, the FedAuth cookie is not getting passed along to the web service and I always receive the STS login page as a response from the web service.
How can I make use of the FedAuth cookie retrieved from signing into the root app to authenticate my web service calls?
You should make the web service anonymous and handle a different type of authentication (assuming the service needs to be secured). You cant "pass" the FedAuth cookie because that lives in the browser. So unless you do the Web service call from the browser using ajax you wont be able to do it. One thing you could do is passing the original ADFS SAML token to the web service and validate it, but that wont be trivial in asmx.
<location path="WebService">
<authorization>
<allow users="*" />
</authorization>
</location>
Related
I have an intranet ASP.NET WebAPI application providing a REST API and we want to use Windows authentication to secure the URLs by setting allowed groups in the web.config like:
<authentication mode="Windows"/>
<authorization>
<allow roles = "someGroup1"/>
<allow roles = "Somegroup2"/>
<deny users="*" />
</authorization>
</authentication>
From this page it sounds like this will fit our needs, but there is one issue I am not sure about: If we have an existing 3rd party application (not .NET) that is on the same network that consumes our REST service, will running this application as a user account who is a member of an allowed group allow the application to connect to the REST API successfully? From the asp.net site:
For .NET client applications, the HttpClient class supports Windows authentication:
HttpClientHandler handler = new HttpClientHandler()
{
UseDefaultCredentials = true
};
HttpClient client = new HttpClient(handler);
It looks like you have to take some special steps inside a client application to authenticate using Windows credentials.
Does anybody know if this solution will work or there is a workaround to allow 3rd party applications to authenticate using Windows credentials?
If the application is running on a separate server this won't work unless you are running in a kerberos environment. What you are describing is a two hop scenario that is not supported in the default windows authentication environment. Basically, by default, an application can't take the security credential from one server and go to another server with it. Google two-hop security and you'll find plenty of information on why it doesn't work.
I have developed an ASPNET WebAPI service that uses form authentication with cookies.
I also have a main website which authenticates against my ASPNET WebAPI and serves some content from it.
So my workflow basically is:
Client/Browser authenticates against the main website.
Main website (server) authenticates against ASPNET WebAPI and receives an authentication cookie.
After logging in the client will need to access some content of the ASPNET WebAPI via server and also via browser.
I would like to know if it is possible to re-use the same cookie that the server received in the browser. Ideally my website server receives the cookie and push it to the client browser. I am assuming that ASPNET Authorisation cookies are not IP-specific, since the client browser and the server IPs are different.
Thanks.
It should be possible by modifying your configuration such as:
<forms loginUrl="login.aspx"
name=".ASPXFORMSAUTH"
protection="All"
path="/"
domain="yourdomain.com"
timeout="30" />
Remember that both sites must be on the same domain, and the cookie path must be set to a common root or /.
I am trying to make a mixed mode authentication to be able to put some users on Federated authentications and others on Forms authentication.
I am working with WIF, I set up my STS and everything is happy, when I am in federated mode by turning off all the authentication this way:
<authorization>
<deny users="?" />
</authorization>
<authentication mode="None" />
I log in to my main application then when I log in to my side application it will let me log in silently since the session cookie is already generated and the user is authenticated.
but when I use Forms authentication, when I log in to my side application it will take me to the login page which I understand because the user is not authenticated but it seems even with having the session cookie it is not silently redirecting it.
I know that I need to redirect onEndRequest to the STS to authenticate the user and if the user is already authenticated then it will generate FedAuth cookie and and it will log me in silently,
does anybody know how to implement this, I didn't find resources about it when I researched.
Alaa
For all who needs to setup federated user authentication in asp.net app the following link might be extremely helpful:
http://blog.elis-co.com/wif-sso-and-forms-authentication-in-asp-net/
Also http modules included to the config from the link above are outdated. So correct them with ones from the following article:
https://learn.microsoft.com/en-us/dotnet/framework/security/how-to-build-claims-aware-aspnet-web-forms-app-using-wif
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'm trying to make a call to the SharePoint Search Webservice from an Asp.NET 4.0 application that does not reside on the SharePoint server. Everything seems to work, accept it is using the AppPool's credentials (a domain service account) to authenticate to SharePoint, which only returns results that that pin has access to. What I need to be able to do is impersonate the calling user, so that I get results for that user and not the domain account. I've set the server that the application is running under up to be trusted for delegation to the http spn that the SharePoint server is using, but I get a 401 error when doing the impersonation in my code. What could I be doing wrong?
you have to impersonate your call to the sharepoint web service.
you can do this at a web application level, with either the calling user or a static user, inside the web.config in the system.web node using the identity element, i.e...
<system.web>
<identity impersonate="true" />
</system.web>
or you can do this with inline code when you make your requesting call.
here is a microsoft KB on how to impersonate with an asp.net application. http://support.microsoft.com/kb/306158