Hi,<div><br></div><div>a few questions: </div><div>* for device registration will it be possible to perform the actual registration by using the variantID and its secret? (Please note that there is no "user" on the mobile device. Currently, for the registration, we perform http_basic authentification against a variant (via varianID /secret))</div>
<div><br></div><div><br></div><div>* isn't it possible to exclude a few URIs (e.g. security-constraint element(s) in web.xml) from Keycloak? That way 'sender' (and 'device registration') cloud stay as they are: using their custom http_basic impl</div>
<div><br></div><div><br></div><div>I am NOT against changes, but I am a bit worried that we add new and instable code for the sender/registration endpoints (and our mobile clients and our senders), just a few weeks before we will have our 1.0.0 release.</div>
<div><br></div><div>Or are my concerns are invalid and the Android, Cordova, iOS SDKs, as well as our senders (java and node), will work just fine, without major changes </div><div><br></div><div>Thanks,</div><div>Matthias<span></span></div>
<div><br>On Thursday, June 19, 2014, Stian Thorgersen <<a href="mailto:stian@redhat.com">stian@redhat.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Here's an idea on how it could be done (disclaimer: this is just a rough idea so take it with a pinch of salt ;)). Some benefits:<br>
<br>
* Relatively simple to maintain backwards compatibility<br>
* Support public clients directly (by using logged in users permissions)<br>
* One application can access multiple UPS Apps<br>
* No need to maintain master secret in UPS (and can support multiple methods to auth in the future, for example cert or jwt<br>
* Manage access through KC - what app/client or user can access what UPS App<br>
<br>
<br>
When creating a new UPS App create:<br>
<br>
* A role on unified-push-server - the name should be equal to id of UPS app<br>
<br>
Applications should have 3 options to authenticate:<br>
<br>
* As the logged in user (for client side applications)<br>
* As themselves (for server side applications)<br>
* HTTP Basic<br>
<br>
The master secret can also be removed from UPS App as it should no longer be required.<br>
<br>
As the logged in user<br>
---------------------<br>
This allows public applications to send push messages on behalf of the logged in user. The steps required are:<br>
<br>
1) Create an application/client in Keycloak<br>
* Set to public client<br>
* Add scope on UPS App role<br>
2) Create user<br>
* Add role mapping on UPS App role<br>
3) Users logs in with username/password, social, etc through KC login<br>
screens<br>
4) Application can send push messages with bearer token using users<br>
permissions<br>
<br>
As themselves<br>
-------------<br>
This allows a server-side application to send push messages on behalf of itself. The steps required are:<br>
<br>
1) Create an application/client in Keycloak<br>
* Add scope on UPS App role<br>
2) Create user<br>
* Add role mapping on UPS App role<br>
* Set a long unique password (equivalent of master secret)<br>
3) Application logs in with username/password (equal to UPS App<br>
id/master-secret) using direct grant<br>
4) Application can send push messages with bearer token using its own<br>
permissions<br>
<br>
In the future Keycloak will support additional mechanism for a server-side application to authenticate on behalf of itself (cert, jwts, etc).<br>
<br>
HTTP Basic<br>
----------<br>
For backwards compatibility we can add a valve that extracts the UPS App id and master secret from Basic auth. It will then use the direct grant mechanism to obtain a token from Keycloak. The steps required to configure is the same as "As themselves".<br>
<br>
<br>
<br>
----- Original Message -----<br>
> From: "Bruno Oliveira" <<a href="javascript:;" onclick="_e(event, 'cvml', 'bruno@abstractj.org')">bruno@abstractj.org</a>><br>
> To: "AeroGear Developer Mailing List" <<a href="javascript:;" onclick="_e(event, 'cvml', 'aerogear-dev@lists.jboss.org')">aerogear-dev@lists.jboss.org</a>><br>
> Sent: Wednesday, 18 June, 2014 8:12:55 PM<br>
> Subject: Re: [aerogear-dev] Keycloak integration and UPS Sender<br>
><br>
> Hi guys, let's see the result of the conversation with KC team and we<br>
> can revisit this discussion if some changed is required.<br>
><br>
> On 2014-06-18, Matthias Wessendorf wrote:<br>
> > On Wed, Jun 18, 2014 at 12:12 AM, Bruno Oliveira <<a href="javascript:;" onclick="_e(event, 'cvml', 'bruno@abstractj.org')">bruno@abstractj.org</a>><br>
> > wrote:<br>
> ><br>
> > > Answers inline.<br>
> > ><br>
> > > On 2014-06-17, Matthias Wessendorf wrote:<br>
> > > > On Tue, Jun 17, 2014 at 8:51 PM, Matthias Wessendorf<br>
> > > > <<a href="javascript:;" onclick="_e(event, 'cvml', 'matzew@apache.org')">matzew@apache.org</a>><br>
> > > > wrote:<br>
> > > ><br>
> > > > ><br>
> > > > ><br>
> > > > ><br>
> > > > > On Tue, Jun 17, 2014 at 7:17 PM, Bruno Oliveira <<a href="javascript:;" onclick="_e(event, 'cvml', 'bruno@abstractj.org')">bruno@abstractj.org</a>><br>
> > > > > wrote:<br>
> > > > ><br>
> > > > >> Hi Matthias, answer inline.<br>
> > > > >><br>
> > > > >> On 2014-06-17, Matthias Wessendorf wrote:<br>
> > > > >> > On Tue, Jun 17, 2014 at 4:26 PM, Bruno Oliveira <<br>
> > > <a href="javascript:;" onclick="_e(event, 'cvml', 'bruno@abstractj.org')">bruno@abstractj.org</a>><br>
> > > > >> wrote:<br>
> > > > >> ><br>
> > > > >> > > Good morning peeps,<br>
> > > > >> > ><br>
> > > > >> > > I have a problem to solve which might affect the Sender and<br>
> > > > >> > > all the related clients.<br>
> > > > >> > ><br>
> > > > >> > > Previously, the UPS Sender was protected by the basic<br>
> > > authentication<br>
> > > > >> > > method[1], so anyone in possession of _PushApplicationID_ and<br>
> > > > >> > > _MasterSecret_ is able to send push messages.<br>
> > > > >> > ><br>
> > > > >> > > After the integration with Keycloak now everything under _/rest_<br>
> > > > >> > > is properly protect by KC which is totally correct. Our sender<br>
> > > > >> > > is<br>
> > > > >> under<br>
> > > > >> > > the same umbrella which means that now Bearer token<br>
> > > authentication is<br>
> > > > >> > > required[2] and Basic authentication won't exist anymore.<br>
> > > > >> > ><br>
> > > > >> ><br>
> > > > >> ><br>
> > > > >> > The device (un)registration endpoints are hit by this as well<br>
> > > > >> > (/rest/registry/device/*).<br>
> > > > >><br>
> > > > >> Currently Keycloak is protecting our endpoints under /rest/*<br>
> > > > >><br>
> > > > >> ><br>
> > > > >> > I am wondering if it isn't it possible to keep those URLs<br>
> > > > >> > protected<br>
> > > via<br>
> > > > >> > HTTP_BASIC, or does the keycloak.js usage deny this?<br>
> > > > >><br>
> > > > >> Is not the Keycloak.js usage responsible for this, but the correct<br>
> > > > >> configuration of the application atm. Please compare:<br>
> > > > >><br>
> > > > >> - master branch:<br>
> > > > >><br>
> > > > >><br>
> > > <a href="https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/server/src/main/webapp/WEB-INF/web.xml#L56" target="_blank">https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/server/src/main/webapp/WEB-INF/web.xml#L56</a><br>
> > > > >> - keycloak.js branch:<br>
> > > > >><br>
> > > > >><br>
> > > <a href="https://github.com/aerogear/aerogear-unifiedpush-server/blob/keycloak.js/server/src/main/webapp/WEB-INF/web.xml#L33" target="_blank">https://github.com/aerogear/aerogear-unifiedpush-server/blob/keycloak.js/server/src/main/webapp/WEB-INF/web.xml#L33</a><br>
> > > > >><br>
> > > > >> Now we're fully using Keycloak bearer tokens instead of Basic.<br>
> > > > >><br>
> > > > ><br>
> > > > ><br>
> > > > > Oh, I was following Bill's sample project, where he did not use the<br>
> > > > > 'KEYCLOAK' auth-method:<br>
> > > > ><br>
> > > > ><br>
> > > <a href="https://github.com/keycloak/keycloak/blob/master/project-integrations/aerogear-ups/app/src/main/webapp/WEB-INF/web.xml#L44" target="_blank">https://github.com/keycloak/keycloak/blob/master/project-integrations/aerogear-ups/app/src/main/webapp/WEB-INF/web.xml#L44</a><br>
> > > > ><br>
> > > > > But we had the exclusion working w/ the KEYCLOAK 'auth-method', but<br>
> > > this<br>
> > > > > goes back to our initial starts in Dec/Jan.<br>
> > > > > Here is a rebased commit based on your initial commit:<br>
> > > > ><br>
> > > > ><br>
> > > <a href="https://github.com/aerogear/aerogear-unifiedpush-server/blob/2aabd073aaaafa79943ea41d2651f6f0c5e4248e/server/src/main/webapp/WEB-INF/web.xml#L42-L53" target="_blank">https://github.com/aerogear/aerogear-unifiedpush-server/blob/2aabd073aaaafa79943ea41d2651f6f0c5e4248e/server/src/main/webapp/WEB-INF/web.xml#L42-L53</a><br>
> > > > ><br>
> > > > ><br>
> > > > >><br>
> > > > >> ><br>
> > > > >> > On master (plain keycloak; before keycloak.js usage) we are doing<br>
> > > > >> > an<br>
> > > > >> > exclude for those URLs:<br>
> > > > >> ><br>
> > > > >><br>
> > > <a href="https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/server/src/main/webapp/WEB-INF/web.xml#L46-L52" target="_blank">https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/server/src/main/webapp/WEB-INF/web.xml#L46-L52</a><br>
> > > > >><br>
> > > > >> I tried to include your exclusions, but that didn't work for me.<br>
> > > > >><br>
> > > > >> ><br>
> > > > >> ><br>
> > > > >> > IMO if possible, keeping these 'exceptions' (or excludes) under<br>
> > > > >> HTTP_BASIC<br>
> > > > >> > would be the simplest solution, as that means none of our client<br>
> > > SDKs<br>
> > > > >> > (Android, iOS, Cordova, Node.js Sender, Java-Sendet etc) would<br>
> > > require<br>
> > > > >> an<br>
> > > > >> > update.<br>
> > > > >><br>
> > > > >> I had a chat with Stian and looks like it's possible to support both<br>
> > > > >> auth methods in a single app, but that would involve changes on<br>
> > > Keycloak.<br>
> > > > >> It's just the matter of discuss with KC team.<br>
> > > > >><br>
> > > > ><br>
> > > > > I don't think we need to enable to <auth-method> settings in our<br>
> > > web.xml;<br>
> > > > ><br>
> > ><br>
> > > How do you manage login/logout/current logged in user on Angular.js? Is<br>
> > > possible to do on the server side, but how do you control it on the<br>
> > > client side?<br>
> > ><br>
> ><br>
> > Sure, to protect the admin-ui and most of the /rest/* endpoints we need the<br>
> > one <auth-method>KEYCLOAK</auth-method>. No question there. I was trying to<br>
> > say we do not need multiple 'auth-method' elements on web.xml<br>
> ><br>
> > But I think it should be possible to exclude a few URLs, like '/rest/foo'<br>
> > and '/rest/bar', so that they are completely unprotected in terms of<br>
> > Keycloak (e.g. via different security-constraint elements):<br>
> > <a href="https://github.com/aerogear/aerogear-unifiedpush-server/blob/2aabd073aaaafa79943ea41d2651f6f0c5e4248e/server/src/main/webapp/WEB-INF/web.xml" target="_blank">https://github.com/aerogear/aerogear-unifiedpush-server/blob/2aabd073aaaafa79943ea41d2651f6f0c5e4248e/server/src/main/webapp/WEB-INF/web.xml</a><br>
> ><br>
> > In terms of "current logged in user on Angular.js":<br>
> > * For the "/rest/sender" and "/rest/device/registration" endpoints, I don't<br>
> > see a relationship to the user on Angular.js/AdminUI at all.<br>
> ><br>
> > Internally these 'unprotected' (or excluded) endpoints implement the<br>
> > HTTP_BASIC scheme themselves:<br>
> > * They treat the Application/Variant like a 'user', by performing a DB<br>
> > lookup of the give application/variantID<br>
> > * If that (Application or Variant) is found, the endpoints compare the<br>
> > given 'password' form the request w/ the "secret" on the Application or<br>
> > Variant<br>
> ><br>
> > But for these endpoints (sender and device-registration) there is no real<br>
> > user here like "Mr. Jay" or "Push-Admin Foo".<br>
> ><br>
> > The client (registration or sender SDK) performs the auth, by applying the<br>
> > ID and the secret:<br>
> > curl -3 -u "{PushApplicationID}:{MasterSecret}" .... <a href="https://server" target="_blank">https://server</a><br>
> ><br>
> ><br>
> ><br>
> > ><br>
> > > ><br>
> > > > I mean: I think there is no need to enable multiple <auth-method> args,<br>
> > > as<br>
> > > > we had the exclusion already working at some point, using their<br>
> > > > KEYCLOAK<br>
> > > > auth-method<br>
> > ><br>
> > > Stian did that inclusion which for me looks correct. An excerpt from KC<br>
> > > documentation:<br>
> > ><br>
> > > "To be able to secure WAR apps deployed on JBoss AS 7.1.1, JBoss EAP 6.x,<br>
> > > or Wildfly, you must install and configure the Keycloak Subsystem. You<br>
> > > then have two options to secure your WARs. You can provide a keycloak<br>
> > > config file in your WAR and change the auth-method to KEYCLOAK within<br>
> > > web.xml. Alternatively, you don't have to crack open your WARs at all<br>
> > > and can apply Keycloak via the Keycloak Subsystem configuration in<br>
> > > standalone.xml. Both methods are described in this section."<br>
> > ><br>
> > > You can also stick with BASIC, but probably you end with implementations<br>
> > > and customizations that don't take any benefit of Keycloak.js.<br>
> > ><br>
> > > Either way I will talk tomorrow with Stian and let's see what we can do.<br>
> > ><br>
> > > ><br>
> > > ><br>
> > > ><br>
> > > > ><br>
> > > > > My initial hope was to be able to simply exclude a few URLs from the<br>
> > > > > overall Keycloak protection, like the above referenced commit:<br>
> > > > ><br>
> > > > ><br>
> > > <a href="https://github.com/aerogear/aerogear-unifiedpush-server/blob/2aabd073aaaafa79943ea41d2651f6f0c5e4248e/server/src/main/webapp/WEB-INF/web.xml#L42-L53" target="_blank">https://github.com/aerogear/aerogear-unifiedpush-server/blob/2aabd073aaaafa79943ea41d2651f6f0c5e4248e/server/src/main/webapp/WEB-INF/web.xml#L42-L53</a><br>
> > > > ><br>
> > > > > That would be best as that would mean no API change at all, and our<br>
> > > > > client-registration and sender SDKs could stay as they are.<br>
> > > > ><br>
> > > > ><br>
> > > > ><br>
> > > > ><br>
> > > > >><br>
> > > > >> My two cents is the fact that we should use bearer tokens only,<br>
> > > instead<br>
> > > > >> of mix both auth methods in a single app — now that we have KC.<br>
> > > > >> And discuss the changes into our clients rather sooner than later.<br>
> > > > >><br>
> > > > >> But I'm open for whatever you guys think it's the best.<br>
> > > > >><br>
> > > > >><br>
> > > > >> ><br>
> > > > >> > -Matthias<br>
> > > > >> ><br>
> > > > >> ><br>
> > > > >> ><br>
> > > > >> ><br>
> > > > >> ><br>
> > > > >> > ><br>
> > > > >> > > The consequence of this is the basic form being presented when<br>
> > > you try<br>
> > > > >> > > to send push notifications[3]. The problem didn't occur before,<br>
> > > > >> because<br>
> > > > >> > > we were just using Basic authentication[4] instead of Bearer<br>
> > > tokens.<br>
> > > > >> > ><br>
> > > > >> > > Possible solutions:<br>
> > > > >> > ><br>
> > > > >> > > 1- After the removal of Basic authentication, move<br>
> > > _PushApplicationID_<br>
> > > > >> > > and _MasterSecret to http headers like:<br>
> > > > >> > ><br>
> > > > >> > > -H "PushApplicationID: XXXXXX" -H "MasterSecret: 42"<br>
> > > > >> > ><br>
> > > > >> > > IMO it sounds correct and reasonable for me.<br>
> > > > >> > ><br>
> > > > >> > > 2. Create a role specific for the sender like<br>
> > > > >> > > _push-applications_<br>
> > > and<br>
> > > > >> > > dinamically add _PushApplicationID_ and _MasterSecret on<br>
> > > > >> > > Keycloak<br>
> > > > >> where:<br>
> > > > >> > ><br>
> > > > >> > > username: _PushApplicationID_<br>
> > > > >> > > password: _MasterSecret_<br>
> > > > >> > ><br>
> > > > >> > > The implications of this alternative is the fact of have to<br>
> > > > >> > > manage<br>
> > > > >> those<br>
> > > > >> > > credentials on the server side inclusion/exclusion/login<br>
> > > > >> > ><br>
> > > > >> > > 3. Implement another authentication provider specifically for<br>
> > > > >> > > the<br>
> > > > >> sender<br>
> > > > >> > > and Basic authentication[5]<br>
> > > > >> > ><br>
> > > > >> > > 4. Do nothing. The consequences of this alternative is to<br>
> > > implement<br>
> > > > >> > > everything already done by Keycloak.js and manage session tokens<br>
> > > by<br>
> > > > >> hand<br>
> > > > >> > > on the admin-ui.<br>
> > > > >> > ><br>
> > > > >> > > To me the first alternative seems to be more simple, but I<br>
> > > > >> > > really<br>
> > > want<br>
> > > > >> > > your feedback on it, once it affects the whole project.<br>
> > > > >> > ><br>
> > > > >> > > [1] -<br>
> > > > >> > ><br>
> > > > >> > ><br>
> > > > >><br>
> > > <a href="https://github.com/aerogear/aerogear-unifiedpush-server/blob/6c1a0d3fedea8fb6ba918009fd8e9785779c151f/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/sender/PushNotificationSenderEndpoint.java#L56" target="_blank">https://github.com/aerogear/aerogear-unifiedpush-server/blob/6c1a0d3fedea8fb6ba918009fd8e9785779c151f/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/sender/PushNotificationSenderEndpoint.java#L56</a><br>
> > > > >> > ><br>
> > > > >> > > [2] -<br>
> > > > >> > ><br>
> > > > >><br>
> > > <a href="https://github.com/abstractj/aerogear-unifiedpush-server/tree/keycloak.js" target="_blank">https://github.com/abstractj/aerogear-unifiedpush-server/tree/keycloak.js</a><br>
> > > > >> > > [3] -<br>
> > > > >> > ><br>
> > > > >> > ><br>
> > > > >><br>
> > > <a href="http://photon.abstractj.org/AeroGear_UnifiedPush_Server_2014-06-17_10-00-09_2014-06-17_10-00-12.jpg" target="_blank">http://photon.abstractj.org/AeroGear_UnifiedPush_Server_2014-06-17_10-00-09_2014-06-17_10-00-12.jpg</a><br>
> > > > >> > ><br>
> > > > >> > > [4] -<br>
> > > > >> > ><br>
> > > > >> > ><br>
> > > > >><br>
> > > <a href="https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/server/src/main/webapp/WEB-INF/web.xml#L57" target="_blank">https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/server/src/main/webapp/WEB-INF/web.xml#L57</a><br>
> > > > >> > ><br>
> > > > >> > > [5] -<br>
> > > > >> > ><br>
> > > > >><br>
> > > <a href="https://github.com/keycloak/keycloak/tree/master/examples/providers/authentication-properties" target="_blank">https://github.com/keycloak/keycloak/tree/master/examples/providers/authentication-properties</a><br>
> > > > >> > ><br>
> > > > >> > > --<br>
> > > > >> > ><br>
> > > > >> > > abstractj<br>
> > > > >> > > _______________________________________________<br>
> > > > >> > > aerogear-dev mailing list<br>
> > > > >> > > <a href="javascript:;" onclick="_e(event, 'cvml', 'aerogear-dev@lists.jboss.org')">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>
> > > > >> > --<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>
> > > > >><br>
> > > > >> > _______________________________________________<br>
> > > > >> > aerogear-dev mailing list<br>
> > > > >> > <a href="javascript:;" onclick="_e(event, 'cvml', 'aerogear-dev@lists.jboss.org')">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>
> > > > >> abstractj<br>
> > > > >> _______________________________________________<br>
> > > > >> aerogear-dev mailing list<br>
> > > > >> <a href="javascript:;" onclick="_e(event, 'cvml', 'aerogear-dev@lists.jboss.org')">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>
> > > > > --<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>
> > > > ><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>
> > ><br>
> > > > _______________________________________________<br>
> > > > aerogear-dev mailing list<br>
> > > > <a href="javascript:;" onclick="_e(event, 'cvml', 'aerogear-dev@lists.jboss.org')">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>
> > > abstractj<br>
> > > _______________________________________________<br>
> > > aerogear-dev mailing list<br>
> > > <a href="javascript:;" onclick="_e(event, 'cvml', 'aerogear-dev@lists.jboss.org')">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>
> > --<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>
><br>
> > _______________________________________________<br>
> > aerogear-dev mailing list<br>
> > <a href="javascript:;" onclick="_e(event, 'cvml', 'aerogear-dev@lists.jboss.org')">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>
> abstractj<br>
> _______________________________________________<br>
> aerogear-dev mailing list<br>
> <a href="javascript:;" onclick="_e(event, 'cvml', 'aerogear-dev@lists.jboss.org')">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>
aerogear-dev mailing list<br>
<a href="javascript:;" onclick="_e(event, 'cvml', 'aerogear-dev@lists.jboss.org')">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><br>-- <br>Sent from Gmail Mobile<br>