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

On 2014-06-17, Matthias Wessendorf wrote: > Bom Dia! > > > On Tue, Jun 17, 2014 at 7:23 PM, Bruno Oliveira <bruno(a)abstractj.org&gt; wrote: > > > Ahoy Jay, answers inline. > > > > On 2014-06-17, Jay Balunas wrote: > > > Great explanation of the issue and options! > > > > > > On Jun 17, 2014, at 10:26 AM, 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 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. > > > > > > How will this impact CURL usage from the command line? > > > How will this impact Java sender usage? > > > > We would change from (being logged in would be required): > > > > curl -3 -u "{PushApplicationID}:{MasterSecret}" > > -v -H "Accept: application/json" -H "Content-type: application/json" > > -X POST > > > > To: > > > > curl -3 > > -v -H "PushApplicationID: XXXXXX" -H "MasterSecret: 42" \ > > -H "Accept: application/json" -H "Content-type: application/json" > > -X POST > > > > > > > That sounds like the most safe change to our client-registration and sender > SDKs. Basically a 'minor' change where we issue the HTTP request. > > I'd vote for this change, but only if it is not possible to exclude a few > URLs from Keycloak ;-) Thanks Matthias, we will try to find a consensus on it.

> > Note, that those excluded endpoints (for device-registration and sender) > don't require any <auth-method> setting in web.xml, > as they implement their own simple HTTP_BASIC handling by querying our > database ;-) > https://github.com/abstractj/aerogear-unifiedpush-server/blob/keycloak.js... If you look at KC examples[1], most of them properly make use of auth-method. IMO it's necessary if we want to benefit of bearer tokens on the admin-ui (I can be wrong on my understanding). > > > > But, yeah - if the exclusion is not possible at all, I like your suggested > header usage fix. IMO that's the one with the fewest risks. > > > -Matthias > > > > > > > > > > > > > > > 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 > > > > > > Would each application have its own "role" just for the sender in this > > case? > > > > Each application would have the same role "ups-application". > > > > > > > > > > > > > 3. Implement another authentication provider specifically for the > > sender > > > > and Basic authentication[5] > > > > > > Not sure of the impact here, but sounds like a complex solution. > > > > Yes, totally agree on that. > > > > > > > > > > > > > 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. > > > > > > -1 > > > > Stian sent to me a message, he might have more ideas about how to > > overcome this issue. I will update you guys during this week. > > > > > > > > > > > > > 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 > > > > > > > > > _______________________________________________ > > > 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 > _______________________________________________ > 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