<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jun 18, 2014 at 12:12 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">Answers inline.<br>
<div><div class="h5"><br>
On 2014-06-17, Matthias Wessendorf wrote:<br>
> On Tue, Jun 17, 2014 at 8:51 PM, Matthias Wessendorf <<a href="mailto: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="mailto: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 <<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<br>
> >> 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>
> >> Currently Keycloak is protecting our endpoints under /rest/*<br>
> >><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>
> >> 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>
> >> <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>
> >> <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>
> > <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 this<br>
> > goes back to our initial starts in Dec/Jan.<br>
> > Here is a rebased commit based on your initial commit:<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 an<br>
> >> > exclude for those URLs:<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 SDKs<br>
> >> > (Android, iOS, Cordova, Node.js Sender, Java-Sendet etc) would 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 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 web.xml;<br>
> ><br>
<br>
</div></div>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></blockquote><div><br></div><div>Sure, to protect the admin-ui and most of the /rest/* endpoints we need the one <auth-method>KEYCLOAK</auth-method>. No question there. I was trying to say we do not need multiple 'auth-method' elements on web.xml</div>
<div><br></div><div>But I think it should be possible to exclude a few URLs, like '/rest/foo' and '/rest/bar', so that they are completely unprotected in terms of Keycloak (e.g. via different security-constraint elements):<br>
</div><div><a href="https://github.com/aerogear/aerogear-unifiedpush-server/blob/2aabd073aaaafa79943ea41d2651f6f0c5e4248e/server/src/main/webapp/WEB-INF/web.xml">https://github.com/aerogear/aerogear-unifiedpush-server/blob/2aabd073aaaafa79943ea41d2651f6f0c5e4248e/server/src/main/webapp/WEB-INF/web.xml</a><br>
</div><div><br></div><div>In terms of "current logged in user on Angular.js":</div><div>* For the "/rest/sender" and "/rest/device/registration" endpoints, I don't see a relationship to the user on Angular.js/AdminUI at all.</div>
<div><br></div><div>Internally these 'unprotected' (or excluded) endpoints implement the HTTP_BASIC scheme themselves:<br></div><div>* They treat the Application/Variant like a 'user', by performing a DB lookup of the give application/variantID</div>
<div>* If that (Application or Variant) is found, the endpoints compare the given 'password' form the request w/ the "secret" on the Application or Variant</div><div><br></div><div>But for these endpoints (sender and device-registration) there is no real user here like "Mr. Jay" or "Push-Admin Foo".</div>
<div><br></div><div>The client (registration or sender SDK) performs the auth, by applying the ID and the secret:</div><div><span style="font-size:13px;font-family:arial,sans-serif">curl -3 -u "{PushApplicationID}:{</span><span style="font-size:13px;font-family:arial,sans-serif">MasterSecret}"</span> .... <a href="https://server">https://server</a></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>
> I mean: I think there is no need to enable multiple <auth-method> args, as<br>
> we had the exclusion already working at some point, using their KEYCLOAK<br>
> auth-method<br>
<br>
</div>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>
<div class=""><div class="h5"><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>
> > <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, 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 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 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<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>
> >> > > 3. Implement another authentication provider specifically for the<br>
> >> 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<br>
> >> 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>
> >> > ><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>
> >> > ><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>
> >> <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>
> >> <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>
> >> ><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>
> >><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="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></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>