i'm trying to secure some WCF services. I'd like to use IIS or the Web.config todo all of the heavy lifting/configuration if possible. I don't want to embed anything in my code - thought I know that may not be feasible. If possible, I'd like to achieve this without having to resort to AspCompatibilityMode :(
I'm using a custom BasicHttp binding with TransportCredential enabled.
This works fine. Any valid domain or machine account seems to validate against the service.
My problem is I only want users from specific windows groups to be able to access my service. I wanted to use ACLs on the actual folders to achieve this, but I don't think it is possible.
Would appreciate your help!
Thanks
TM
In your web.config try the following:
<authentication mode="Windows" />
<identity impersonate="false" />
<authorization>
<allow users="MYDOMAIN\YourGroup" />
<deny users="*" />
</authorization>
This will block it at the web config level. You can also put an ACL on your folder. Note the Windows authentication and the impersonate = false means that it is the users credentials that are being used to access the directory.
Related
I'm new in asp.net world. I'm building asp.net mvc 4 web application. It has basic http authentication. At the beginning it ask user name and password. After authentication it start some view. During debug if successfully authenticated and continue debugging to some other view/controller. If I stop debugging or app crashes. For the next debug run it never prompt me for authentication. It takes to the view which comes after authentication. I suppose it caches my authentication from previous run. I try to find solution from net and found many suggestion such as :-
Restart iis
Remove cache files from c:\Windows\Microsoft.NET\Framework\v4.0.30319 and C:\Users\user\AppData\Local\Temp\Temporary ASP.NET Files
Modify web.config and rebuild, then lunch.
Remove browser cache.
Even restart pc doesn't help-
I tried all nothing is working. As I'm new I'm not sure is my web.config file has right configuration for HTTP basic authentication. Here it is:-
<system.web>
<compilation debug="true" targetFramework="4.5.1" />
<httpRuntime targetFramework="4.5.1" />
<identity impersonate="true" />
<authentication mode="Forms">
<forms loginUrl="~/Account/Login" >
</forms>
</authentication>
</system.web>
My environment windows 7, iis 7.5, visual studio 2012. Please advise me how can force authentication every time or start as in initial state. Thanks in advance!
It's the browser cookie that is letting you in as it's still valid for your application. Clear your browser cookies or start an in-private session.
I have an ASP MVC 4 application which uses a 3rd party HTTP module for security. When using Windows authentication it will attempt to automatically log you in, if that fails, then it will redirect you to a custom login page.
This has been working fine for previous ASP Webforms and MVC 2-4 applications, but for this particular application it is failing to automatically log the user in.
The application's virtual directory has all of the authentication modes disabled (anonymous etc) except for Windows authentication which is enabled. I have also checked that the provider is Negotiate and NTLM.
The web.config is a pretty standard one that you get from the MVC template and I have tried various web.config changes to system.web and system.webServer (and changing app pool's pipeline mode) such as:
<system.web>
<authentication mode="Windows"/>
and also adding
<authorization>
<allow users="*" />
<deny users="?" />
</authorization>
But in each case the security module cannot get the user name. The module attempts to get the user name via HttpContext.Current.Request.ServerVariables["REMOTE_USER"], but I have also modified it to use HttpContext.Current.User.Identity.Name and in both cases it is blank.
Since this module has been working fine for years and still works for other applications on the same server, I believe it is an IIS or Web.config configuration issue. I have tried creating a new virtual directory and it has the same error.
Is there any additional configuration required or another reason why it is not working for this particular application?
The solution was to add the following to my the appSetting section in my web.config
<add key="autoFormsAuthentication" value="false" />
<add key="enableSimpleMembership" value="false"/>
</appSettings>
This is the first time that I have needed to add such a thing, so I am not sure why it is necessary, but it does work.
I have an ASP.NET WebApi application running locally using IISExpress that allows me to accept requests from any domain. I am doing this using a DelegatingHandler similar to the one provided one this blob post.
Locally this runs perfectly however after uploading to an Azure Website, I get the typical 'Origin http://localhost:8080 is not allowed by Access-Control-Allow-Origin.' under Chrome.
I've tried to debug this by adding trace statements into the Handler with no output and it seems like SendAsync is never being executed, almost as if IIS is responding to the OPTIONS request instead of passing it on to my application.
Has anyone come across anything similar going from development to production?
IIS (including the one in your Azure web site) has a default OPTIONS handler. You will need to remove it in Web.config. It answers the OPTIONS call before your message handler has an opportunity to respond.
<configuration>
...
<system.webServer>
<handlers>
<remove name="OPTIONSVerbHandler" />
...
</handlers>
</system.webServer>
</configuration>
I am learning and designing a WCF service. I have picked to use Windows credential as the authentication method, and I have configured it correctly, hopefully, because I can see the authentication audit log from event log viewer when I am testing my service hosted in the local machine.
But now I come up with this weird question: what users will not be authenticated under such configuration? Does my service authenticate all Windows user within the same Windows domain, or can I specify what specific users within my domain will/will not get authenticated?
Or, does it mean that I can only control what users (in my domain) can perform what operations my service is providing through authorization(that I know how to do)?
It sounds simple but all the material I found only tell you how to perform authentication, doesn't say how to deny authentication request.
Update:
After reading #syneptody answer, I still have two questions:
I must say my confusion between authentication and authorization is still there. The authentication means to identify the user. But if I want to tell a user belonging to the same domain as the service host(it's IIS, by the way), who just makes a request to my service, "you are not authenticated", what I really should say is "I do authenticate you, but you are not authorized (to perform your request)", is it right? There is not a state of "Unauthenticated" for a user in my domain? And what if a user not belonging to my domain makes a request? My service will tell him "You are not authenticated" or "You are not authorized"? As long as this user has an identity, the service will authenticate it, and continue to investigate whether it should be authorized?
#syneptody mentioned This "authorization" element. It belongs to ASP.NET, and it specifies which roles can/can't access the resource (whether it is the website or an application hosted in the website, depending on which Web.config file it is in). Is it right? But what if I don't use ASP.NET or don't host the WCF in ASP.NET Compatibility Mode, will it still work like that? Actually the requirement for us is to only provide the service, so I didn't think of using ASP.NET because in my opinion it is more like a web client consuming my service.
By the way, my usage scenario is this service will be hosted and consumed within intranet. So I choose Windows credential for authentication and Windows Groups for role-based authorization because it requires minimum work in my opinion.
Take a look at this article:
http://msdn.microsoft.com/en-us/library/aa702682.aspx
It does a pretty good job explaining the connection between WCF and ASP.NET. If you are able to run your services in ASP.NET compatibility mode you can use the ASP.NET authorization rules. In a domain environment where you can leverage Integrated Authentication there is no easier way to provide authorization to your services.
Your service implementation:
[AspNetCompatibilityRequirements(RequirementsMode AspNetCompatibilityRequirementsMode.Allowed)]
[ServiceBehavior]
public class Foo { ... }
Then in your configuration:
<system.web>
<authorization>
<allow users="?" />
<allow roles="DOMAIN_SECURITY_GROUP" />
<deny users="*" />
</authorization>
<authentication mode="Windows" />
<identity impersonate="false" />
</system.web>
After having searched for an answer thoroughly on SO, I have to ask my first question for good this time !
Here goes :
I have a Windows Forms app, which uses a dozen WCF services to handle all the business logic.
WIF is implemented on every single WCF service, and users are authenticated through a basic UserName authentication.
Everything works well except the Ping() method that we have.
Before WIF was implemented, we used to call every WCF service with a dummy Ping() method during the splash screen to ensure the service was up, but now the user can't access this method since he's not logged yet.
Is there a way to distinguish Authenticated and Anonymous Methods in a service on which WIF is implemented ? I suppose there isn't, so I'd like to know if maybe an anonymous token could be issued by the STS ?
I'm pretty out of ideas right now, so any help or just some hints would be greatly appreciated :)
Depending on your configuration, you could create a set of services within a specific folder in your site, then add custom configuration to that location that would not include the Authentication and Session modules.
As an example:
<location path="AnonymousServices">
<system.webServer>
<modules>
<remove name="WSFederationAuthenticationModule" />
<remove name="SessionAuthenticationModule" />
</modules>
</system.webServer>
</location>
I have not tried this in practice, but it should work.