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