[aerogear-dev] Keycloak integration and UPS Sender

[Bruno Oliveira]

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

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