Re: [aerogear-dev] Keycloak integration and UPS Sender

Answers inline. On 2014-06-17, Matthias Wessendorf wrote: > On Tue, Jun 17, 2014 at 8:51 PM, Matthias Wessendorf <matzew(a)apache.org&gt; > wrote: > > > > > > > > > On Tue, Jun 17, 2014 at 7:17 PM, Bruno Oliveira <bruno(a)abstractj.org&gt; > > wrote: > > > >> Hi Matthias, answer inline. > >> > >> On 2014-06-17, Matthias Wessendorf wrote: > >> > On Tue, Jun 17, 2014 at 4:26 PM, Bruno Oliveira < bruno(a)abstractj.org&gt; > >> wrote: > >> > > >> > > Good morning peeps, > >> > > > >> > > I have a problem to solve which might affect the Sender and > >> > > all the related clients. > >> > > > >> > > Previously, the UPS Sender was protected by the basic authentication > >> > > method[1], so anyone in possession of _PushApplicationID_ and > >> > > _MasterSecret_ is able to send push messages. > >> > > > >> > > After the integration with Keycloak now everything under _/rest_ > >> > > is properly protect by KC which is totally correct. Our sender is > >> under > >> > > the same umbrella which means that now Bearer token authentication is > >> > > required[2] and Basic authentication won't exist anymore. > >> > > > >> > > >> > > >> > The device (un)registration endpoints are hit by this as well > >> > (/rest/registry/device/*). > >> > >> Currently Keycloak is protecting our endpoints under /rest/* > >> > >> > > >> > I am wondering if it isn't it possible to keep those URLs protected via > >> > HTTP_BASIC, or does the keycloak.js usage deny this? > >> > >> Is not the Keycloak.js usage responsible for this, but the correct > >> configuration of the application atm. Please compare: > >> > >> - master branch: > >> > >> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/serve... > >> - keycloak.js branch: > >> > >> https://github.com/aerogear/aerogear-unifiedpush-server/blob/keycloak.js/... > >> > >> Now we're fully using Keycloak bearer tokens instead of Basic. > >> > > > > > > Oh, I was following Bill's sample project, where he did not use the > > 'KEYCLOAK' auth-method: > > > > https://github.com/keycloak/keycloak/blob/master/project-integrations/aer... > > > > But we had the exclusion working w/ the KEYCLOAK 'auth-method', but this > > goes back to our initial starts in Dec/Jan. > > Here is a rebased commit based on your initial commit: > > > > https://github.com/aerogear/aerogear-unifiedpush-server/blob/2aabd073aaaa... > > > > > >> > >> > > >> > On master (plain keycloak; before keycloak.js usage) we are doing an > >> > exclude for those URLs: > >> > > >> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/serve... > >> > >> I tried to include your exclusions, but that didn't work for me. > >> > >> > > >> > > >> > IMO if possible, keeping these 'exceptions' (or excludes) under > >> HTTP_BASIC > >> > would be the simplest solution, as that means none of our client SDKs > >> > (Android, iOS, Cordova, Node.js Sender, Java-Sendet etc) would require > >> an > >> > update. > >> > >> I had a chat with Stian and looks like it's possible to support both > >> auth methods in a single app, but that would involve changes on Keycloak. > >> It's just the matter of discuss with KC team. > >> > > > > I don't think we need to enable to <auth-method> settings in our web.xml; > > How do you manage login/logout/current logged in user on Angular.js? Is possible to do on the server side, but how do you control it on the client side?

> > 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 Stian did that inclusion which for me looks correct. An excerpt from KC documentation: "To be able to secure WAR apps deployed on JBoss AS 7.1.1, JBoss EAP 6.x, or Wildfly, you must install and configure the Keycloak Subsystem. You then have two options to secure your WARs. You can provide a keycloak config file in your WAR and change the auth-method to KEYCLOAK within web.xml. Alternatively, you don't have to crack open your WARs at all and can apply Keycloak via the Keycloak Subsystem configuration in standalone.xml. Both methods are described in this section." You can also stick with BASIC, but probably you end with implementations and customizations that don't take any benefit of Keycloak.js. Either way I will talk tomorrow with Stian and let's see what we can do. > > > > > > > My initial hope was to be able to simply exclude a few URLs from the > > overall Keycloak protection, like the above referenced commit: > > > > https://github.com/aerogear/aerogear-unifiedpush-server/blob/2aabd073aaaa... > > > > 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. > > > > > > > > > >> > >> My two cents is the fact that we should use bearer tokens only, instead > >> of mix both auth methods in a single app — now that we have KC. > >> And discuss the changes into our clients rather sooner than later. > >> > >> But I'm open for whatever you guys think it's the best. > >> > >> > >> > > >> > -Matthias > >> > > >> > > >> > > >> > > >> > > >> > > > >> > > The consequence of this is the basic form being presented when you try > >> > > to send push notifications[3]. The problem didn't occur before, > >> because > >> > > we were just using Basic authentication[4] instead of Bearer tokens. > >> > > > >> > > Possible solutions: > >> > > > >> > > 1- After the removal of Basic authentication, move _PushApplicationID_ > >> > > and _MasterSecret to http headers like: > >> > > > >> > > -H "PushApplicationID: XXXXXX" -H "MasterSecret: 42" > >> > > > >> > > IMO it sounds correct and reasonable for me. > >> > > > >> > > 2. Create a role specific for the sender like _push-applications_ and > >> > > dinamically add _PushApplicationID_ and _MasterSecret on Keycloak > >> where: > >> > > > >> > > username: _PushApplicationID_ > >> > > password: _MasterSecret_ > >> > > > >> > > The implications of this alternative is the fact of have to manage > >> those > >> > > credentials on the server side inclusion/exclusion/login > >> > > > >> > > 3. Implement another authentication provider specifically for the > >> sender > >> > > and Basic authentication[5] > >> > > > >> > > 4. Do nothing. The consequences of this alternative is to implement > >> > > everything already done by Keycloak.js and manage session tokens by > >> hand > >> > > on the admin-ui. > >> > > > >> > > To me the first alternative seems to be more simple, but I really want > >> > > your feedback on it, once it affects the whole project. > >> > > > >> > > [1] - > >> > > > >> > > > >> https://github.com/aerogear/aerogear-unifiedpush-server/blob/6c1a0d3fedea... > >> > > > >> > > [2] - > >> > > > >> https://github.com/abstractj/aerogear-unifiedpush-server/tree/keycloak.js > >> > > [3] - > >> > > > >> > > > >> http://photon.abstractj.org/AeroGear_UnifiedPush_Server_2014-06-17_10-00-... > >> > > > >> > > [4] - > >> > > > >> > > > >> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/serve... > >> > > > >> > > [5] - > >> > > > >> https://github.com/keycloak/keycloak/tree/master/examples/providers/authe... > >> > > > >> > > -- > >> > > > >> > > abstractj > >> > > _______________________________________________ > >> > > aerogear-dev mailing list > >> > > aerogear-dev(a)lists.jboss.org > >> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > >> > > > >> > > >> > > >> > > >> > -- > >> > Matthias Wessendorf > >> > > >> > blog: http://matthiaswessendorf.wordpress.com/ > >> > sessions: http://www.slideshare.net/mwessendorf > >> > twitter: http://twitter.com/mwessendorf > >> > >> > _______________________________________________ > >> > aerogear-dev mailing list > >> > aerogear-dev(a)lists.jboss.org > >> > https://lists.jboss.org/mailman/listinfo/aerogear-dev > >> > >> > >> -- > >> > >> abstractj > >> _______________________________________________ > >> aerogear-dev mailing list > >> aerogear-dev(a)lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >> > > > > > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev