iPhone web service calls to WCF Service with Certificate Authentication - iphone

We are a .Net shop that has standardized on WCF Services. We are in the processs of developing an iPhone application that needs to make secure web services calls to obtain data for the app. To ensure secure communiations we have enabled SSL on our web servers. But this does not ensure the service can only be consumed by authorized apps. We have configured our services to support x509 certificate authentication. Is it even possible to call a secure WCF service with certifcate authentication from an IPhone app?
I have spent many hours searching the internet for examples but to no avail. I HAVE been able to successfuly call an un-secure WCF service with no issues. I have also done a lot of research on the WS-Security and WS-Trust communications standards. I believe I understand how this should work. I am just having trouble piecing together the steps/objects within the iPhone frameworks I need to make this work.
Any thoughts and ideas on the subject would be greatly appreciated.
Also, any thoughts on any of the following:
How best to deploy the P12 certifcate file with the iPhone application
How best to secure the password for the P12 file within the app
Is deploying the P12 file with the app a best practice
Are there facilties within the iPhone frameworks to support this kind of secure communication? If not, what would be an alternative recommendation.


For starters, I'd say if you are really serious about security please dedicate the proper time and resources to it and treat it like a first class citizen in your feature list. Don't just "turn on SSL" and pretend things are secure. I'm not suggesting you are doing this or not doing this, but I just feel like I have to say it before proceeding.
That said, you probably already know that WS-* is all built on top of http requests, and any time you are doing loads of http requests, you'll probably find ASIHTTPRequest very helpful on the iPhone. However, that will not get you 100% of the way there.
From the iPhone's perspective you have:
The URL loading system, which is a high level API for dealing with network resources of any kind
The CFNetwork C API which is lower-level and allows you a great deal more control of encrypting streams and network traffic any way you see fit
The Certificate, Key, and Trust Services that do the heavy lifting, and more specifically the X509 trust policies
On Macs you get to use Secure Transport, but as far as I know they haven't ported that to the device so I wouldn't get too distracted reading up on that unless you are planning on bringing this to the desktop or are just in the mood to learn everything :)
If you are doing any security with WCF, the first thing you probably realized is that there are many options available to you, but it all boils down to this short list:
Transport layer security (https) with clear text messages (xml/json/...)
Message layer security (encrypted message body) over an open transport (http)
Secured messages over a secured transport
The last time I was doing WCF (about a year ago) the general recommendation from Microsoft seemed to be Message layer security over an open transport because of firewall / accessibility issues introduced when trying to secure the transport. However, this approach assumed that all parties involved were .NET / WCF capable. I believe it would be easier to consume on the device if it were an HTTPS transport level security, with clear XML or JSON message bodies. That way you can take advantage of all the stuff baked into CFNetwork and NSHTTPRequest that Apple has done.
Once you get something working, you'll want to refer to the Enterprise Deployment Guide, and specifically the documentation on Over-the-Air Enrollment so that you can install the certificates on the devices. Remember, anything is possible, and don't be afraid to use one of those Apple support tickets that come with the program :)
EDIT:
I completely forgot to mention the GenericKeychain and CryptoExcercise examples
EDIT 2:
After I got downvoted for no apparent reason I re-read my response and realized I rambled a bit too much without actually answering your question about how to open a p12 file on the device. You ought to be able to simply [[UIApplication sharedApplication] openURL:urlToP12FileEitherLocalOrRemote]] and have it kick out to the OS for the installation procedure.


You can also use ssl + user/pass authentication at the message level.


Generally, if you want to install certificates on the iPhone, there are two options I have found (both of them from here):
Email the certificate to the recipient. If it is a valid certificate and the headers in the email are in order, then it will allow the recipient of the email to install the certificate. The problem here of course is a man-in-the-middle attack.
Use the iPhone enterpirse configuration utlity.
That should get you part of the way there (installing the certificate locally). I should note that in general, you don't want to install one certifiate for the entire application, but have separate certificates for your users. As a general practice, authenticating the application is a very bad thing, whereas you should be authenticating the user.
However, if you are authenticating the user already, then this shouldn't be an issue, as using basic authentication over HTTPS would work just as well (and easier to code).


I agree with Yaron Naveh's solution too, probably the best bet is to use SSL. I believe SSL/TLS encryption is better performance wise than message/XML based encryption in WCF too.
I think the certificate would probably need to be from a trusted CA (certificate authority) for this to work though. From memory, I had difficulty with the iPhone SDK with self-signed certificates, but that may well have changed in the last year...


An iPhone should be able to access a Certificate-secured WCF application. If you make your WCF service a RP of Azure ACS it should work using OAuth among other methods.
Take a look at the samples here for more: http://acs.codeplex.com/

Related

Why do API's have different URLs?

Why do API's use different URLs? Is there two different interfaces on the web server? One processing API requests and the other web HTTP requests? For example there might be a site called www.joecoffee.com but then they use the URL www.api.joecoffe.com for their API requests. Why are different URLS being used here?

We separate ours for a couple of reasons, and they won't always apply.
Separation of concerns.
We write API code in one project, and deploy it in one unit. When we work on the API we only worry about that and we don't worry about page layout. When we do web work, that's completely separate
Different authentication mechanisms.
The way you tell a user to log in is quite different to how you tell an API client it's not authenticated.
Different scalability requirements
It might be that the API does a lot of complex operations, while the web-server serves more or less static content. So you might want to add hundreds of API servers around the world, but only have 10 web servers.
Different Clients
You might have an API for the web client and a separate API for a mobile client. Or perhaps a public one and a private / authenticated one. This might not apply to your example.
Different Technologies
Kind of an extension of Separation of concerns, but it allows you to have Linux server for one and use something like an AWS Lambda for the other.
SSL Wrangling
This one is more of an anti-reason (particularly for the specific example you give). Many sites use SSL for both web and api. Most sites are going to use SSL for the API at least. You tend to have SSL certificates matched to your URL, so there might be a reason there. That said, if you had a *.joecoffee.com certificate you would use api.joecoffee.com not www.api.joecoffee.com (because apparently an extra '.' in your URL costs more, or something like that).
As #james suggested - there's no really right answer and some debate.

Does WSO2 EMM (MDM) support OMA DM and/or TR-069 client participation?

WSO2 EMM looks like a very interesting effort. I am looking for OMA-DM and optionally TR-069 client support as well. In other words, the ability of a device with an OMA-DM client to enroll and be managed by WSO2 EMM. One might say that what want is an OMA-DM server, but in fact, I am looking for a server that can address both mobile device (smartphone/tablet) as well as "other" device management options.
Thank you in advance!

WSO2 EMM doesn't support OMA-DM or TR-069 client support (yet). As a core developer involved in the project I would certainly raise these protocols as important features to address in the future releases.

From WSO2 EMM right now what we have tried (please note that I am a core team member) to address is the management of mobile platforms which are popular these days. For this we have dealt with the MDM APIs provided by the platforms. For this its not necessary to dig into the implementation details of MDM protocol under each platform since its upto the MDM vendor to provide and implement it.
Note: As far as I know Windows supports OMA-DM. Anyway in a future release there will be Windows phone support.
To add additionally to your point, if you think it from a different angel its also possible to integrate OMA-DM clients. For this the implementation of the EMM needs to be done adhering to the server aspect of the protocol. Yes this is perfectly possible and if there are real use cases or need we might go for it.

Data Synchronization between mobile and webserver

How would you implement a data synchronization solution that ensures data on a mobile device and web server are in sync.

Take a look to this tutorial (part one and part two), basically what they do is add a timestamp attribute storing the last modifications. It is developed to synchronize with the parse.com backend service but it is extendable to any backend.

We use a Unix-Timestamp in our company for this. The Server is comunicating with us in json over tls and client is using AsyncSocket. For Web-Server (https) you can take for example a REST-service and ASIHTTP for client. But our solutions are used for client independent services, so if you have only access with IOS/OS X it's maybe easier to use other solutions for direct synchronization :)

securing a WCF service for consumption by iphone

I have a WCF service that needs to be secured to be consumed by an iphone app. I would like to know what my options are. I looked around the net and found that using SSL or api key or username/password over SSL is an option but I wasn't able to find any links about how to properly implement them for consumption by an iphone app. I'd really appreciate if someone could point me to the right direction.

Configure the WCF service for basicHttp binding and transport security. To make the client side of things work, you will need to implement an NSUrlConnection delegate. The phone will then be able to authenticate correctly. You can use the Keychain to store the user's credentials.
Stay away from the WS-* protocols that are typically turned on by wsHttp binding. These greatly increase the complexity of the XML you need to read and/or generate.
Although the phone can receive and send XML, it's not nearly as convenient as in .NET. You might want to consider a simpler serialization format such as JSON. This will require the use of webHttp binding.

Alternative to building a proper web service for iPhone app to consume

I am in the process of scoping the development of an iPhone app for a client. Among other things, the app will allow users to browse through and place orders on specific (tangible) products.
The client has a website that currently does a similar thing and due to their limited budget and the fact that the website runs on a third-party proprietary platform which they have no control over, we are investigating possible alternatives to building a web service.
On the website, user registration and authentication, as well as order placing is done through POST requests via secure HTTP. The response is always a formatted HTML page which will contain strings indicating whether the request was successful or not, and if there was an error, what the error is etc.
So provided I can replicate the POST requests on the phone, and parse the HTML responses to read the results of each request, do you think this is an acceptable alternative to building a web service to handle this?
Apart from the possibility of pages changing (which we can manage) and the fact that I will probably have to download and parse a relatively large HTML response, are there any other drawbacks to this solution and is there anything else that I might be missing?
Many thanks in advance for your thoughts.
Cheers,
Rog

You could create an intermediary server that will communicate with the client server, and on it expose some REST web services with json (small overhead and easy to handle) responses that will be consumed by the iPhone app.

So, you're going to parse HTML and formulate POSTs off a third-party server, and pray that they don't even so much as rename a form field.
Your question is in two parts:
Do I think that a miracle is an acceptable solution? I don't.
Do I think that aside from the fact a miracle is required, are there any other drawbacks? None that I can think of.
You didn't ask, but this is a terrible course of action. Two suggestions.
I spy an assumption that the providers of the third-party platform aren't interested in enabling third-party applications by providing an API. They have a very good business reason for this, which is that it promotes platform lock-in. Reach out to their support department and have a talk with them.
You have to sell the client on building an intermediary web service. To at least try to mitigate the damage that changes on this third-party platform can do to your app, I recommend that you build and operate a proxy that receives requests from your applications, and proxies them over to the third-party platform. You should build into this client-server protocol a means for returning "we are in maintenance mode, go away" messages to apps, for that inevitable day when the third-party server changes something that breaks your app (they swapped the billing and shipping address pages, for instance) and you have to rush through an update through Apple to deal with it.
The proxy could be written in something more flexible and easy to bash stuff out in, such as PHP, Python, Perl, or Ruby. It could be hosted at Amazon in a micro instance.
p.s. This question is inappropriately tagged objective C.

HTML is the worst because of parsing (1-2secs per page), memory, and changes, but you already know that. Check in advance that ALL the data you need is exposed on the HTML.
If you use an intermediary server you are moving work elsewhere and you have another server to maintain. I would only do that if memory is an issue. Check How To Choose The Best XML Parser for Your iPhone Project for memory/performance/xpath support. libxml2 is a good option, but it depends on your needs. And maybe you'll want to check ASIHTTPRequest features before using the SDK.

I think utilising the web language of JSON would contribute to the diminishing of the parsing time. By building a REST service that, when sent a GET request, returns the correct information for easy sorting, you could then display the output a lot faster than that of parsing straight HTML.
I prefer JSON over XML, but everyone has their personal preference. You should look at a few very good libraries that are built specifically for parsing purposes of both XML and JSON.
For XML I recommend using the inbuilt libxml parser. Albeit, this can sometimes deem very difficult to use. A simple Google search will bring up a heap of results that relate specifically to what parser should be used depending on what task is to be completed.
As for a JSON parser, I recommend SBJSON. I am currently using it one of the biggest projects I have undertaken and it is definitely working perfectly for my use.
If you need a good way to connect to a RESTful web service, you should try LRResty.

Don't go for a parsing solution on the iPhone for 4 reasons:
Server can change their design and break your application (AppStore submition is long) + They can also detect that the request are sent from an application based on user agent which you have to update the application to change it.
Some of the requests might be made thru Javascript so you not only have to parse (X)HTML but also Javascript request (which can be in the form of XMLHttpRequest, but don't have to)
Long term evolution of the mobile market : maybe your client want (or will want) an application for android, Blackberry, Bada OS (Samsung), Symbian (Nokia/ OVIStore), Java Mobile or Windows Phone 7?
Of course network traffic, Memory and CPU needed to parse HTML (look the time it takes to the browser to do it?)
Regarding the traffic, if the application will not have a huge traffic you can home-host your proxy. Or you can find some provider to host it for you. I guess you won't need more than a couple of Megabytes of storage but maybe traffic. For less than 100€/year you can find some with unlimited traffic (like OVH Pro plan or Infomaniak). But if you want to go Java have a look at Google App Engine : you pay only if your traffic is important and if your application generate many CPU Cycles. If not : you don't have to pay. And it's hosted on Google server : reliable.

If the client is open, you could consider the paypal API.