Re: [aerogear-dev] Push: Security / role model

On Tue, Apr 9, 2013 at 4:47 PM, Matthias Wessendorf <matzew(a)apache.org&gt;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-re... > 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