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

Le 17 juin 2014 à 18:37, Matthias Wessendorf <matzew(a)apache.org&gt; a écrit : > 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/*). 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? 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... 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.

-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