Hi,
Bruno, Kris and I met, to talk a bit about the security related items here.
Using OAuth2 for (initial) authentication of the following items:
- Mobile Variant Instances: The installation on a device (
Mobile Variant Instances) needs to authenticate itself in order to register its data (e.g.deviceToken,aliasetc, as discussed in the spec) - Applications: Backend applications that are using the HTTP endpoints to submit "Push Message requests" (e.g.
send XZY to all mobile-variant-instances of PushApplication X) - Developers: OAuth2 is not enought. See below...
There are OAuth2 clients, that will be reused. e.g. AFNetworking has support for it...
Our Java lib will also use one of the existing client libs (e.g. Apache Oltu) to authenticate itself against the AeroGear Unified Push Server.
We will create something minimal for now, instead of making this part of AeroGear.Auth.
For Developers (with different roles/groups etc) simply OAuth is not enough. We need a Security Framework for the right management, e.g. to authorize that Developer X is really allowed to do step y.
The AeroGear Unified Push Server must be decoupled from any concrete "Security Provider", so that it is plugable and not tied to one "Security Framework". A common interface could be provided by AeroGear-Security. The AeroGear Unified Push Server is now only tied to this flexible dependency. Different plugable implementations would/cloud be provided by AeroGear-Security.
The Secuirty Framework abstration (e.g. via AG-Security), would model the concept of a Developer (and its groups/roles etc).
The actual model of the AeroGear Unified Push Server (e.g. ``Push Applications, Mobile Variants``` and ```Mobile Variant Instances```) would be independent from that "security layer".
However, since a Developer creates the model objects (e.g. a Mobile Variant for a Push Application), there is a relationship between them. To some degree (and also inspired by Picketlink), these are (logical) extensions of a Developer. They belong to a Developer.
TL;DR: The "model objects" would be stored as "properties" / "attributes" of such a "Developer", abstracted by the (future) offerings of the AeroGear-Sec layer, instead of using a concrete "user class" of one, specific Security Framework
For the first iteration, we are going to use OAuth here. However, that may have a problem: When a Mobile Variant Instance is performing authentication againt the server, some Credentials (e.g. "kris:IloveJavaScript") are being used. For ALL the installed applications (e.g. via Play / Apple App-Store), or in EACH browser (SimplePush)!!
That means the kris:IloveJavaScript couple will be used by 1.000.000 phones. And opens room for reverse engineering interests.
Future: we will evaluate "Digital signatures" or on the fly (self signed) client SSL certifactes. This also will remove the requirement (see Spec) to send a Mobile-Variant-ID to the AeroGear Unified Push Server....
But for now, we start with OAuth...
User Agent ID and Channel IDs being stored in localStorage...
We could investigate JS encryption... but for now the plan is expire/renew those IDs after some amount of (specified?) time. Crypto.js will come at a later iteration!
With ♥
Greetings, Bruno, Kris and Matthias