[aerogear-dev] Push: Security / role model

[Matthias Wessendorf]

On Tue, Apr 9, 2013 at 4:47 PM, Matthias Wessendorf <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!!!
> <https://gist.github.com/matzew/e335881b3f95b1448774#deviceinstallation-registration>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 *)applicationdidRegisterForRemoteNotificationsWithDeviceToken:(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...

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130409/8269cfc5/attachment-0001.html