12:23 p.m.
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(a)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/6c1a0d3fedea...
>
> [2] -
> https://github.com/abstractj/aerogear-unifiedpush-server/tree/keycloak.js
> [3] -
>
http://photon.abstractj.org/AeroGear_UnifiedPush_Server_2014-06-17_10-00-...
>
> [4] -
>
https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/serve...
>
> [5] -
https://github.com/keycloak/keycloak/tree/master/examples/providers/authe...
>
> --
>
> abstractj
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
abstractj
