[aerogear-dev] Keycloak integration and UPS Sender

Wed Jun 18 01:13:03 EDT 2014

On Wed, Jun 18, 2014 at 12:22 AM, Bruno Oliveira <bruno at abstractj.org>
wrote:

> On 2014-06-17, Matthias Wessendorf wrote:
> > 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 ;-)
>
> 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/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/sender/PushNotificationSenderEndpoint.java#L55-L61
>
> If you look at KC examples[1], most of them properly make use of
> auth-method.

yeah, I did not say that we should not use
<auth-mehod>KEYCLOAK</auth-method>. Sorry if that was not clear.

> IMO it's necessary if we want to benefit of bearer tokens
> on the admin-ui (I can be wrong on my understanding).
>

Yeah, I understand! But I'd really like to exclude a few URLs from Keycloak
protection and have themselves handle their auth (HTTP_BASIC in this case),
as explained in my previous email.

If this exclusion, with the proper use of
<auth-mehod>KEYCLOAK</auth-method> is NOT possible, let's pay the tax and
update all of our clients. As said, your header suggestion sounds good to
me and should not take longer than a day (per client). But I'd really like
to avoid that change :-))

-Matthias

>
>
> >
> >
> >
> > 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
>
> > _______________________________________________
> > 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/20140618/d06d0050/attachment.html 