[aerogear-dev] iOS Passphrases for UPS

[Matthias Wessendorf]

On Mon, Mar 10, 2014 at 11:38 PM, Bruno Oliveira <bruno at abstractj.org>wrote:

> Ahoy, answers inline.
>
> --
> abstractj
>
> On March 10, 2014 at 6:01:33 PM, Matthias Wessendorf (matzew at apache.org)
> wrote:
> > Ahoy!
> >
> >
> > On Mon, Mar 10, 2014 at 9:49 PM, Bruno Oliveira wrote:
> >
> > > Good morning guys, for this issue
> > > https://issues.jboss.org/browse/AGPUSH-358. I was revisiting the whole
> > > UPS code and thinking about include two fields for iOSVariant class:
> skey
> > > (secret key) and pKey (public key). What's the idea?
> > >
> > > 1. Each application has its own key pair
> > >
> >
> > each of the PushApplication constructs/objects on the UPS ?
>
> Yes if that makes sense to the others like Android variants. And no if we
> just want to use it with iOSVariant, into this case that would apply only
> for iOS applications.
>

Perfect!

It does make sense on the 'root' PushApplication. That way other variant
types can benefit from it as well. I think we can(should?) also encrypt the
Google API-Key value. And future variants (other networks) will benefit in
this case as well



>
> >
> >
> > > 2. Before the addition of the iOS variant, the client sends a request
> > > asking for the public keys
> > >
> >
> > "the client" ? Is that the AdminUI (or the relevant HTTP Rest code), when
> > someone clicks "Add new Variant" ?
>
> Whatever REST consumer we have or the service.
>
> >
> >
> >
> > > 3. The server sends an HTTP response with the public key for encryption
> > > 4. The client make use of the public key to encrypt the certificate +
> the
> > > passphrase
> > > 5. Server stores it encrypted
> > > 6. When necessary to send push messages, the server make use of the
> > > private key to decrypt that data and send fancy messages.
> > >
> >
> > Now, when a (JavaEE) application is sending a request for push messages
> to
> > the UPS (which than internally makes use of the private key to decrypt
> that
> > data and send fancy messages to Apple), the HTTP RestEndpoint requires a
> > new argument (the public key) to be allowed to submit these "requests" ?
>
> On the client side, after the public key retrieval you don't need to add
> new parameters. As Sebastien mentioned it would remain unchanged.
>

perfect!


>
> Currently:
>
> curl -3 -v -b cookies.txt -c cookies.txt
>   -i -H "Accept: application/json" -H "Content-type: multipart/form-data"
>   -F "certificate=@/Users/matzew/Desktop/MyProdCert.p12"
>   -F "passphrase=TopSecret"
>   -F "production=true"  // make sure you have Production certificate and
> Provisioning Profile
>
>   -X POST https://SERVER:PORT
> /CONTEXT/rest/applications/{pushApplicationID}/iOS
>
>
> Proposed:
>
>
> curl -3 -v -b cookies.txt -c cookies.txt
>   -i -H "Accept: application/json" -H "Content-type: multipart/form-data"
>   -F "certificate=@/Users/matzew/Desktop/encrypted-cert.blah"
>   -F "passphrase=schwarzenegger"
>   -F "production=true"  // make sure you have Production certificate and
> Provisioning Profile
>
>   -X POST https://SERVER:PORT
> /CONTEXT/rest/applications/{pushApplicationID}/iOS
>
> Where encrypted-cert.blah and "Schwarzenegger" are encrypted data.
>

Ok, so the encrypted data is being uploaded by the user of the UPS, right ?
and hence, no more a direct upload of the plain certificate and the plain
passphrase.
That means there is an extra step for the user, if I see it correct.

having an extra step for the API to create the (iOS) variant is fine, let's
make sure it's a somewhat simple step for our users, which hopefully than
does not need too much extra steps in the documentation :-)



> Makes sense?
>

Yes, I think :-)
 Thanks!

-Matthias


>
> >
> >
> > >
> > > Does it make sense to you?
> > >
> >
> > Somewhat - not sure I fully understood :)
> >
> >
> > >
> > > --
> > > abstractj
> > >
> > > JBoss, a division of Red Hat
> > >
> > >
> > >
> > > _______________________________________________
> > > aerogear-dev mailing list
> > > aerogear-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> >
> >
> >
> > --
> > Matthias Wessendorf
> >
> > blog: http://matthiaswessendorf.wordpress.com/
> > sessions: http://www.slideshare.net/mwessendorf
> > twitter: http://twitter.com/mwessendorf
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>


-- 
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/20140311/2869728e/attachment.html