[aerogear-dev] Push: Security / role model

[Matthias Wessendorf]

On Tue, Apr 9, 2013 at 5:53 PM, Matthias Wessendorf <matzew at apache.org>wrote:

>
>
>
> 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...
>


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