I am building an iOS app that is going to be used internally within my company. An administrator wants to be able to give certain employees logins to use the app across multiple devices.
For example, Administrator will assign Employee A and Employee B their own username and password. The app will be installed on Device X, Y, and Z. Employees A and B need to be able to login to any device (say, Device X), do stuff in the app and save their changes, and then login to another device (say, Device Z) and see their changes. Administrator would like to be able to manage the logins within the app (i.e. after entering an administrator password).
I have looked into iCloud Keychain to store the username/password pairs but it sounds like Keychain is meant to only be used with one Apple ID (which I assume all company devices would be attached to one Apple ID so maybe Keychain could work).
In summary, my questions are:
Where can I securely store user login information (if not on Keychain)? Do I need my own server or are there services within the Apple API that would help accomplish this?
How can I utilize the logins from any device with my app?
Are there any APIs or Wrappers that would simplify this process? I found Locksmith but I'm not sure if it will work for what I need.
I appreciate any suggestions!
You will need a back-end server. However, if you are looking for a simpler solution, I would recommend AWS Mobile Hub:
https://aws.amazon.com/mobile/
They provide Authentication and NoSQL services without having to setup your own servers. All in all, it's a pretty comprehensive offering.
Related
I have an app on store and all client are used it. Sometimes some client needs additional feature that isn't wanted by others so in that case I make AdHoc build for that particular client, but it is not proper solution.
I think on Enterprise solution but apple not allowed to distribute outside the organization in it and I have all users are clients.
If your app has a user login, download a user specific configfile directly after login and check in code for feature availability by looking into it. Large companies like Spotify and also startups do it this way to test new features without releasing them to all.
I have a developer account and I'm developing an app for someone. I want him to be able to change datas in CloudKit so I want to use his iCloud account(He doesn't have a developer account, just personal account). However, i don't know how to differentiate my developer account and his iCloud account.
Thank You
I believe CloudKit's notion of public and private databases may achieve what you need to do. As a reference, I am referring to slide 45 in Apple's WWDC presentation on cloudkit (http://devstreaming.apple.com/videos/wwdc/2014/208xx42tf0hw3vv/208/208_introducing_cloudkit.pdf)
Considering that each app has a container, and that container includes 1 public database (that all users of the app can access) plus a multitude of private databases (one per user), if the data you're storing isn't private, then consider storing it in the public database. You can modify it as needed during development by being logged into your iCloud account, and your client can modify it as well by being logged into his iCloud account. (Apple docs say the public database is stored in the App developer's iCloud space)
If you store the data in the private database, however, it will be written to an instance of the private database belonging to the currently signed-in user. So anything you write would go into a private database instance (which Apple docs says resides in each user's personal iCloud space) and anything he writes would go into his private database instance. Until recently, that was the end of the story. However, now, cloudKit supports CKShare which, in a nutshell, allows a user to grant access to specific shared items inside their private db. So you could still write the data to a private DB but allow access via a CKshare.
Finally, there's another option, but I don't recommend it. In the device settings, you can log out of iCloud and log back in as another user. In which, you're still developing on your device, but you're logged into iCloud as your client. This has many drawbacks, though. First and foremost, credential sharing is always a bad security practice. But, probably a more immediate consequence will be your device will no longer be sharing with/backing up to your iCloud account, but instead with the client's.
It's hard to give more specific advice without better understanding the scenarios you're implementing.
** update based on OP's comment **
I see now. Using the development cloudkit dashboard probably isn't going to work. AFAIK, you must log in with a development account, not just an iCloud account, to use the cloudkit dashboard. So your client won't be able to get in at all, anyway. You could add your client's email address as a member of your development team, which will let them log into your cloudkit dashboard; however, that also gives them access into portions of your iTunesConnect as well. And, it really won't scale to support additional users of your app.
CloudKit data, and most iCloud data outside of iCloud Drive, is sandboxed to individual applications. This makes sense from the standpoint of securing user data from leaking from one application to another without their control. However, with my own iCloud credentials as a user, I have access to all of my data via the apps which own the individual buckets.
Is it possible, as a technical user writing code on my own machine (not something that would be distributed in the App Stores), to enumerate, read, and/or write data as myself in the iCloud buckets of applications which I did not create?
I am particularly interested to do this on a Mac (with developer tools and unsigned apps allowed), and am willing to assume that I know the bundle IDs of the buckets of interest. Being able to enumerate all buckets which exist for my user would be even more useful.
If you have the same developer account as the original app, then you could create a 2nd app that could use the same CloudKit container. You do have to be aware that there is a developer and a production database. You can only access the production database with a published app (Could be a TestFlight only distribution)
There is a way to access a container that is created by someone else. But then you do need to get an API access web token which can only be handed out by the developer account of the original app. You could then access the container using the CloudKit Web API
Keychain access groups and application groups are both segregated using the app's team id.
Named pasteboards are also sandboxed using the team id.
Kerberos SSO seems to work well, but opening the KDC to the internet is a security hazard so it can only really be used together with a VPN.
The Shared Web Credentials API works well between native apps, but has intrusive popups showing up every time you attempt to access or even just check for the existence of credentials.
libdispatch can send messages to arbitrary apps, but the payload is limited to 64 bits and the recipient app must be currently running.
No unique device identifier that could be used to derive a key for a cloud-based encrypted KVS can ever be shared between apps not on the same team id.
…is there any way to share credentials (or any data, for that matter) between applications signed with different team ids, on recent versions of iOS? Apple doesn't allow migrating IAP, Passbook, etc to new team ids and it's blocking my team from implementing SSO between apps with historical team ids (M&As, etc).
You can open the app with deeplink that will reopen the other app with the infos you want to pass along. That's good for login but can be cumbersome if you want to pass a lot of infos back and forth.
I'm working on an iPhone app that is logging into a webservice and it's been asked of me to get the account login management into the settings page (i.e. next to Twitter, Facebook and Vimeo). From what I've been reading about the accounts framework, it appears that only those few companies have that ability.
I currently have it set up and working asking for login info periodically and polling the webservice for validation, but we're trying to move toward supporting moderately offline use, which means we need to have some sort of account info managed on the phone itself.
Can I use the built-in account framework for our own login credentials or is that not something that's available to a regular dev and I'll have to look for another way to do it on my own? Is that something that the keychain would be better for?
Using the keychain to securely store the users credentials is a good idea to start.
If I am understanding your question about a "built-in account framework", I don't believe there is a local framework for account management on the device itself that I am aware of that would be useful in this circumstance.
I've had to build an app that needed to authenticate to a web service that also needed to have some offline access. I ended up recording the validated authentication date and time in the NSUserDefaults and would let the user use the app for a 48 hours period before they had to re-authenticate. Their data was queued locally and when they had online access again, I would re-authenticate and then sync the data. Not the most elegant solution but it fit the project.
I used AFNetworking (http://afnetworking.com) to track the changes in network access and used to blocks to respond to the changes.