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

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; >

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

> > 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