I have a monotouch application that currently calls a hosted WCF service in IIS using ssl and basic authentication. I need to move this wcf service to Azure and am confused on the best security practice. I've read to use ACS, but I can't find any examples of using that setup with monotouch and am not sure it will work. Does anyone have any examples or suggestions with calling a WCF service from monotouch securely in azure?
Thanks, Ben
I am not familiar with MonoTouch. But as far as the service side is concerned, you can continue to use SSL and basic authentication. Note by default IIS basic authentication require Windows credential. Since it works locally, I think you’ve already implemented a custom basic authentication module. Another area to note is it needs additional steps to support SSL in Windows Azure. You can refer to http://msdn.microsoft.com/en-us/gg271302 for a tutorial. ACS is usually used if you want to support claim based authorization.
Best Regards,
Ming Xu.
Related
I'm struggling with securing IIS hosted svc WCF service hosted in Azure using WIF and ACS.
I found lot of how-tos here:
http://msdn.microsoft.com/en-us/library/gg185939.aspx
I'm particularly interested in those describing how create secure WCF service and authenticate using certificate or username/password.
Now the ACS definition part is pretty clear. But when it comes to securing the service itself I struggle. I'm using WebRole and SVC file to expose the service and the configuration in how-to is done in code and I guess it won't work with azure webrole as well.
Any help on how to get this combination working would be much appreciated!
Just a small clarification: if you rely on ACS then the authentication (in whatever form: certs / username/password, etc) will happen in ACS, not in your app. Your WCF service will simply expect a token issued by ACS and will remain largely ignorant of the type of authentication used.
Also, the actual implementation depends on whether you are creating a SOAP service or a REST one. Typically you have different token formats and protocols involved (e.g. SAML vs SWT, etc.)
Besides the how-tos you mentioned, take a look at the samples in this guide. Especially these:
http://msdn.microsoft.com/en-us/library/hh446528.aspx
http://msdn.microsoft.com/en-us/library/hh446531.aspx
Hope it helps
Most probably you need to use a HttpModule to secure your service. The primary responsibility of this module is to read the Authorization header and create the claims.
Also make sure in the web.config tag should contain
You can get the code for HttpModule from the below sample.
http://acs.codeplex.com/wikipage?title=ACS%20Windows%20Phone%20Sample
Look at the ProtectedResourceModule.cs
Joy
I have client apps that talk to my silverlight application and its web services. So the client app is running on the client machine and making calls directly to the silverlight app running on the machine and also making web service calls.
I want the usernames/password security to be handled by the 3rd party client app.
Any idea how I can do this?
I'd try the Application Scenario's, Guidelines and How Tos sections of this CodePlex Link. You should be able to find a scenario that matches closely to yours and follow the guidelines and configuration to get yourself going.
If I've understood this correctly, the client application would pass a username/password to your silverlight app which would require a wsHttpBinding that has clientCredentials="Username". You would need to be able to authenticate this against a user store configured on your server, for example you could configure a SQL Server provider.
I'm not sure how your 3rd party client app works, but you would require a seperate security configuration for that communication. You could use a less secure binding if the apps were on the same machine and possibly use clientCredentials="Windows"/"None"/"Basic".
Difficult to advise further without knowing your exact situation. What do you have so far?
I have an application that uses Silverlight and ASP.NET as a front-end. It retrieves data from the server by calling some RESTful WCF services that are hosted there. I'd like to prevent the curious user from opening up a new browser window and calling the web service themselves. Is there a way to restrict access to the web services to a specific application?
Thanks!
You can use HTTPS to secure the endpoint and require authentication. You can put an obnoxiously long secret key embedded in the code. Unfortunately, System.Security.Cryptography is not in the SL install, so no encrypt on server/decrypt on client capabilities. And there's no reason the user couldn't just use something like reflector to read the code anyway.
SL can be made "mostly securish", but definitely not secure.
Here's the guide of the Patterns & Practices team for WCF Security. There's a lot to be found there.
http://www.codeplex.com/WCFSecurityGuide
If you're truly interested in securing your web services, you should think about migrating from RESTful services to SOAP Based Web Services and implementing the WS-Security standard for Message based Encryption.
You can then secure your services so only clients that have the proper security information (be in username/password or X.509 certs) can call your web services.
Update
As you can see...I've removed X.509 as an option. I blanked for a moment and forgot the WS-Security limitations in Silverlight. The good news is that you can implement username tokens based on the WS-Security standard in Silverlight:
Implementing Username Password & WS-Security with Silverlight
No there's not.
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
I want to expose few web services but thinking of hosting those as Windows Service as against hosting in IIS.
Is it a good practice?
If yes? How do I make it secured?
I want to authenticate the users who are accessing it (against our custom security database and also want to make sure that the request is originating from our business partner (X.509 certificates???? not worked much with this).
appreciate your pointers in this regards.
Thanks & Regards,
Ajay
You might want to read this Microsoft article , which clearly points Pros/cons of each hosting method, including: Console/WinForms App, IIS 6 and 7 (there are differences) and Windows Services.
If you are using IIS6, using a Windows Service is a must for many scenarios. Windows Services are 100% supported and a 100% safe way to host WCF. You can secure them with the same options as in IIS.