<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jun 18, 2014 at 12:22 AM, 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"><div class="">On 2014-06-17, Matthias Wessendorf wrote:<br>
</div><div><div class="h5">> Bom Dia!<br>
><br>
><br>
> On Tue, Jun 17, 2014 at 7:23 PM, Bruno Oliveira <<a href="mailto:bruno@abstractj.org">bruno@abstractj.org</a>> wrote:<br>
><br>
> > Ahoy Jay, answers inline.<br>
> ><br>
> > On 2014-06-17, Jay Balunas wrote:<br>
> > > Great explanation of the issue and options!<br>
> > ><br>
> > > On Jun 17, 2014, at 10:26 AM, Bruno Oliveira <<a href="mailto: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 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>
> > > > 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>
> > > How will this impact CURL usage from the command line?<br>
> > > How will this impact Java sender usage?<br>
> ><br>
> > We would change from (being logged in would be required):<br>
> ><br>
> > curl -3 -u "{PushApplicationID}:{MasterSecret}"<br>
> > -v -H "Accept: application/json" -H "Content-type: application/json"<br>
> > -X POST<br>
> ><br>
> > To:<br>
> ><br>
> > curl -3<br>
> > -v -H "PushApplicationID: XXXXXX" -H "MasterSecret: 42" \<br>
> > -H "Accept: application/json" -H "Content-type: application/json"<br>
> > -X POST<br>
> ><br>
> ><br>
><br>
><br>
> That sounds like the most safe change to our client-registration and sender<br>
> SDKs. Basically a 'minor' change where we issue the HTTP request.<br>
><br>
> I'd vote for this change, but only if it is not possible to exclude a few<br>
> URLs from Keycloak ;-)<br>
<br>
</div></div>Thanks Matthias, we will try to find a consensus on it.<br>
<div class=""><br>
><br>
> Note, that those excluded endpoints (for device-registration and sender)<br>
> don't require any <auth-method> setting in web.xml,<br>
> as they implement their own simple HTTP_BASIC handling by querying our<br>
> database ;-)<br>
> <a href="https://github.com/abstractj/aerogear-unifiedpush-server/blob/keycloak.js/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/sender/PushNotificationSenderEndpoint.java#L55-L61" target="_blank">https://github.com/abstractj/aerogear-unifiedpush-server/blob/keycloak.js/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/sender/PushNotificationSenderEndpoint.java#L55-L61</a><br>
<br>
</div>If you look at KC examples[1], most of them properly make use of<br>
auth-method. </blockquote><div><br></div><div>yeah, I did not say that we should not use <auth-mehod>KEYCLOAK</auth-method>. Sorry if that was not clear.</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">
IMO it's necessary if we want to benefit of bearer tokens<br>
on the admin-ui (I can be wrong on my understanding).<br></blockquote><div><br></div><div>Yeah, I understand! But I'd really like to exclude a few URLs from Keycloak protection and have themselves handle their auth (HTTP_BASIC in this case), as explained in my previous email.</div>
<div><br></div><div>If this exclusion, with the proper use of <auth-mehod>KEYCLOAK</auth-method> is NOT possible, let's pay the tax and update all of our clients. As said, your header suggestion sounds good to me and should not take longer than a day (per client). But I'd really like to avoid that change :-))</div>
<div><br></div><div><br></div><div>-Matthias<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 class=""><div class="h5"><br>
<br>
><br>
><br>
><br>
> But, yeah - if the exclusion is not possible at all, I like your suggested<br>
> header usage fix. IMO that's the one with the fewest risks.<br>
><br>
><br>
> -Matthias<br>
><br>
><br>
><br>
><br>
> > ><br>
> > > ><br>
> > > > 2. Create a role specific for the sender like _push-applications_ and<br>
> > > > dinamically add _PushApplicationID_ and _MasterSecret on Keycloak<br>
> > where:<br>
> > > ><br>
> > > > username: _PushApplicationID_<br>
> > > > password: _MasterSecret_<br>
> > > ><br>
> > > > The implications of this alternative is the fact of have to manage<br>
> > those<br>
> > > > credentials on the server side inclusion/exclusion/login<br>
> > ><br>
> > > Would each application have its own "role" just for the sender in this<br>
> > case?<br>
> ><br>
> > Each application would have the same role "ups-application".<br>
> ><br>
> > ><br>
> > > ><br>
> > > > 3. Implement another authentication provider specifically for the<br>
> > sender<br>
> > > > and Basic authentication[5]<br>
> > ><br>
> > > Not sure of the impact here, but sounds like a complex solution.<br>
> ><br>
> > Yes, totally agree on that.<br>
> ><br>
> > ><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<br>
> > hand<br>
> > > > on the admin-ui.<br>
> > ><br>
> > > -1<br>
> ><br>
> > Stian sent to me a message, he might have more ideas about how to<br>
> > overcome this issue. I will update you guys during this week.<br>
> ><br>
> > ><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>
> > > ><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">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>
> > > aerogear-dev mailing list<br>
> > > <a href="mailto: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>
> > abstractj<br>
> > _______________________________________________<br>
> > aerogear-dev mailing list<br>
> > <a href="mailto: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="mailto: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="mailto: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>
</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>