I'm planning to develop an Android application with an app-engine backend.
However I would like to refrain from using authentication (either with Google accounts or Open ID). Since the data will be sent only from my app and not any other client, and will be over SSL connection, I consider the data safe and trusted.
So my question is two-fold:
Is there any security issue I'm missing here ?
All the examples I found use some sort of authentication. Is it at all possible to use the android appengine infrastructure (RequestFactory, etc) without authenitcation ?
An app engine application is just a regular web application deployed on app engine. If you need to authenticate your users, do so. If you don't need to, then don't.
You're missing something, though: once a web app is deployed on app engine, it's accessible from anywhere on the web, and so anyone (and not just your app) could send requests to this application, whether you use SSL or not. SSL will just make the communication encrypted, and ensure the client that they're talking to your web app, and not to a rogue web app maskerading as yours.
Related
I'm working on a project which is a mobile application developed with Ionic. The project is split into two parts: a mobile front-end and a back-end. The back-end is performing all the calls to external services and applying business rules, while the front-end only calls my back-end.
One of the services I'm using is a IAM service using Oauth2 protocol. I've implemented the authorization code flow to integrate this service. Until now, I was always using the command ionic serve to run my front-end in a web browser, and everything is going well.
But now, for testing purposes, I need to run my front-end in an android emulator. In order for my front-end to contact my back-end, I'm using the IP 10.0.2.2 (which is the alias of the loopback of my machine where my back-end is running).
The problem is with the redirect of the authentication service. It is not something that I have control on, and it can take weeks or months for the service provider to update my client configuration. When I want to authenticate myself through the app running on emulator, it opens a InAppBrowser to perform the authentication. When I successfully authenticated myself against the service, the redirect URI is http://127.0.0.1:8080/xxxx, and this response is sent to that InAppBrowser.
My question is:
Is there a way to replace the base URL of that response (without changing the client configuration), so that I can send the call response to my back-end ?
NOTE: I've been trying to find a solution online, but I can't find anything on that topic. I suspect that in that matter, I probably lack some vocabulary in order to find what I'm looking for.
Is there a way to
The following idea is in our heads and we did not find out how to realize it.
We have a responsive web application that is based on a domino server using xpages. The service authenticates using SAML against our adfs 2.0 service.
We want to use native mobile apps to improve the mobile web app it two disciplines:
1. use notifications to alert users about tasks and events
2. Store the password in a secure way on the device so it won't be asked every time you use the app.
The web app stays on that domino server and is used as is.
I thought this should be possible using only bluemix services.
But how?
We do not want to develop native apps by ourselves so apache Cordova came in our minds. That or a similar solution should enable us to provide native mobile apps with in app stored passwords (or tokens or even touchID logon) and mobile notifications.
Which is the best bluemix practice?
Bernd,
you have a rather large set of technology moving parts here :-). Let me pick them into pieces:
Domino: you need something outside of Bluemix for storing the NSF, like a Softlayer Domino server. That will be key to the solution.
mobile app: Cordova is right, but look one step further and have a look at Ionic. It uses Cordova under the hood. You can add it to your app as is, or use IBM Mobile first foundation
Push notifications: there's a service for it in Bluemix
Authentication: there's a service for it
What I would do:
on the Domino server holding the NSFs deploy a OSGi plugin you write extending Domino Access Services that reads/writes the data you are interested in JSON. Use the OpenNTF Domino Api (ODA) to make your life easier
configure the server to only talk to Bluemix. I would use VPN technology for that - Bluemix has a service for that
Now the fun part: configure Domino to accept the WAS headers for user identity. Securing Domino in the step before is ESSENTIAL since hitting it direct would now allow to spoof identity. This is why ONLY your Bluemix VPN shall hit it
Now build your app layer in Bluemix using Liberty or Node.js (I would use Node.js since passport, a Node module, has the most authentication options) that handles auth using the Bluemix services and sets the header when talking to Domino
Make sure you use a web worker in your mobile app to take the network out of the user experience
That's roughly it. Hope it helps
How can one find out which or what an app is using as a back-end server?
Assume you are making an app and you are using Parse.com as your back-end server. You made an app and go published it to the appstore. Later, what are the odds for some one else to find out what did you use as a back-end server? Can she/he find out that you used Parse.com ?
What are the odds for an iOS app and Android playmarket app ?
Simply see what networks calls are being made by the app. No need to decompile or anything like that. Simply log network calls on your home network. Your Wifi router might do this or you could setup a proxy server that logs all requests.
I'm building a mashup app for Android Wear, using speech recognition so I can post to Fitbit's API. Single-purpose and pretty simple. I generated the OAuth 1.0 credentials with the excellent Temboo library and granted access in a desktop browser, then naively hard-coded those keys and tokens into my app and let Temboo take care of the HTTP requests and API calls to Fitbit.
I've gotten errors from Fitbit stating that my requests are being refused by Temboo's server because of invalid OAuth signature (Fitbit uses OAuth 1.0). I've come to the realization that I probably need to have the user grant access on the wearable app itself. I'll need to launch the mobile browser and pass it the authorization URL from Temboo in a WebView, then have the user grant access, and then pass this approved data back to the watch.
Is there a pattern for doing this in order to allow access to third-party web service APIs already? I've not seen documentation on it so far. Does anyone have a tip on how the authorization process would flow for a wearable watch app?
Thanks much!
There is no web browser or direct internet connection on Android Wear devices - all web connections must be done on the phone part of your app and then forwarded to your Wearable app via the various Data Layer API methods - using messages is an easy way to send information in a lightweight, time sensitive manner.
Therefore your phone app should do all of the OAuth dance as part of an initial setup.
What is the best solution to secure a REST service provider (assume a java servlet running on google appengine) by allowing requests only from iOS or Android device from a specific app?
Assume I have a servlet running on google appengine that does some processing and responds to a GET request with some JSON data. And I want to restrict this access to my app that runs on Android and iOS.
My current solutions are:
Use if(tokenValue ==
request.getHeader(tokenKey)) on the
appengine servlet. And
response.addHeader(tokenKey,
tokenValue) on the mobile apps'
code. So basically only my app would
know the token key.
Use HTTP(s) for the above solution, appengine supports this
Use oAuth - but I need to have the user sign-on to some oAuth provider from the app, which complicates the app
Suggest other useful approaches to tackle this problem. Assume this servlet only serves GET requests and maybe use Restlet or Jackson
Only 3 would be an appropriate solution if security is important to you. This is because anyone using the application can intercept the traffic and just replay the values against your web service. SSL offers some protection but a good attacker can work out how to capture data if they control the device. With OAuth the damage done by an attacker is limited to a single user (as long as they are not an app admin).
How about using a client SSL certificate? I haven't tried this, but I'm considering it. Here's a page that describes the approach, with some sample code:
http://blog.crazybob.org/2010/02/android-trusting-ssl-certificates.html