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

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;

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