[aerogear-dev] Push: Security / role model

Tue Apr 9 17:45:35 EDT 2013

yeah - that's totally out of scope; it just covers sending, not device
registration, similar to the java lib (github.com/notnoop/java-apns) I am
using in my POC (https://github.com/matzew/ag-up-poc)

from reading (not using), I think this is a better node apns lib (for
sending only):
https://github.com/qualiancy/apnagent

it;s very interesting, there are only libs that do one of the following:
- device registration database (e.g. helios)
- sending API for ONE push network (e.g. serveral apns / gcm libs, for
different languages/platforms)

Our AG Unified Push POC does already both, for two networks (APNs / GCM)

-Matthias

On Tue, Apr 9, 2013 at 9:37 PM, Bruno Oliveira <bruno at abstractj.org> wrote:

> Might be another topic, not sure. Did you get a chance to look at this
> https://github.com/argon/node-apn?
>
>
> --
> "The measure of a man is what he does with power" - Plato
> -
> @abstractj
> -
> Volenti Nihil Difficile
>
>
>
> On Tuesday, April 9, 2013 at 2:32 PM, Bruno Oliveira wrote:
>
> > Hi Matthias, for the authentication method let me know if some of those
> workflows works for you https://developers.google.com/accounts/docs/OAuth2
> ?
> >
> > For encryption I'm working on ECDH (
> http://en.wikipedia.org/wiki/Elliptic_curve_Diffie%E2%80%93Hellman) but
> if you're in hurry we can stick with AES only (if you really want some
> encryption).
> >
> > I'll be working on a bare minimum crypto specification (suggestion) for
> the client side, but words don't compile. So I've been testing it before.
> >
> >
> > --
> > "The measure of a man is what he does with power" - Plato
> > -
> > @abstractj
> > -
> > Volenti Nihil Difficile
> >
> >
> >
> > On Tuesday, April 9, 2013 at 1:20 PM, Matthias Wessendorf wrote:
> >
> > >
> > >
> > >
> > > On Tue, Apr 9, 2013 at 5:53 PM, Matthias Wessendorf <matzew at apache.org(mailto:
> matzew at apache.org)> wrote:
> > > >
> > > >
> > > >
> > > > On Tue, Apr 9, 2013 at 4:47 PM, Matthias Wessendorf <
> matzew at apache.org (mailto:matzew at apache.org)> wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > >
> > > > > as you know the unified push server has a 'registration' component
> (see here (https://gist.github.com/matzew/69d33a18d4fac9fdedd4) for
> details; see here (https://gist.github.com/matzew/2da6fc349a4aaf629bce)
> for REST APIs) which does the following:
> > > > >
> > > > > app registration and adding multiple variations
> > > > > registration of an installation, submitted from the device
> > > > >
> > > > >
> > > > > There are different roles (as also discussed in the above
> links).... The "app registration" functionality can be only achieved by
> something like an "admin";
> > > > >
> > > > >
> > > > > The admin can create a logical app construct on the server ( Sport
> News mobile ), which has different variations:
> > > > >
> > > > > free for iOS/Android (no user required, everybody can install the
> app)
> > > > > paid (same, for both: iOS/Android): User is required, since they
> pay for extra, exclusive content
> > > > >
> > > > >
> > > > > Now.... the "logical" app construct on the server get's some ID,
> when the app has been registered... (similar for each of the variants:
> iOS/iOS-paid etc...)
> > > > >
> > > > >
> > > > > This part of the registration needs to be protected, very well
> (e.g. OAuth); just thinking out loud.... But yeah... only users, with the
> proper rights should be able to register (update/delete) apps here!!!
> > > > >
> > > > > Device/Installation registration
> > > > >
> > > > > However, the other part of the registration (when an installation,
> from a device, tries to register itself for wanting to receive messages),
> may be a little more "weak"...
> > > > >
> > > > >
> > > > > Scenario:
> > > > >
> > > > > Someone downloads the free iOS app:
> > > > > once he launches the app and he agrees on receiving push messages
> > > > > Now... the app should send the generated token (generated by the
> actual Push Network), to the registration server... (otherwise it can't
> receive push messages :-) ).
> > > > >
> > > > >
> > > > > So...... the following information needs to be available.... so
> that the mobile dev. for the free iOS app can register the token with the
> server:
> > > > >
> > > > > APP ID (+ mobile-variant ID)
> > > > >
> > > > >
> > > > > Yes, the IDs are needed.... in order to tell the "registration
> server": Hey, this installation for XYZ wants to receive messages.....
> > > > >
> > > > >
> > > > > So, the iOS (client SDK) code could look like:
> > > > >
> > > > > - (void)application:(UIApplication *)application
> didRegisterForRemoteNotificationsWithDeviceToken:(NSData *)deviceToken {
> NSURL *serverURL = [NSURL URLWithString:@"
> http://pusher.server.com/registry/device/"]; PushClient *pclient =
> [PushClient appID:@"1234" mobileID:@"456454"]; [pclient
> registerDeviceToken:deviceToken withServer:serverURL success:^(id
> responseObject) { NSLog(@"Registration Success: %@", responseObject); }
> failure:^(NSError *error) { NSLog(@"Registration Error: %@", error); }]; }
> > > > >
> > > > >
> > > > > The code above would be used by some customer/user, when they
> register their app with their running version, of our Unified Push
> server..... Not sure.... are we concerned about the keys are compiled into
> the actual app, that everybody could download from the app store ?
> > > >
> > > >
> > > >
> > > > Others do similar, requiring some sort of "API KEY" (similar to our
> appID/MobileID pair) being submitted when registering a specific
> device/installation.
> > > >
> > > > That said, without these IDs/Keys.... you can't register an app...
> > >
> > >
> > > perhaps this app/mobile app thing can be used + a "private key" (e.g.
> for the admin/developer....) and internally we issue some OAuth req., for
> the registration?
> > >
> > >
> > > I guess.... we should do/recommend some sort of encryption here....
> since these keys are compiled into the app.......
> > >
> > > hrm...
> > >
> > > >
> > > > NOTE: the appID/mobileID keys are generated by our server, when an
> admin/developer creates the logical construct of an app, on the server...
> > > >
> > > >
> > > >
> > > > >
> > > > > We really can't issue a login in the above case, since there may
> be no user..... and even if the paid app, requires a user..... someone can
> still first buy the app, and after installation decide to register a new
> user, from the app...... so the above code is still executed BEFORE the
> user decides to active/register his account...
> > > > >
> > > > >
> > > > > Matthias
> > > > >
> > > > >
> > > > > --
> > > > > Matthias Wessendorf
> > > > >
> > > > > blog: http://matthiaswessendorf.wordpress.com/
> > > > > sessions: http://www.slideshare.net/mwessendorf
> > > > > twitter: http://twitter.com/mwessendorf
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Matthias Wessendorf
> > > >
> > > > blog: http://matthiaswessendorf.wordpress.com/
> > > > sessions: http://www.slideshare.net/mwessendorf
> > > > twitter: http://twitter.com/mwessendorf
> > >
> > >
> > >
> > >
> > >
> > > --
> > > Matthias Wessendorf
> > >
> > > blog: http://matthiaswessendorf.wordpress.com/
> > > sessions: http://www.slideshare.net/mwessendorf
> > > twitter: http://twitter.com/mwessendorf
> > > _______________________________________________
> > > aerogear-dev mailing list
> > > aerogear-dev at lists.jboss.org (mailto:aerogear-dev at lists.jboss.org)
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>

-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130409/ab075979/attachment-0001.html 