[aerogear-dev] Keycloak integration and UPS Sender

Matthias Wessendorf matzew at apache.org
Tue Jun 17 14:57:13 EDT 2014


Bom Dia!


On Tue, Jun 17, 2014 at 7:23 PM, Bruno Oliveira <bruno at abstractj.org> 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 at abstractj.org>
> 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 ;-)

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/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/sender/PushNotificationSenderEndpoint.java#L55-L61



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/6c1a0d3fedea8fb6ba918009fd8e9785779c151f/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/sender/PushNotificationSenderEndpoint.java#L56
> > >
> > > [2] -
> > >
> https://github.com/abstractj/aerogear-unifiedpush-server/tree/keycloak.js
> > > [3] -
> > >
> http://photon.abstractj.org/AeroGear_UnifiedPush_Server_2014-06-17_10-00-09_2014-06-17_10-00-12.jpg
> > >
> > > [4] -
> > >
> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/server/src/main/webapp/WEB-INF/web.xml#L57
> > >
> > > [5] -
> https://github.com/keycloak/keycloak/tree/master/examples/providers/authentication-properties
> > >
> > > --
> > >
> > > abstractj
> > > _______________________________________________
> > > aerogear-dev mailing list
> > > aerogear-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
> --
>
> abstractj
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140617/b75ae732/attachment.html 


More information about the aerogear-dev mailing list