[aerogear-dev] Push: Security / role model

[Matthias Wessendorf]

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 ?

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