On Tue, Jun 17, 2014 at 7:17 PM, Bruno Oliveira <bruno@abstractj.org> wrote:
Hi Matthias, answer inline.
Currently Keycloak is protecting our endpoints under /rest/*
On 2014-06-17, Matthias Wessendorf wrote:
> On Tue, Jun 17, 2014 at 4:26 PM, 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 device (un)registration endpoints are hit by this as well
> (/rest/registry/device/*).
Is not the Keycloak.js usage responsible for this, but the correct
>
> I am wondering if it isn't it possible to keep those URLs protected via
> HTTP_BASIC, or does the keycloak.js usage deny this?
configuration of the application atm. Please compare:
- master branch:
https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/server/src/main/webapp/WEB-INF/web.xml#L56
- keycloak.js branch:
https://github.com/aerogear/aerogear-unifiedpush-server/blob/keycloak.js/server/src/main/webapp/WEB-INF/web.xml#L33
Now we're fully using Keycloak bearer tokens instead of Basic.Oh, I was following Bill's sample project, where he did not use the 'KEYCLOAK' auth-method:But we had the exclusion working w/ the KEYCLOAK 'auth-method', but this goes back to our initial starts in Dec/Jan.Here is a rebased commit based on your initial commit:I tried to include your exclusions, but that didn't work for me.
>
> On master (plain keycloak; before keycloak.js usage) we are doing an
> exclude for those URLs:
> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/server/src/main/webapp/WEB-INF/web.xml#L46-L52
I had a chat with Stian and looks like it's possible to support both
>
>
> IMO if possible, keeping these 'exceptions' (or excludes) under HTTP_BASIC
> would be the simplest solution, as that means none of our client SDKs
> (Android, iOS, Cordova, Node.js Sender, Java-Sendet etc) would require an
> update.
auth methods in a single app, but that would involve changes on Keycloak.
It's just the matter of discuss with KC team.I don't think we need to enable to <auth-method> settings in our web.xml;
My initial hope was to be able to simply exclude a few URLs from the overall Keycloak protection, like the above referenced commit:That would be best as that would mean no API change at all, and our client-registration and sender SDKs could stay as they are.
My two cents is the fact that we should use bearer tokens only, instead
of mix both auth methods in a single app — now that we have KC.
And discuss the changes into our clients rather sooner than later.
But I'm open for whatever you guys think it's the best.
>
> -Matthias
>
>
>
>
>
> >
> > 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.
> >
> > 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
> >
> > 3. Implement another authentication provider specifically for the sender
> > and Basic authentication[5]
> >
> > 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.
> >
> > 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
> >
>
>
>
> --
> 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