<div dir="ltr"><div style>BTW...</div><div style><br></div><div style><br></div><div style>Have in mind, that regarding the "<em style="font-family:Helvetica,arial,freesans,clean,sans-serif;font-size:14px;line-height:20px;margin-top:0px">Mobile Variant Instances</em>" thing, some new comments were made in this thread:</div>
<div style><a href="http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Security-for-quot-Device-Registration-quot-td2505.html">http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Security-for-quot-Device-Registration-quot-td2505.html</a><br>
</div><div style><br></div><div style><br></div><div style>-Matthias</div><div style><br></div><div style><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, May 8, 2013 at 5:30 PM, Matthias Wessendorf <span dir="ltr"><<a href="mailto:matzew@apache.org" target="_blank">matzew@apache.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><p style="line-height:20px;margin-right:0px;font-size:13.63636302947998px;margin-left:0px;margin-bottom:15px;font-family:Helvetica,arial,freesans,clean,sans-serif;margin-top:0px!important">
Hi,</p>
<p style="line-height:20px;font-size:13.63636302947998px;font-family:Helvetica,arial,freesans,clean,sans-serif;margin:15px 0px">Bruno, Kris and I met, to talk a bit about the <em>security</em> related items here.</p>
<h3 style="font-size:18px;font-family:Helvetica,arial,freesans,clean,sans-serif;margin:20px 0px 10px;padding:0px"><a name="13e84c3796037139_oauth2" href="https://gist.github.com/matzew/cd8c8de1e2f00b837bb5#oauth2" style="color:rgb(65,131,196);text-decoration:none;display:block;padding-left:30px" target="_blank"></a>OAuth2</h3>
<p style="line-height:20px;font-size:13.63636302947998px;font-family:Helvetica,arial,freesans,clean,sans-serif;margin:0px 0px 15px">Using OAuth2 for (initial) authentication of the following items:</p><ul style="line-height:20px;font-size:13.63636302947998px;font-family:Helvetica,arial,freesans,clean,sans-serif;margin:15px 0px;padding:0px 0px 0px 30px">
<li><em style="margin-top:0px">Mobile Variant Instances:</em> The installation on a device (<code style="font-size:12px;line-height:normal;font-family:Consolas,'Liberation Mono',Courier,monospace;margin:0px 2px;padding:0px 5px;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;white-space:nowrap">Mobile Variant Instances</code>) needs to authenticate itself in order to register its data (e.g. <code style="font-size:12px;line-height:normal;font-family:Consolas,'Liberation Mono',Courier,monospace;margin:0px 2px;padding:0px 5px;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;white-space:nowrap">deviceToken</code>, <code style="font-size:12px;line-height:normal;font-family:Consolas,'Liberation Mono',Courier,monospace;margin:0px 2px;padding:0px 5px;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;white-space:nowrap">alias</code> etc, as discussed in the spec)</li>
<li><em style="margin-top:0px">Applications:</em> Backend applications that are using the <em>HTTP endpoints</em> to submit "Push Message requests" (e.g.<code style="font-size:12px;line-height:normal;font-family:Consolas,'Liberation Mono',Courier,monospace;margin:0px 2px;padding:0px 5px;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;white-space:nowrap">send XZY to all mobile-variant-instances of PushApplication X</code>)</li>
<li><em style="margin-top:0px">Developers:</em> OAuth2 is not enought. See below...</li></ul><h4 style="font-size:16px;font-family:Helvetica,arial,freesans,clean,sans-serif;margin:20px 0px 10px;padding:0px">
<a name="13e84c3796037139_mobile-variant-instances-based-on-android--ios" href="https://gist.github.com/matzew/cd8c8de1e2f00b837bb5#mobile-variant-instances-based-on-android--ios" style="color:rgb(65,131,196);text-decoration:none;display:block;padding-left:30px" target="_blank"></a>Mobile Variant Instances based on Android / iOS</h4>
<p style="line-height:20px;font-size:13.63636302947998px;font-family:Helvetica,arial,freesans,clean,sans-serif;margin:0px 0px 15px">There are OAuth2 clients, that will be reused. e.g. <em>AFNetworking</em> has support for it...</p>
<h4 style="font-size:16px;font-family:Helvetica,arial,freesans,clean,sans-serif;margin:20px 0px 10px;padding:0px"><a name="13e84c3796037139_java-application" href="https://gist.github.com/matzew/cd8c8de1e2f00b837bb5#java-application" style="color:rgb(65,131,196);text-decoration:none;display:block;padding-left:30px" target="_blank"></a>(Java) Application</h4>
<p style="line-height:20px;font-size:13.63636302947998px;font-family:Helvetica,arial,freesans,clean,sans-serif;margin:0px 0px 15px">Our Java lib will also use one of the existing client libs (e.g. Apache Oltu) to authenticate itself against the <em>AeroGear Unified Push Server</em>.</p>
<h4 style="font-size:16px;font-family:Helvetica,arial,freesans,clean,sans-serif;margin:20px 0px 10px;padding:0px"><a name="13e84c3796037139_javascript" href="https://gist.github.com/matzew/cd8c8de1e2f00b837bb5#javascript" style="color:rgb(65,131,196);text-decoration:none;display:block;padding-left:30px" target="_blank"></a>JavaScript</h4>
<p style="line-height:20px;font-size:13.63636302947998px;font-family:Helvetica,arial,freesans,clean,sans-serif;margin:0px 0px 15px">We will create something minimal for now, instead of making this part of <code style="font-size:12px;line-height:normal;font-family:Consolas,'Liberation Mono',Courier,monospace;margin:0px 2px;padding:0px 5px;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;white-space:nowrap">AeroGear.Auth</code>.</p>
<h3 style="font-size:18px;font-family:Helvetica,arial,freesans,clean,sans-serif;margin:20px 0px 10px;padding:0px"><a name="13e84c3796037139_security-framework" href="https://gist.github.com/matzew/cd8c8de1e2f00b837bb5#security-framework" style="color:rgb(65,131,196);text-decoration:none;display:block;padding-left:30px" target="_blank"></a>Security Framework</h3>
<p style="line-height:20px;font-size:13.63636302947998px;font-family:Helvetica,arial,freesans,clean,sans-serif;margin:0px 0px 15px">For <code style="font-size:12px;line-height:normal;font-family:Consolas,'Liberation Mono',Courier,monospace;margin:0px 2px;padding:0px 5px;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;white-space:nowrap">Developers</code> (with different roles/groups etc) simply OAuth is not enough. We need a <em>Security Framework</em> for the<strong>right management</strong>, e.g. to authorize that Developer X is really allowed to do step y.</p>
<p style="line-height:20px;font-size:13.63636302947998px;font-family:Helvetica,arial,freesans,clean,sans-serif;margin:15px 0px">The <em>AeroGear Unified Push Server</em> must be decoupled from any concrete "Security Provider", so that it is plugable and not tied to <em>one</em> "Security Framework". A common interface could be provided by <code style="font-size:12px;line-height:normal;font-family:Consolas,'Liberation Mono',Courier,monospace;margin:0px 2px;padding:0px 5px;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;white-space:nowrap">AeroGear-Security</code>. The <em>AeroGear Unified Push Server</em> is now only tied to this flexible dependency. Different plugable implementations would/cloud be provided by <code style="font-size:12px;line-height:normal;font-family:Consolas,'Liberation Mono',Courier,monospace;margin:0px 2px;padding:0px 5px;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;white-space:nowrap">AeroGear-Security</code>.</p>
<h4 style="font-size:16px;font-family:Helvetica,arial,freesans,clean,sans-serif;margin:20px 0px 10px;padding:0px"><a name="13e84c3796037139_management-of-developers-and-push-applications" href="https://gist.github.com/matzew/cd8c8de1e2f00b837bb5#management-of-developers-and-push-applications" style="color:rgb(65,131,196);text-decoration:none;display:block;padding-left:30px" target="_blank"></a>Management of <em>Developers</em> and Push Applications</h4>
<p style="line-height:20px;font-size:13.63636302947998px;font-family:Helvetica,arial,freesans,clean,sans-serif;margin:0px 0px 15px">The Secuirty Framework abstration (e.g. via <code style="font-size:12px;line-height:normal;font-family:Consolas,'Liberation Mono',Courier,monospace;margin:0px 2px;padding:0px 5px;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;white-space:nowrap">AG-Security</code>), would model the concept of a <code style="font-size:12px;line-height:normal;font-family:Consolas,'Liberation Mono',Courier,monospace;margin:0px 2px;padding:0px 5px;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;white-space:nowrap">Developer</code> (and its groups/roles etc).</p>
<p style="line-height:20px;font-size:13.63636302947998px;font-family:Helvetica,arial,freesans,clean,sans-serif;margin:15px 0px">The actual model of the <em>AeroGear Unified Push Server</em> (e.g.<code style="font-size:12px;line-height:normal;font-family:Consolas,'Liberation Mono',Courier,monospace;margin:0px 2px;padding:0px 5px;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;white-space:nowrap">Push Applications</code><code style="font-size:12px;line-height:normal;font-family:Consolas,'Liberation Mono',Courier,monospace;margin:0px 2px;padding:0px 5px;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;white-space:nowrap">,</code><code style="font-size:12px;line-height:normal;font-family:Consolas,'Liberation Mono',Courier,monospace;margin:0px 2px;padding:0px 5px;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;white-space:nowrap">Mobile Variants</code><code style="font-size:12px;line-height:normal;font-family:Consolas,'Liberation Mono',Courier,monospace;margin:0px 2px;padding:0px 5px;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;white-space:nowrap">and</code><code style="font-size:12px;line-height:normal;font-family:Consolas,'Liberation Mono',Courier,monospace;margin:0px 2px;padding:0px 5px;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;white-space:nowrap">Mobile Variant Instances</code>`) would be independent from that "security layer".</p>
<p style="line-height:20px;font-size:13.63636302947998px;font-family:Helvetica,arial,freesans,clean,sans-serif;margin:15px 0px">However, since a <code style="font-size:12px;line-height:normal;font-family:Consolas,'Liberation Mono',Courier,monospace;margin:0px 2px;padding:0px 5px;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;white-space:nowrap">Developer</code> creates the model objects (e.g. a <code style="font-size:12px;line-height:normal;font-family:Consolas,'Liberation Mono',Courier,monospace;margin:0px 2px;padding:0px 5px;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;white-space:nowrap">Mobile Variant</code> for a <code style="font-size:12px;line-height:normal;font-family:Consolas,'Liberation Mono',Courier,monospace;margin:0px 2px;padding:0px 5px;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;white-space:nowrap">Push Application</code>), there is a relationship between them. To some degree (and also inspired by Picketlink), these are (logical) extensions of a<code style="font-size:12px;line-height:normal;font-family:Consolas,'Liberation Mono',Courier,monospace;margin:0px 2px;padding:0px 5px;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;white-space:nowrap">Developer</code>. They <em>belong</em> to a <code style="font-size:12px;line-height:normal;font-family:Consolas,'Liberation Mono',Courier,monospace;margin:0px 2px;padding:0px 5px;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;white-space:nowrap">Developer</code>.</p>
<p style="line-height:20px;font-size:13.63636302947998px;font-family:Helvetica,arial,freesans,clean,sans-serif;margin:15px 0px"><strong>TL;DR:</strong> The "model objects" would be stored as "properties" / "attributes" of such a "Developer", abstracted by the (future) offerings of the <code style="font-size:12px;line-height:normal;font-family:Consolas,'Liberation Mono',Courier,monospace;margin:0px 2px;padding:0px 5px;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;white-space:nowrap">AeroGear-Sec</code> layer, instead of using a <em>concrete</em> "user class" of one, specific Security Framework</p>
<h3 style="font-size:18px;font-family:Helvetica,arial,freesans,clean,sans-serif;margin:20px 0px 10px;padding:0px"><a name="13e84c3796037139_authentication-of-mobile-variant-instance" href="https://gist.github.com/matzew/cd8c8de1e2f00b837bb5#authentication-of-mobile-variant-instance" style="color:rgb(65,131,196);text-decoration:none;display:block;padding-left:30px" target="_blank"></a>Authentication of Mobile Variant Instance</h3>
<p style="line-height:20px;font-size:13.63636302947998px;font-family:Helvetica,arial,freesans,clean,sans-serif;margin:0px 0px 15px">For the first iteration, we are going to use OAuth here. <strong>However</strong>, that may have a problem: When a<code style="font-size:12px;line-height:normal;font-family:Consolas,'Liberation Mono',Courier,monospace;margin:0px 2px;padding:0px 5px;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;white-space:nowrap">Mobile Variant Instance</code> is performing authentication againt the server, some Credentials (e.g. "kris:IloveJavaScript") are being used. For <strong>ALL</strong> the installed applications (e.g. via Play / Apple App-Store), or in EACH browser (<code style="font-size:12px;line-height:normal;font-family:Consolas,'Liberation Mono',Courier,monospace;margin:0px 2px;padding:0px 5px;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;white-space:nowrap">SimplePush</code>)!!</p>
<p style="line-height:20px;font-size:13.63636302947998px;font-family:Helvetica,arial,freesans,clean,sans-serif;margin:15px 0px">That means the <code style="font-size:12px;line-height:normal;font-family:Consolas,'Liberation Mono',Courier,monospace;margin:0px 2px;padding:0px 5px;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;white-space:nowrap">kris:IloveJavaScript</code> couple will be used by 1.000.000 phones. And opens room for <em>reverse engineering interests</em>.</p>
<p style="line-height:20px;font-size:13.63636302947998px;font-family:Helvetica,arial,freesans,clean,sans-serif;margin:15px 0px"><strong>Future:</strong> 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 <code style="font-size:12px;line-height:normal;font-family:Consolas,'Liberation Mono',Courier,monospace;margin:0px 2px;padding:0px 5px;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;white-space:nowrap">Mobile-Variant-ID</code> to the <em>AeroGear Unified Push Server</em>....</p>
<p style="line-height:20px;font-size:13.63636302947998px;font-family:Helvetica,arial,freesans,clean,sans-serif;margin:15px 0px"><em>But for now, we start with OAuth...</em></p><h4 style="font-size:16px;font-family:Helvetica,arial,freesans,clean,sans-serif;margin:20px 0px 10px;padding:0px">
<a name="13e84c3796037139_javascriptsimplepush" href="https://gist.github.com/matzew/cd8c8de1e2f00b837bb5#javascriptsimplepush" style="color:rgb(65,131,196);text-decoration:none;display:block;padding-left:30px" target="_blank"></a>JavaScript/SimplePush</h4>
<p style="line-height:20px;font-size:13.63636302947998px;font-family:Helvetica,arial,freesans,clean,sans-serif;margin:0px 0px 15px"><code style="font-size:12px;line-height:normal;font-family:Consolas,'Liberation Mono',Courier,monospace;margin:0px 2px;padding:0px 5px;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;white-space:nowrap">User Agent ID</code> and <code style="font-size:12px;line-height:normal;font-family:Consolas,'Liberation Mono',Courier,monospace;margin:0px 2px;padding:0px 5px;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;white-space:nowrap">Channel IDs</code> being stored in <code style="font-size:12px;line-height:normal;font-family:Consolas,'Liberation Mono',Courier,monospace;margin:0px 2px;padding:0px 5px;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;white-space:nowrap">localStorage</code>...</p>
<p style="line-height:20px;font-size:13.63636302947998px;font-family:Helvetica,arial,freesans,clean,sans-serif;margin:15px 0px">We <em>could</em> 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!</p>
<p style="line-height:20px;font-size:13.63636302947998px;font-family:Helvetica,arial,freesans,clean,sans-serif;margin:15px 0px">Thoughts? If not, content will be baked into the "spec"...</p><p style="line-height:20px;font-size:13.63636302947998px;font-family:Helvetica,arial,freesans,clean,sans-serif;margin:15px 0px">
With ♥</p><p style="line-height:20px;margin-right:0px;font-size:13.63636302947998px;margin-left:0px;margin-bottom:0px!important;font-family:Helvetica,arial,freesans,clean,sans-serif;margin-top:15px">Greetings<br>
<span style="font-size:13.63636302947998px">Bruno, Kris and Matthias</span></p><p style="line-height:20px;margin-right:0px;font-size:13.63636302947998px;margin-left:0px;margin-bottom:0px!important;font-family:Helvetica,arial,freesans,clean,sans-serif;margin-top:15px">
<br></p><p style="line-height:20px;margin-right:0px;font-size:13.63636302947998px;margin-left:0px;margin-bottom:0px!important;font-family:Helvetica,arial,freesans,clean,sans-serif;margin-top:15px"><br></p>
<p style="line-height:20px;margin-right:0px;font-size:13.63636302947998px;margin-left:0px;margin-bottom:0px!important;font-family:Helvetica,arial,freesans,clean,sans-serif;margin-top:15px"><br></p><p style="line-height:20px;margin-right:0px;font-size:13.63636302947998px;margin-left:0px;margin-bottom:0px!important;font-family:Helvetica,arial,freesans,clean,sans-serif;margin-top:15px">
<br></p><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, May 8, 2013 at 6:54 AM, Matthias Wessendorf <span dir="ltr"><<a href="mailto:matzew@apache.org" target="_blank">matzew@apache.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">
<div>On Wed, May 8, 2013 at 5:24 AM, Deepali Khushraj <span dir="ltr"><<a href="mailto:dkhushra@redhat.com" target="_blank">dkhushra@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word">Matthias,<div><br></div>
<div>A couple of comments:</div><div><br></div><div>* You mention disable notifications feature for "mobile variant instances". I was wondering if you considered the same for "mobile variants" and "push applications"? Could help admins disable misbehaving apps, and developers manage older app versions.</div>
</div></blockquote><div><br></div></div><div>yeah, removing(or perhaps disabling) mobile variants, or even the lager "push application" concept would be possible.</div><div>I think I mentioned the "instances" to make clear I can easily remove a guy, which has been fired (but he didn't return the company phone).</div>
<div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div>
<div>* API access: during "app registration", developer login seems like a good idea.</div></div></blockquote><div><br></div></div><div>Otherwise everyone could register new apps :)</div><div><div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word"><div> I am not so sure about "sending" messages though, as this will likely be initiated by a server-side component with no developer in the loop. <br></div></div></blockquote>
<div>
<br></div></div><div>I feel that we should protect our "sending http endpoint". That does not necessarily mean a user:password combination.</div><div><br></div><div>The "Send" is triggered by a server-side component (e.g. some backend app, written in some language/framework). <br>
</div><div>We should make sure that only "valid" server-side components can send messages to a PushApplication/MobileVariant(s).</div><div><br></div><div>Not covered in the spec (but the UI Mockups indicate it already)</div>
<div>When these PushApplication/MobileVariant(s) are registered we will have a button to generate "access keys".</div><div><br></div><div><pre style="background-color:rgb(248,248,248);border-top-left-radius:3px;padding:6px 10px;line-height:19px;border-top-right-radius:3px;font-size:13px;overflow:auto;border-bottom-right-radius:3px;font-family:Consolas,'Liberation Mono',Courier,monospace;word-wrap:break-word;border:1px solid rgb(204,204,204);border-bottom-left-radius:3px;margin-bottom:0px!important;margin-top:0px!important">
<code style="font-size:12px;line-height:normal;font-family:Consolas,'Liberation Mono',Courier,monospace;margin:0px;padding:0px;border:none;background-color:transparent;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px">curl -v -H "Accept: application/json" -H "Content-type: application/json"
-H "ag-pa-access-key: 329804327981237984317927098247980432179843217813267834687213842"
-X POST
-d '{message: {"key":"blah", "alert":"HELLO!"}}'
<a href="http://SERVER/sender/broadcast/PushApplicationID" target="_blank">http://SERVER/sender/broadcast/PushApplicationID</a> </code></pre></div><div><br></div><div>Not sure if that is really enough, but here the "server side comp." needs to know the ID of the logical "Push Application" constract, plus it "push-app-access-key";</div>
<div><br></div><div>So... if someone knows these two, he could start spamming the users, hence I feel that on-top of these keys we may want to have the server-side-component somehow perform some sort of auth against our HTTP-SEND endpoint </div>
<div>
<div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word">
<div><div><br>
</div><div>Thanks for the spec! The clear definitions made it very easy to read. </div></div></div></blockquote><div><br></div></div><div>Thanks!</div><div><div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><span><font color="#888888"><div><br></div><div>D.</div></font></span><div><div><div><br></div>
<br><div><div>On May 6, 2013, at 3:33 AM, Matthias Wessendorf <<a href="mailto:matzew@apache.org" target="_blank">matzew@apache.org</a>> wrote:</div><br><blockquote type="cite"><div dir="ltr">Moved the current draft to the homepage, see <a href="https://github.com/aerogear/aerogear.org/pull/57" target="_blank">https://github.com/aerogear/aerogear.org/pull/57</a><div>
<br></div><div>-M</div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Tue, Apr 30, 2013 at 1:57 PM, Bruno Oliveira <span dir="ltr"><<a href="mailto:bruno@abstractj.org" target="_blank">bruno@abstractj.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Really helpful Matthias. Thanks!<br>
<br>
<br>
--<br>
"The measure of a man is what he does with power" - Plato<br>
-<br>
@abstractj<br>
-<br>
Volenti Nihil Difficile<br>
<div><br>
<br>
<br>
On Tuesday, April 30, 2013 at 8:54 AM, Matthias Wessendorf wrote:<br>
<br>
> On IRC, Bruno raised a valid concern: The earlier version had "use cases"<br>
><br>
><br>
> I updated the GIST (<a href="https://gist.github.com/matzew/b918eb45d3f17de09b8f" target="_blank">https://gist.github.com/matzew/b918eb45d3f17de09b8f</a>) and added:<br>
> * more definitions<br>
> * usage scenarios<br>
> * use cases<br>
><br>
><br>
> -Matthias<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
</div><div>> On Mon, Apr 29, 2013 at 3:27 PM, Matthias Wessendorf <<a href="mailto:matzew@apache.org" target="_blank">matzew@apache.org</a> (mailto:<a href="mailto:matzew@apache.org" target="_blank">matzew@apache.org</a>)> wrote:<br>
> > Hi,<br>
> ><br>
> > I started a GIST to convert the different gists and readme's into a server-side spec<br>
> > (<a href="https://gist.github.com/matzew/b918eb45d3f17de09b8f" target="_blank">https://gist.github.com/matzew/b918eb45d3f17de09b8f</a>)<br>
> ><br>
> ><br>
> > * Regarding the "mobile variant instance":<br>
> > We need to decide, what a SimplePush client may need on-top of the data, described below (and in the gist). (since they have clientIDs + channels)<br>
> ><br>
> > * Similar... we need to reflect the "" on a "selected" (and broadcast) send as well.<br>
> ><br>
> > * Sec: there is a different meeting, on the sec - content will be integrated (or linked from this spec)<br>
> ><br>
> ><br>
> > If this doc, looks good, I will submit it as a PR so that we get it on the homepage<br>
> ><br>
> ><br>
> > Next:<br>
> > CLIENT SPEC is coming later today (or tomorrow)<br>
> ><br>
> > Thoughts ?<br>
> > Matthias<br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> > AeroGear Unified Push Server (Draft 0.0.3)<br>
> ><br>
</div>> > The AeroGear Unified Push Server is a server that allows sending native push messages to different mobile operation systems. The initial version of the server supports Apple's APNs (<a href="http://developer.apple.com/library/mac/#documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/ApplePushService.html%23//apple_ref/doc/uid/TP40008194-CH100-SW9" target="_blank">http://developer.apple.com/library/mac/#documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/ApplePushService.html%23//apple_ref/doc/uid/TP40008194-CH100-SW9</a>), Google Cloud Messaging (<a href="http://developer.android.com/google/gcm/index.html" target="_blank">http://developer.android.com/google/gcm/index.html</a>) and Mozilla's Simple Push (<a href="https://wiki.mozilla.org/WebAPI/SimplePush" target="_blank">https://wiki.mozilla.org/WebAPI/SimplePush</a>).<br>
<div>> ><br>
> > Motivation / Purpose<br>
> ><br>
> > Goal: Any (JBoss/AeroGear powered) mobile application, that is backed by JBoss technology (e.g. admin console, Errai, drools, etc.), is able to easily work with mobile push messages. For a JBoss "backend application" it should be as simple as possible, to send messages to its different mobile clients.<br>
> ><br>
> > Definitions<br>
> ><br>
> > Before we get into details, it's important that we have a good lexicon.<br>
> ><br>
> > Push Application<br>
> ><br>
> > A logical construct that represents an overall mobile application (e.g. Mobile HR).<br>
> ><br>
> > Mobile Variant<br>
> ><br>
> > A mobile variant of the Push Application. There can be multiple variants for a Push Application (e.g. HR Android,HR iPad, HR iPhone free, HR iPhone premium or HR Mobile Web).<br>
> ><br>
> > Mobile Variant Instance<br>
> ><br>
> > Represents an actual installation on a mobile device (e.g. User1 connected via MobileWeb or User2 runs HR iPhone premium on his phone)<br>
> ><br>
> > Overview<br>
> ><br>
> > The AeroGear Unified Push Server contains three different components:<br>
> ><br>
> > Registration: Registry for Push Applications, Mobile Variants and Mobile Variant Instances<br>
> > Storage: A database, storing the registered applications and instances<br>
> > Sender: Receives messages and sends them to different Mobile Variant Instances<br>
> ><br>
> ><br>
> > The graphic below gives a little overview:<br>
> ><br>
</div><div>> > Functionality<br>
> > Registration<br>
> ><br>
> > Three different registration types are provided by the AeroGear Unified Push Server.<br>
> ><br>
> > Push Application Registration<br>
> ><br>
> > Adds a logical construct, that represents an overall mobile application (e.g. Mobile HR). The Push Application contains the following properties:<br>
> ><br>
> > Name<br>
> > Description<br>
> > A collection of Mobile Variants<br>
> ><br>
> ><br>
> > The server offers an HTTP interfaces to apply a Push Application registration:<br>
> ><br>
> > curl -v -H "Accept: application/json" -H "Content-type: application/json" -X POST -d '{"name" : "MyApp", "description" : "awesome app" }' <a href="http://server/applications" target="_blank">http://SERVER/applications</a><br>
> ><br>
> > The response returns an ID for the Push Application.<br>
> ><br>
> > Mobile Variant Registration<br>
> ><br>
> > Adds a mobile variant for an existing Push Application. There can be multiple variants for a Push Application (e.g. HR Android, HR iPad, HR iPhone free, HR iPhone premium or HR Mobile Web).<br>
> ><br>
> ><br>
> > The server supports the following variant types:<br>
> ><br>
> > iOS<br>
> > Android<br>
> > SimplePush<br>
> ><br>
> > iOS Variant<br>
> ><br>
> > An iOS variant represents a logical construct for one iOS application (e.g. HR for iPhone or HR for iPad ). The iOS variant requires some APNs specific values:<br>
> ><br>
> > APNs Push Certificate file<br>
> > Passphrase<br>
> ><br>
> ><br>
> > The server offers an HTTP interfaces to register an iOS varian:<br>
> ><br>
</div>> > curl -i -H "Accept: application/json" -H "Content-type: multipart/form-data" -F "certificate=@/Users/matzew/Desktop/MyCert.p12" -F "passphrase=TopSecret" -X POST <a href="http://server/applications/%7BPUSH_ID%7D/iOS" target="_blank">http://SERVER/applications/{PUSH_ID}/iOS</a> (<a href="http://server/applications/%7BPUSH_ID%7D/iOS" target="_blank">http://SERVER/applications/%7BPUSH_ID%7D/iOS</a>)<br>
<div>> ><br>
> > NOTE: The above is a multipart/form-data, since it is required to upload the "Apple Push certificate"!<br>
> ><br>
> ><br>
> > The response returns an ID for the iOS variant.<br>
> ><br>
> > Android Variant<br>
> ><br>
> > An Android variant represents a logical construct for one Android application (e.g. HR for Android). The Android variant requires some Google specific values:<br>
> ><br>
> > Google API Key<br>
> ><br>
> ><br>
> > The server offers an HTTP interfaces to register an Android variant:<br>
> ><br>
</div>> > curl -v -H "Accept: application/json" -H "Content-type: application/json" -X POST -d '{"googleKey" : "IDDASDASDSA"}' <a href="http://server/applications/%7BPUSH_ID%7D/android" target="_blank">http://SERVER/applications/{PUSH_ID}/android</a> (<a href="http://server/applications/%7BPUSH_ID%7D/android" target="_blank">http://SERVER/applications/%7BPUSH_ID%7D/android</a>)<br>
<div>> ><br>
> > _The response returns an ID for the Android variant.<br>
> ><br>
> > SimplePush Variant<br>
> ><br>
> > An SimplePush variant represents a logical construct for one SimplePush application (e.g. HR mobile Web). The SimplePush variant requires some Simple Push Network specific values:<br>
> ><br>
> > URL of the PushNetwork server<br>
> ><br>
> ><br>
> > The server offers an HTTP interfaces to register an SimplePush variant:<br>
> ><br>
</div>> > curl -v -H "Accept: application/json" -H "Content-type: application/json" -X POST -d '{"pushNetworkURL" : "<a href="http://localhost:7777/endpoint/" target="_blank">http://localhost:7777/endpoint/</a>"}' <a href="http://server/applications/%7BPUSH_ID%7D/simplePush" target="_blank">http://SERVER/applications/{PUSH_ID}/simplePush</a> (<a href="http://server/applications/%7BPUSH_ID%7D/simplePush" target="_blank">http://SERVER/applications/%7BPUSH_ID%7D/simplePush</a>)<br>
<div>> ><br>
> > The response returns an ID for the SimplePush variant.<br>
> ><br>
> > Mobile Variant Instance Registration<br>
> ><br>
> > Adds an mobile variant instance to an existing mobile variant (e.g. User1 runs HR-iPad on his device). It is possible that one user can have multiple devices. A mobile variant instance contains the following properties:<br>
> ><br>
> > Required Data<br>
> > deviceToken<br>
> ><br>
> ><br>
> > The platform specific device token, that identifies the device with the used push network, in order to deliver messages<br>
> ><br>
> > operatingSystem<br>
> ><br>
> ><br>
> > It is required for the device to submit it's exact name of the underlying OS.<br>
> ><br>
> > osVersion<br>
> ><br>
> ><br>
> > It is required for the device to submit it's exact version of the underlying OS.<br>
> ><br>
> > Mobile Variation ID<br>
> ><br>
> ><br>
> > ID received when registering a Mobile Variant. This ID needs to be submitted as a request header (ag-mobile-variant). NOTE: It is possible that this ID goes away, in favor for a digital signature in a future release<br>
> ><br>
> > Optional Data<br>
> > deviceType<br>
> ><br>
> ><br>
> > It is recommended to store the (exact) device type (e.g. phone vs tablet).<br>
> ><br>
> > alias<br>
> ><br>
> ><br>
> > If the business application requires the conecpt of a user, the registration must submit an unique identifier (like a username), to identify the user. It is possible that one user has multiple devices.<br>
> ><br>
> > Business Data<br>
> ><br>
> > The above are technical information bits that are required to get a message to the device. This the app wants to send notification based on a criteria, the relevant data has to be stored in the business backend. This way the backend app is very flexible on the criterias (e.g. max salary, geolocation, number of children, etc). All this data is NOT directly related to the technical functionality of sending data. The usage of the AeroGear Pipe is highly recommended to store business data on the business backend.<br>
> ><br>
> ><br>
> > The server offers an HTTP interfaces to register an mobile variant instance:<br>
> ><br>
</div>> > curl -v -H "Accept: application/json" -H "Content-type: application/json" -H "ag-push-app: {id}" -H "ag-mobile-app: {id}" -X POST -d '{ "alias" : "<a href="mailto:user@company.com" target="_blank">user@company.com</a> (mailto:<a href="mailto:user@company.com" target="_blank">user@company.com</a>)", "deviceToken" : "someTokenString", "deviceType" : "ANDROID", "mobileOperatingSystem" : "android", "osVersion" : "4.0.1" }' <a href="http://server/registry/device" target="_blank">http://SERVER/registry/device</a><br>
<div>> ><br>
> > NOTE: Platform specific Client SDKs will be provided to submit the require data to the AeroGear Unified Push Server.<br>
> ><br>
> > Storage<br>
> ><br>
> > A (configurable) database that stores all registered applications and instances.<br>
> ><br>
> > Sender<br>
> ><br>
> > HTTP interface that receives messages for a delivery to different Mobile Push Networks. A few different Sender Types are supported by the push server.<br>
> ><br>
> > Global Broadcast Sender<br>
> ><br>
> > Sends a push message to all mobile variants (and all of its mobile variant intances), of a given Push Application:<br>
> ><br>
</div>> > curl -v -H "Accept: application/json" -H "Content-type: application/json" -X POST -d '{"key":"blah", "alert":"HELLO!"}' <a href="http://server/sender/broadcast/%7BPushApplicationID%7D" target="_blank">http://SERVER/sender/broadcast/{PushApplicationID}</a> (<a href="http://server/sender/broadcast/%7BPushApplicationID%7D" target="_blank">http://SERVER/sender/broadcast/%7BPushApplicationID%7D</a>)<br>
<div>> ><br>
> > Sends a JSON map to the server. If platform specific key words (e.g. alert for APNs) are used, they are honored for the specific platform. This transformation is done by the AeroGear Unified Push Server.<br>
> ><br>
> > Variant specific Broadcast<br>
> ><br>
> > Sends a push message to only one mobile variants (and all of its mobile variant intances).:<br>
> ><br>
</div>> > curl -v -H "Accept: application/json" -H "Content-type: application/json" -X POST -d '{"key":"blah", "alert":"HELLO!"}' <a href="http://server/sender/broadcast/variant/%7BMobileVariantID%7D" target="_blank">http://SERVER/sender/broadcast/variant/{MobileVariantID}</a> (<a href="http://server/sender/broadcast/variant/%7BMobileVariantID%7D" target="_blank">http://SERVER/sender/broadcast/variant/%7BMobileVariantID%7D</a>)<br>
<div>> ><br>
> > Sends a JSON map to the server. If platform specific key words (e.g. alert for APNs) are used, they are honored for the specific platform. This transformation is done by the AeroGear Unified Push Server.<br>
> ><br>
> > Selected Sender<br>
> ><br>
> > Sends a push message to a selected list of identified users (regardless of their variant):<br>
> ><br>
</div>> > curl -v -H "Accept: application/json" -H "Content-type: application/json" -X POST -d '{ alias: ["<a href="mailto:user@foo.com" target="_blank">user@foo.com</a> (mailto:<a href="mailto:user@foo.com" target="_blank">user@foo.com</a>)", "<a href="mailto:bar@moz.org" target="_blank">bar@moz.org</a> (mailto:<a href="mailto:bar@moz.org" target="_blank">bar@moz.org</a>)", ....], message: {"key":"blah", "alert":"HELLO!"} }' <a href="http://server/sender/selected" target="_blank">http://SERVER/sender/selected</a><br>
<div>> ><br>
> > The alias value is used to identied the desired users. The payload (messages) is a standard JSON map. If platform specific key words (e.g. alert for APNs) are used, they are honored for the specific platform. This transformation is done by the AeroGear Unified Push Server.<br>
><br>
><br>
><br>
><br>
><br>
> --<br>
> Matthias Wessendorf<br>
><br>
> blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
> sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
> twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a><br>
</div>> _______________________________________________<br>
> aerogear-dev mailing list<br>
> <a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a> (mailto:<a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a>)<br>
> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
<br>
<br>
<br>
_______________________________________________<br>
aerogear-dev mailing list<br>
<a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>Matthias Wessendorf <br><br>blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a>
</div>
_______________________________________________<br>aerogear-dev mailing list<br><a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br><a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a></blockquote>
</div><br></div></div></div></div><br>_______________________________________________<br>
aerogear-dev mailing list<br>
<a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br></blockquote></div></div></div><div><div><br><br clear="all"><span class="HOEnZb"><font color="#888888"><div>
<br>
</div>-- <br>Matthias Wessendorf <br>
<br>blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a>
</font></span></div></div></div></div><span class="HOEnZb"><font color="#888888">
</font></span></blockquote></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br>Matthias Wessendorf <br><br>blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a>
</font></span></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>Matthias Wessendorf <br><br>blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a>
</div>