<div dir="ltr">Bom Dia!<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jun 17, 2014 at 7:23 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">Ahoy Jay, answers inline.<br>
<div class=""><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>> 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>
</div>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>
<div class=""><br></div></blockquote><div><br></div><div><br></div><div><br></div><div>That sounds like the most safe change to our client-registration and sender SDKs. Basically a 'minor' change where we issue the HTTP request.</div>
<div><br></div><div>I'd vote for this change, but only if it is not possible to exclude a few URLs from Keycloak ;-)</div><div><br></div><div>Note, that those excluded endpoints (for device-registration and sender) don't require any <auth-method> setting in web.xml,</div>
<div>as they implement their own simple HTTP_BASIC handling by querying our database ;-)</div><div><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">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>
</div><div><br></div><div><br></div><div><br></div><div>But, yeah - if the exclusion is not possible at all, I like your suggested header usage fix. IMO that's the one with the fewest risks.</div><div><br></div><div><br>
</div><div>-Matthias</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 class="">
><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>
> Would each application have its own "role" just for the sender in this case?<br>
<br>
</div>Each application would have the same role "ups-application".<br>
<div class=""><br>
><br>
> ><br>
> > 3. Implement another authentication provider specifically for the sender<br>
> > and Basic authentication[5]<br>
><br>
> Not sure of the impact here, but sounds like a complex solution.<br>
<br>
</div>Yes, totally agree on that.<br>
<div class=""><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 hand<br>
> > on the admin-ui.<br>
><br>
> -1<br>
<br>
</div>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>
<div class=""><div class="h5"><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>
> > <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>
> > <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>
> > <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] - <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>
</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>