<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jun 17, 2014 at 8:51 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"><br><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div class="h5">On Tue, Jun 17, 2014 at 7:17 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">Hi Matthias, answer inline.<br>
<div><br>
On 2014-06-17, Matthias Wessendorf wrote:<br>
> On Tue, Jun 17, 2014 at 4:26 PM, Bruno Oliveira <<a href="mailto:bruno@abstractj.org" target="_blank">bruno@abstractj.org</a>> 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 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 is under<br>
> > the same umbrella which means that now Bearer token 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>
</div>Currently Keycloak is protecting our endpoints under /rest/*<br>
<div><br>
><br>
> I am wondering if it isn't it possible to keep those URLs protected via<br>
> HTTP_BASIC, or does the keycloak.js usage deny this?<br>
<br>
</div>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>
<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>
<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></blockquote><div><br></div><div><br></div></div></div><div>Oh, I was following Bill's sample project, where he did not use the 'KEYCLOAK' auth-method:</div>
<div><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>
</div><div><br></div><div>But we had the exclusion working w/ the KEYCLOAK 'auth-method', but this goes back to our initial starts in Dec/Jan.</div><div>Here is a rebased commit based on your initial commit:</div>
<div><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>
</div><div class=""><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><br>
><br>
> On master (plain keycloak; before keycloak.js usage) we are doing an<br>
> exclude for those URLs:<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>
</div>I tried to include your exclusions, but that didn't work for me.<br>
<div><br>
><br>
><br>
> IMO if possible, keeping these 'exceptions' (or excludes) under HTTP_BASIC<br>
> would be the simplest solution, as that means none of our client SDKs<br>
> (Android, iOS, Cordova, Node.js Sender, Java-Sendet etc) would require an<br>
> update.<br>
<br>
</div>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 Keycloak.<br>
It's just the matter of discuss with KC team.<br></blockquote><div><br></div></div><div>I don't think we need to enable to <auth-method> settings in our web.xml;</div></div></div></div></blockquote><div><br>
</div><div>I mean: I think there is no need to enable multiple <auth-method> args, as we had the exclusion already working at some point, using their KEYCLOAK auth-method</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>My initial hope was to be able to simply exclude a few URLs from the overall Keycloak protection, like the above referenced commit:</div>
<div><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>
</div><div><br></div><div>That would be best as that would mean no API change at all, and our client-registration and sender SDKs could stay as they are.</div><div><div class="h5"><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">
<br>
My two cents is the fact that we should use bearer tokens only, 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>
<div><div><br>
<br>
><br>
> -Matthias<br>
><br>
><br>
><br>
><br>
><br>
> ><br>
> > The consequence of this is the basic form being presented when you try<br>
> > to send push notifications[3]. The problem didn't occur before, because<br>
> > we were just using Basic authentication[4] instead of Bearer tokens.<br>
> ><br>
> > Possible solutions:<br>
> ><br>
> > 1- After the removal of Basic authentication, move _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 _push-applications_ and<br>
> > dinamically add _PushApplicationID_ and _MasterSecret on Keycloak where:<br>
> ><br>
> > username: _PushApplicationID_<br>
> > password: _MasterSecret_<br>
> ><br>
> > The implications of this alternative is the fact of have to manage those<br>
> > credentials on the server side inclusion/exclusion/login<br>
> ><br>
> > 3. Implement another authentication provider specifically for the sender<br>
> > and Basic authentication[5]<br>
> ><br>
> > 4. Do nothing. The consequences of this alternative is to implement<br>
> > everything already done by Keycloak.js and manage session tokens by hand<br>
> > on the admin-ui.<br>
> ><br>
> > To me the first alternative seems to be more simple, but I really want<br>
> > your feedback on it, once it affects the whole project.<br>
> ><br>
> > [1] -<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>
> > <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>
> > <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>
> > <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>
> > <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="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>
> --<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="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>
abstractj<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></div></div></blockquote></div></div></div><div><div class="h5"><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></div></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></div>