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 ;-)

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.



--
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf