I am currently working on a project that has an iPad application that uses JSON to call WCF services hosted with IIS. One of the requirements is that the WCF services needs to use IIS Basic Authentication to login. Once the user has been authenticated from the database, a few values need to set to a cookie for return trips to other WCF functions (similar to asp.net session variables). Is this possible with WCF and using cookies to hold state? If not, any recommended method?
Thank you.
WCF absolutely supports basic authentication. http://msdn.microsoft.com/en-us/library/ms733775.aspx has details on this. WCF will then identify this user on all messages that come through.
If you want to implement a customer authorization mechanic, you will need to implement ServiceAuthorizationManager. I've recently done something similar where I have iOS clients that use OAuth to authenticate with our services. I have this implemented a ServiceAuthorizationManager to determine who they are and what privileges that they have. Might be worth looking into.
Related
I have a WPF application that uses Client Application Services to allow authentication (username/password logon) against a related web application that uses Forms authentication and the SqlMembershipProvider/SqlProfileProvider/SqlRoleProvider. This all works and I can reliably validate a user/password combination.
The WPF application also calls a number of WCF services that are exposed by the same web application as is used for the CAS authentication. I now want to be able to pass through the authentication details (from Client Application Services) to the WCF services in order that I can identify the user that was authenticated within those services. I also need to be able to prevent the WCF services from being used if no authentication has taken place.
I have found a couple of .NET 3.5 examples where CAS authentication is used against .asmx web services, or authentication is provided against WCF Data Services which does not use ClientBase and has authentication facilities built in, but I cannot find any examples with pure WCF. Can anybody point me toward instruction that will enable this scenario? I am using .NET 4.0 for this project.
I have also found this stackoverflow question but again this is answered for .asmx web services and not for WCF.
The closest I have gotten involves the creation of an OperationContextScope and then copying the cookie header from the ClientFormsIdentity object to an HttpRequestMessageProperty and adding this to the OutgoingMessageProperties of the current OperationContext. I then call one or more methods of the service within the lifespan of the OperationContextScope. Thing is, when I then get to the WCF service, I still cannot see anything that resembles authentication in such a way as I can identify the original user. This methodology has been taken from various examples but I am obviously missing a step at the WCF end.
I think you need to switch to the Web API that Microsoft is now having people use for WCF Services. Check out Using Forms Authentication with Web API and http://aamirposwal.blogspot.com/2012/05/aspnet-web-api-custom-authorize-and.html
Found it.
In my binding, I specified allowCookies="true".
According to Wiktor Zychla, "setting the AllowCookies property on a BasicHttpBinding to true turns on the automatic cookie management" - this means that any attempt to set a cookie in code will be ignored and this is what I was doing.
We write a WCF web service.
How can we call it's methods in JSON format?
An additional issue is how can we secure our web services.
I'd like to use Microsoft Membership and Roles providers for users authentication and authorization. The question is how to do this. Is it possible to do authentication and authorization behind-the-scenes (in context of WCF), or I must call ValidateUser() and IsUserInRole() in every web method for every user call?
Whether I restricted to use webHttpBinding (over wsHttpBinding) because our client-side programmer familiar with AJAX/JSON? Whether there are any restrictions of webHttpBinding concerning using Membership/Roles comparably comparably to wsHttpBinding?
Thanks a lot in advance!
Ilan.
Basic question here (I think), I was hoping someone could point me in the right direction. I don't know much about WCF but I'd like to create a web service to be called from an ASP.Net MVC application. The goal is to make sure only authorized ASP.Net users (we're using forms authentication) can call the web service, not just anyone. Are there tutorials out there I can look at on how to approach this? Many thanks.
I assume from the question that you don't care what the end (MVC) user ID is that is hitting the WCF service (in other words you don't need a specific authenticated user to hit the WCF so you can get the ID of that specific user (i.e. so you know that joeBobUser hit the WCF)). you just want to make sure that user is authenticated and authorized to use the site. You don't need every potential user of your MVC app to be authenticated/authorized.
As long as that is true, then my approach would be as follows:
run your MVC app as a specific, known user account (i.e. set up the app pool in IIS to runas a domain user such as yourdomain\youMvcAccount) instead of the default asp account. There are lots sites that have instructions on how to make this happen if you are not already running your mvc app as a domain user.
set up your WCF service endpoint configuration binding as WsHttp. Again, many sites describe how to do this. here's one that does it via GUI (I prefer hand-editing the config but whatever). So now your WCF service will only accept secure, authenticated requests
create your WCF client proxy in the MVC app. easiest way to do this (probably not best re: separation of concerns, but just to get started) is just add new web service and discover you WCF endpoint that way. Again, basic stuff easily googable if you don't know how to do that.
Now your MVC app will be making the call to the WCF service authenticated. However, at this point, any client authenticated in your domain can call the service. You are now accepting ONLY authenticated but ANY authorized user. All calls issued from your MVC app hitting the WCF will be from the identity yourDomain\yourMvcApp
Restrict authorization to the identity set in #1 restricting (authorizing) authenticated users can be done a number of ways. The get'r'done fast way (but not very flexible as any change requires recompile) is just to check the identity of the request is the same as the identity of your WCF service directly in your service call. Alternatively, you can set up more robust (with the concurrently more goo) options such as AzMan or other WCF authentication rule sets. Again, many sites have instructions on setting that sort of thing up after you have an authenticated user. Here is a SO question that limits authorization to a windows group post (I'd do it that way--more flexible but you need to add that user to a group on your domain), and another article that goes more into the details of WCF security and allowing only a specific user access to the service.
I need help on securing my WCF Service so that only authorized users can make a call to service methods.
The WCF Service is configured with wsHttpBinding and is hosted under Windows Service.
The client application is an asp.net website. Also, the users making call to WCF service are already authorized by client application, so just need to make sure that they are authorized while handling the request on service side.
Please guide me on what are the different ways (along with their pros and cons, if possible) to achive above.
Thank you!
If you are using the ASP.NET role provider infrastructure, you could pass the user on and leverage the same provider via WCF. This would be nice as it would maintain logic across the process boundaries.
If you are using Windows groups for ASP.NET, the same would apply, just re-authorize.
Certificates are an option, but then you have to manage them.
Lastly you could issue an access token and validate it on the WCF side. This could be done by extending WCF(probably at the contract level). You would then have to manage the token via some other service to enforce expiration etc.
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