I have an application where it should be possible to choose whether you want to use the built in security (basic username and password) or the windows authentication. How do i make this possible for my application? different endpoints for each type?
I concur with your suggestion: the service should expose different endpoints for each authentication type, and the client will programaticaly select the appropriate endpoint.
The authentication type is a property of the Transport or Message security (depending upon which mode you are using), and the security settings are a property of the binding configuration.
So you would need to create two separate binding configurations. Then you would create two separate endpoints, each endpoint referencing a different binding configuration.
Related
We need to expose two WCF endpoints in a single Windows service. One endpoint should use claims based authentication (WIF), with the other using certificate authentication. Unfortunately all our attempts have failed because WIF configuration attaches to all WCF endpoints; the endpoint which should use certificate authentication requires a token.
I can’t find any solution to this particular issue. Is it possible to expose two endpoints within one windows service with two different authentication where only one of them is WIF, and if it’s possible, then how?
Read
How to mix WIF and non-WIF endpoints in a single WCF <service>?
There is no way to do it unless you use two different service contracts (this could be just marker interfaces though) or you do things manually without WCF (i.e.: create your own behavior and claims authorization manager using WIF). It's not that hard, but you need to understand how things work.
I'm using custom basic authentication module (http://www.custombasicauth.codeplex.com) for authenticating users in WCF service. I've used a custom membership provider and in the ValidateUser method I've making a db call and returning true if the authentication succeeds. I also created a binding that uses transport security for the WCF service. Everything works fine now the problem is the client want two endpoints to be created for the WCF service and the custom basic authentication should happen for one endpoint not for the other.
Is it really possible to achieve this by using the custom authentication module or I have to try some other ways?
This is not possible when hosting your service in IIS. IIS has authentication scoped per whole virtual directory and your endpoints are exposed on the same service = single resource in single virtual directory. You must either move to self hosting and host service in windows service (you will not need that module anymore) or you must deploy the service again to different virtual directory or web application and change security configuration in each deployment separately (= every endpoint will be in separate deployed service).
I have a web project that has Anonymous access and Integrated Windows authentication enabled. I built a WCF Data Service and since it allows only one authentication, I enabled Integrated authentication on the service. I am able to view the service in browser. However when I try to query the service for any Entity, it gives me Forbidden error. I tried to enable Anonymous access on service too, but it does not work.
Do I need to give it some other access or it is not possible to enable one authentication on the service itself keeping the project virtual directory as Anonymous and Integrated.
Update: I do no have any operations in my Data Service. For the entities, I have already set the "All" permission on all entities.
Only one authentication method is permitted on a WCF Data Service.
If you choose to go the Integrated Security route then you need to set the credentials after constructing the DataServiceContext.
Something like this would work for using the current user's Windows identity.
employeeEntities = new EmployeeDataService.EmployeeEntities(new Uri("http://.../employeedata.svc"));
employeeEntities.Credentials = CredentialCache.DefaultCredentials;
I'm using a WCF service with the NetNamedPipesBinding to communicate between two AppDomains in my process.
How do I secure the service so that it is not accessible to other users on the same machine?
I have already taken the precaution of using a GUID in the Endpoint Address, so there's a little security through obscurity, but I'm looking for a way of locking the service down using ACL or something similar.
See http://blogs.charteris.com/blogs/chrisdi/archive/2008/06/23/exploring-the-wcf-named-pipe-binding-part-3.aspx for one way to do it via ACLs.
you can use WCF authentication. One of the options is to validate against the windows username and password. If you use active directory, you can use that too (harder to set up, put less of a burden). http://blogs.msdn.com/pedram/archive/2007/10/05/wcf-authentication-custom-username-and-password-validator.aspx.
WCF NetNamedPipesBinding has only Transport Security
http://msdn.microsoft.com/en-us/library/ms731699.aspx
Is this a shared PC? Do you have several users logging on locally to the same physical machine?
Is there a clean way to expose a WCF REST service that requires basic authentication, but where we handle the actual validation of the username/password ourselves? It seems that when you tell WCF in config that you want to use basic authentication, it forces you to turn on basic authentication in IIS and IIS can only do basic authentication against window accounts.
The only hack we have found is to lie to WCF and tell it there is no security on the service and then do authentication outside of the WCF stack using a generic IHttpModule (which has a proprietary config file to indicate which URLs have which authentication/authorization requirements).
It seems like there should be a better way. Anyone have one?
The WCF REST Contrib library enables this functionality:
http://github.com/mikeobrien/WcfRestContrib
It also allows you to secure individual operations.
is the username and password set on the client like:
cc.ClientCredentials.UserName.UserName = ReturnUsername();
cc.ClientCredentials.UserName.Password = ReturnPassword();
Or are they embedded in the body of the REST message?
If the former, you can use a custom UserNamePasswordValidator:
http://msdn.microsoft.com/en-us/library/aa702565.aspx
If the latter, you can set the service to no security, and use a custom ServiceAuthorizationManager to validate the contents of the message:
http://msdn.microsoft.com/en-us/library/ms731774.aspx
Hope one or the other helps! I'd try to post sample code & config, but I'm # home and dont have access to code, which is all # work.
See Custom Basic Authentication for RESTful services. Pablo's approach uses the interceptor functionality that is provided via the REST starter kit to solve the problem. If you do not want to depend on the REST starter kit, then you can create your own service host and use the inteceptor functionality provided.
If you host it on IIS, using custom http module is the way to go. You can bring over the principal over to WCF side to do code access security. See HTTP Basic Authentication against Non-Windows Accounts in IIS/ASP.NET (Part 3 - Adding WCF Support). Also see Custom HTTP Basic Authentication for ASP.NET Web Services on .NET 3.5/VS 2008.
If you are not using IIS, you should be able to implement userNameAuthentication. See Finally! Usernames over Transport Authentication in WCF.
Yes absolutely there is a way. You need to configuring a custom userNamePasswordValidationMode value for your service and point it to a class with an overridden method that can inspect and validate the credentials provided. When making a RESTful call, these credentials when using Basic authentication in its proper form should be in the request header. With this custom method you can inspect the credentials and then authenticate the client to your service. No Windows accounts or domain even needed.
The nice thing is you can then take that security context to the next level and provide fine-grained authrization at the method level. You might have instances where a large pool of clients are able to access the service, but not all methods within (i.e. paid clients vs. unpaid). In this case you can also provide authorization at the method level as well if needed.
Below is a step-by-step solution (with too many steps to embed) by me that contains both the needed configuration and security required to have a complete solution. The problem is often Basic authentication is used without securing the Transport with a SSL certificate and this is bad. Make sure to follow all the steps and you will implement Basic authentication without the need of any type of Windows accounts or configuration on your WCF RESTful based service.
RESTful Services: Authenticating Clients Using Basic Authentication