[aerogear-dev] Passphrase protection proposal and UPS
Matthias Wessendorf
matzew at apache.org
Mon Feb 17 11:28:53 EST 2014
On Mon, Feb 17, 2014 at 4:37 PM, Bruno Oliveira <bruno at abstractj.org> wrote:
>
>
> --
> abstractj
>
> On February 17, 2014 at 12:21:45 PM, Matthias Wessendorf (
> matzew at apache.org) wrote:
> >
> > On Wed, Feb 12, 2014 at 3:15 PM, Bruno Oliveira
> > wrote:
> > > ### Some considerations
> > >
> > > - The key pair will be generated in a separated project, not on
> > UPS
> > > - For the key store I'm considering to support the same data stores
> > > provided by SPS. What Dan did is a nice a idea (
> > >
> https://github.com/aerogear/aerogear-simplepush-server/tree/master/datastores
> > > )
> > >
> >
> > You mean the new "key server" supports multiple databases, right
> > ?
>
> Basically the possibility to store those key pairs in whatever storage
> mechanism you want: memory, Redis...
>
> TBH not very critical atm.
>
yup
>
> > > ## Changes suggested on UPS server
> > >
> > > 1. Login endpoint
> > >
> > > - Current login endpoint:
> > >
> > > POST /rest/auth/login
> > >
> > > - Suggested change:
> > >
> > > I'm not sure if we really need **POST** for login, unless
> > > we are changing the state of some resource
> > >
> > > GET /rest/auth/login
> > >
> >
> >
> > Changing from POST to GET (for UPS login) is fine we me. The Login
> > is
> > really only relevant to the Admin UI.
> > Historically: I picked POST because that's what all of our client
> > libraries
> > use as the default HTTP method for login (JS, iOS and Android)
> >
>
> That's more a suggestion than a deal breaker.
>
yeah, I am pretty flexible here :-)
>
> > > 2. Register push app
> > >
> > > - Our push clients will need to change to accept the public key
> > > provided by the server and encrypt the passphrase. We can make
> > use of *AG
> > > Crypto* for it
> > > - The basic workflow for our clients would be:
> > >
> >
> >
> > What clients do you mean? The only thing that really does a login
> > against
> > the server is the Admin UI (or a direct curl, using the same 'management'
> > rest-endpoints which are accessed by the AdminUI).
> >
> >
>
> By clients I mean: cURL, aerogear-unifiedpush-java-client, node
> version...etc. If I got it right, you must provide the master secret.
Right! for sending these 'sender clients' need to know the (umbrella) push
applicationID and its masterSecret:
http://aerogear.org/docs/specs/aerogear-push-rest/Sender/
> The suggestion is not only protect our passphrases,
the passphrase is really something specific to iOS
> but also do not expose that masterSecret, because someone in possession of
> this could start to send push messages to the server. Am I wrong on it?
>
correct someone could to that. In the past we already at least chatted
about having some sort of key/certificate for that + access-keys (e.g. per
application).
-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/20140217/0eed5e50/attachment.html
More information about the aerogear-dev
mailing list