I am developing an MDM Server for my office(around 20-25) so that we can push our company's IOS apps(only 2) to users devices. We will not be managing the devices.
There are around 20-25 sub-offices around the globe and each has their own server(hosted only in intranet) and set of users. None of them intervene with one another.
The APNs Certificate way of MDM looks convenient to me.
I have looked at few MDM providers. They ask each customer to create their own APNs certificate in the Apple Certificate Portal. Why can't the MDM providers have their own APNs certificate and use it to manage the devices of customers?
Can there be a centralized MDM Server which provides its SSL Certificate details, APNs Certificate details and Profile details for the .mobileconfig and also take care of profile and app installation
so that users will connect to the centralized server and download the .mobileconfig but the individual servers should decide on who should download the .mobileconfig and see the status of installtion of apps on those particular devices?
Is this solution possible?
My company uses Airwatch and there is very little user setup. We download the Agent, tech department sends a qr code to email, user scans it, puts in their username and email for our network, and it just does all the setup. Then they can go to a catalog and download our applications. I develop these applications and have enrolled maybe a hundred devices and haven't had to do much of anything on the client side.
What you are saying would work if you change the phones OS to check into this central MDM server. This would actually break Apples streamlined way of doing this. Hate it or love it, APNS makes it so there is only one way of doing things.
iOS does not allow it but Android does.
You have to think like Apple to see why the MDM vendors have you make an APNS push certificate to give them. Say one day, your MDM server goes absolutely bonkers and starts sending commands every second to devices that makes them unusable for users (constantly locking the screen or erasing devices every day). How can Apple prevent your rampant abuse of the MDM protocol that is ruining customer experience? Well, if they revoke the APNS certificate, you can't command your devices any more as the devices will never get notified there are new MDM commands, and the users will no longer be affected.
If there was a MDM vendor who had one APNS certificate for hundreds or thousands of different companies, the abuse by a single company could lead to Apple revoking the APNS certificate and now all those other companies are unable to use their MDM because of one abuser.
Related
I'm building a server-side "push" notification capability for various (specific) iOS apps my company makes. I'm not a mobile developer. I understand there's a "p12" certificate I'd need, and that the mobile client must provide the "token" I use to initiate the push from the server.
Does anyone know if there's a pre-built developer/test iOS app in the store that will display a token, has a downloadable cert, etc., and will accept push notifications? I'd like to build the server-side out a bit before I try to plug in the real tokens/certs for my companies apps.
No there isn't, but there are 2 separated environments one for test and one for production.
Usually the app developer team should provide the certificates to the back end developer team.
Once you have your certificates you can integrate them in the backend.
Pay attention that certificates are app specific, they work only for a given identifier.
During test both the team should work together to see if everything work as expected.
Token can be track in a different way, in debug mode using real device by printing them in the console log or by using a particular configuration file, in both cases the device must be connected to Xcode.
You should ask the dev team if they can provide you a sample app that print the token on the device screen and that just send the token to the server to make your experiments.
I am very new to iOS app development and APNs. I have developed two apps which are configured to receive push notification.
In my test environment, I am hosting two APIs apiAppX and apiAppY written using Javapns library on same machine. apiAppX and apiAppY generate push notifications(alerts) for appX and appY respectively. I am using different p12 file for different app.
The problem is, if I generate APNs certificate for appX first then it receives notification but appY doesnt. If I generate APNs certificate for appY first then it receives notification but appX doesnt.
I think this issue is being caused because I am hosting two providers on one machine. I came to conclusion after reading this documentation. Especially, after reading following paragraph:
Note that provider connection is valid for delivery to only one specific app, identified by the topic (bundle ID) specified in the certificate. APNs also maintains a certificate revocation list; if a provider’s certificate is on this list, APNs may revoke provider trust (that is, refuse the connection).
Am I right?
Thanks.
I developed a MDM setup where I could able to push apps into the iOS devices. My main bottleneck here is giving the URL to the user via e-mail and asking them to install configuration profile. I want to automate this process. At once the user login with his Enterprise Wifi's username and password the configuration profile should be installed into the devices.
You question is kind of controversial.
You say "where I could able to push apps into the iOS devices" and literally next sentence " via e-mail and asking them to install configuration profile".
It's not clear whether you are sending emails and asking users to install an app or you are pushing an app (meaning that users doesn't have to do anything).
Couple of notes:
1) As I remember, you can't completely automatically it (install apps without a user intervention).
The small caveat - it's possible for supervised devices.
2) If you want to semi-automate it. You can use MDM protocol. As soon as a device is enrolled into MDM server, MDM server can issue install application command and a user will be prompted to install an application. However, ultimately, he/she will decide whether to install it or not
3) Making all of these happen on a user logging to Enterprise WiFi could be even more trickier. I would say, you will need to have a captive portal. You will prompt a user to enroll into MDM on it when he/she connects to this WiFi. And as soon as a user is enrolled, you can install applications + setup client certificate authentication for Enterprise WiFi to distinguish devices which was and wasn't enrolled in MDMD.
I have two Applications in iTunes. A free version and a paid version. The paid version does not have advertisement. The two versions have different App Ids.
I have set up APNS for one of the App Ids. How can I handle notifications for both Apps?
Each application requires its own certificate (since each App Id has its own push certificates).
Therefore, your server will have to hold a different certificate for each App, and maintain a separate connection with the APNs server for each App (since you use the certificate to open the connection).
This means that when one of your apps sends a device token to your server, you have to know which app sent the device token, and mark it accordingly in your DB (in order to know which connection to the APNs server to use when pushing a notification to that device).
I'm developing a iOS app. This app has two targets (free version and premium version). Then I want to send push notifications throw my Service Web.
So, Do I need two certificates? Because my app (free or premium) uses the same Web Service and the same database. And when I want to send a push notification, now do I have to store and look if it's one version or another?
Can I use one certificate? Can I merge two certificates in one?
Thanks.
You can't use one certificate, since each certificate it tied to an App ID, and the App ID is different for each App (it contains the bundle ID of the App which is unique for each App).
You must use two certificates, which means your server will have to know which Device Token belongs to which App, and use the appropriate certificate. Perhaps, when you send the device token from your app to your server, you should send some additional info that indicates which App sent the token).