On Wed, Jun 18, 2014 at 12:22 AM, Bruno Oliveira <bruno@abstractj.org> wrote:
On 2014-06-17, Matthias Wessendorf wrote:
> Bom Dia!
>
>
> On Tue, Jun 17, 2014 at 7:23 PM, Bruno Oliveira <bruno@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@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@lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > >
> > >
> > > _______________________________________________
> > > aerogear-dev mailing list
> > > aerogear-dev@lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> > --
> >
> > abstractj
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev@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@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


--

abstractj
_______________________________________________
aerogear-dev mailing list
aerogear-dev@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