I'm developing a corporate web application.
The devices it is supposed to run on devices that have MobileIron and a corporate profile installed.
The app uses a corporate authentication service that authenticates based on client certificates. When I open the app in the Safari browser - the authentication is working properly. But in order to provide some of the features the app had to be wrapped in a PhoneGap shell. And the authentication has stopped working.
As far as I understand it is due to the fact that the UIWebView is unable to get the certificates from the device.
Is there any way to entitle it to or implement the handling myself?
Using MobileIron AppConnect, you can distribute certificates directly into those apps (instead of to the system keychain, which is only accessible to the built-in apps like Safari). The app can then be coded to provide that certificate to the web server when challenged. This is pretty easy to do.
http://support.mobileiron.com/appconnect will have the details.
Related
We are developing an iOS application in Xamarin, which will be distributed via MobileIron. We are also developing the Backend WebServices (rest).
What I need to know is, when a web service call comes to my API, I want to make sure, that the call is coming from a client who is logged-in to my app with his Active-Directory credentials, using MobileIron.
The MobileIron website has plenty of information, but is also a bit chaotic.
What MobileIron products are needed for my use case?
Whats the best way to protect my WebServices and allow just requests from our iOS Application with correct AD-Credentials?
Do I need the AppConnect SDK or can I just wrap the iOS Application in MobileIron? If I need the SDK, are there any examples?
Thanks in advance!
Cheers
Immi
Here is one way how it should work, we have this built up in our environment.
Assuming that the target devices are managed by the MobileIron MDM system with MobileIron Core (MDM) & MobileIron Sentry (Gateway -> Intranet).
You can configure MobileIron Sentry in this way, that a webrequest from an AppConnect enabled app (no matter if SDK included or wrapped!) will be authenticated with user certificate from device, Sentry obtains Kerberos ticket from domain controller for the user and then forwards the web request to a website / webservice where Kerberos authentication is enabled and the user has access granted.
There are many things to configure for this to work (CA, user certificate -> device, service account with delegation configured in AD, SPN for website configured in AD,...) and there is a good support document available from MobileIron to make this up & running.
It's to extensive to describe here all steps.
If this is already setup in the target environment (if there is already another AppConnect app), there are only a few steps left (SPN and MI app-specific AppConnect Config).
The good news is, that the app itself does not have to take care of the authentication. The MobileIron stuff does this on its own...
We are currently trying to add OAuth2.0 for authentication into an existing Adobe AIR mobile app for a client. We are trying to carry this out by using this library https://github.com/charlesbihis/actionscript-oauth2 from this article.
We have tried using instances of the 'StageWebView' class and the Feathers UI 'WebView' class to display the authorization prompt page within the mobile app itself.
When we publish the app locally on our development PCs, the whole process works ok. However, as soon as it is published to our iPad(s) for testing, it is almost as if some security setting stops the "embedded" website from communicating with to the server.
As the website we are trying to communicate with is a https:// address, I'm assuming that this might be causing issues, but I can't confirm this.
Has anyone out there found themselves in a similar situation?
Thanks,
Dave
I want to record web requests using fiddler of an iOS7 native app which using https protocol (with trusted certificates) to communicate with server. I could able to record the requests and after Https decryption option disabled and its worked fine. When Https decryption option enabled app shows invalid/untrusted certifificate alert and cannot proceed even after installing fiddler certificate in iOS.
Question is,
Is there any way to record Https request/response of iOS7 app using fiddler by imitating any other certificate as trusted certificate or anyother way to do that? any suggestions? any other tools? I got another solution from here but it was not worked.
Thanks in advance
You need to use the Fiddler Certificate Maker add-on to generate certificates that iOS is willing to trust.
See http://blogs.telerik.com/fiddler/posts/12-12-21/using-fiddler-with-apple-ios-devices for more information.
Also keep in mind that some iOS applications (like the AppStore) use a technique called "Certificate Pinning" which means that you cannot decrypt their traffic seamlessly unless you jailbreak the device.
In the Facebook App Settings ☞ Advanced ☞ Authentication I can pick "Web" or "Native/Desktop" as App Type. The info bubble says:
Only select Native/Desktop if you are a Native iOS or Android app,
device, or Desktop app
Actually I am none of those but my app is a Native iOS App as well as a Facebook Page Tab.
Question: Which App Type should I pick?
I did some research and found the following in the Facebook Android Tutorial (under Troubleshoot):
App type Web vs Native/Desktop. Does it matter?: No, it does not
matter. However it's recommended to use the type 'Native/Desktop' for
your app.
What does it mean it does not matter? That does not make sense to me. Why should I have a choice then?
I did some more research on SO and found this statement by #Igy (dev support engineer at Facebook):
If the app's type is set to 'Native / Desktop' it's assumed you
distributed the app's secret key with the binary, and thus the app
access token isn't trusted (and 'getAccessToken' in the PHP SDK will
only work when real users log in, it can't fall back to the app token)
Finally I found this in the Facebook documentation:
Note: Applications that are configured as Native/Desktop apps will not
be able to make API calls that require an application access_token.
I do need to make API calls which require an access token from my page tab app, hence my conclusion is to pick "Web" as the App Type, although I'm having a native iOS app using the same app ID as the page tab app. But will that have any drawbacks on the iOS app?
TL;DR: use 'web' unless you're putting the app secret into the iOS / Android binary
The primary difference (and also the reason that it says 'it doesn't matter' while also giving a recommendation) is that if you choose 'native/desktop' mode, it's assumed that you distribute the app binary with the application secret embedded and the app secret is considered untrusted.
In this configuration, API calls which use the app secret (e.g. creating test users, making API calls on behalf of the app itself like changing app settings, posting achievements, etc) will not work.
If your app doesn't need to use the app secret / app access token, setting it to native/desktop increases the security somewhat as there's one less attack vector for your app.
If you're distributing the app secret with your code you MUST use that option or users could easily determine the app secret and hijack the app itself.
I've received the following restriction on a mobile web app which doesn't make any sense as SSO only applies to native apps..
"This application will not be accessible on iOS unless SSO is configured"
How do I resolve this problem?
You need to configure SSO for your native app using the Instructions for SSO in section 3 of the iOS SDK documentation - once you've done that the app will be accessible as normal.
If the app doesn't have a native iOS version, your app is probably restricted from being accessed from inside Facebook's native app due to not complying with Apple's policies about iOS-approved payment methods.
You'd need to take it up with your lawyers or Facebook's policy team if that's the case - all i can answer here is the info on how to enable SSO for your native app if applicable