[aerogear-dev] Keycloak integration and UPS Sender

Wed Jun 18 01:04:12 EDT 2014

On Wed, Jun 18, 2014 at 12:12 AM, Bruno Oliveira <bruno at abstractj.org>
wrote:

> Answers inline.
>
> On 2014-06-17, Matthias Wessendorf wrote:
> > On Tue, Jun 17, 2014 at 8:51 PM, Matthias Wessendorf <matzew at apache.org>
> > wrote:
> >
> > >
> > >
> > >
> > > On Tue, Jun 17, 2014 at 7:17 PM, Bruno Oliveira <bruno at abstractj.org>
> > > wrote:
> > >
> > >> Hi Matthias, answer inline.
> > >>
> > >> On 2014-06-17, Matthias Wessendorf wrote:
> > >> > On Tue, Jun 17, 2014 at 4:26 PM, 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 device (un)registration endpoints are hit by this as well
> > >> > (/rest/registry/device/*).
> > >>
> > >> Currently Keycloak is protecting our endpoints under /rest/*
> > >>
> > >> >
> > >> > 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?
> > >>
> > >> Is not the Keycloak.js usage responsible for this, but the correct
> > >> 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:
> > >
> > >
> https://github.com/keycloak/keycloak/blob/master/project-integrations/aerogear-ups/app/src/main/webapp/WEB-INF/web.xml#L44
> > >
> > > 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:
> > >
> > >
> https://github.com/aerogear/aerogear-unifiedpush-server/blob/2aabd073aaaafa79943ea41d2651f6f0c5e4248e/server/src/main/webapp/WEB-INF/web.xml#L42-L53
> > >
> > >
> > >>
> > >> >
> > >> > 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 tried to include your exclusions, but that didn't work for me.
> > >>
> > >> >
> > >> >
> > >> > 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.
> > >>
> > >> I had a chat with Stian and looks like it's possible to support both
> > >> 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;
> > >
>
> How do you manage login/logout/current logged in user on Angular.js? Is
> possible to do on the server side, but how do you control it on the
> client side?
>

Sure, to protect the admin-ui and most of the /rest/* endpoints we need the
one <auth-method>KEYCLOAK</auth-method>. No question there. I was trying to
say we do not need multiple 'auth-method' elements on web.xml

But I think it should be possible to exclude a few URLs, like '/rest/foo'
and '/rest/bar', so that they are completely unprotected in terms of
Keycloak (e.g. via different security-constraint elements):
https://github.com/aerogear/aerogear-unifiedpush-server/blob/2aabd073aaaafa79943ea41d2651f6f0c5e4248e/server/src/main/webapp/WEB-INF/web.xml

In terms of "current logged in user on Angular.js":
* For the "/rest/sender" and "/rest/device/registration" endpoints, I don't
see a relationship to the user on Angular.js/AdminUI at all.

Internally these 'unprotected' (or excluded) endpoints implement the
HTTP_BASIC scheme themselves:
* They treat the Application/Variant like a 'user', by performing a DB
lookup of the give application/variantID
* If that (Application or Variant) is found, the endpoints compare the
given 'password' form the request w/ the "secret" on the  Application or
Variant

But for these endpoints (sender and device-registration) there is no real
user here like "Mr. Jay" or "Push-Admin Foo".

The client (registration or sender SDK) performs the auth, by applying the
ID and the secret:
curl -3 -u "{PushApplicationID}:{MasterSecret}" .... https://server

>
> >
> > I mean: I think there is no need to enable multiple <auth-method> args,
> as
> > we had the exclusion already working at some point, using their KEYCLOAK
> > auth-method
>
> Stian did that inclusion which for me looks correct. An excerpt from KC
> documentation:
>
> "To be able to secure WAR apps deployed on JBoss AS 7.1.1, JBoss EAP 6.x,
> or Wildfly, you must install and configure the Keycloak Subsystem. You
> then have two options to secure your WARs. You can provide a keycloak
> config file in your WAR and change the auth-method to KEYCLOAK within
> web.xml. Alternatively, you don't have to crack open your WARs at all
> and can apply Keycloak via the Keycloak Subsystem configuration in
> standalone.xml. Both methods are described in this section."
>
> You can also stick with BASIC, but probably you end with implementations
> and customizations that don't take any benefit of Keycloak.js.
>
> Either way I will talk tomorrow with Stian and let's see what we can do.
>
> >
> >
> >
> > >
> > > My initial hope was to be able to simply exclude a few URLs from the
> > > overall Keycloak protection, like the above referenced commit:
> > >
> > >
> https://github.com/aerogear/aerogear-unifiedpush-server/blob/2aabd073aaaafa79943ea41d2651f6f0c5e4248e/server/src/main/webapp/WEB-INF/web.xml#L42-L53
> > >
> > > 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 at 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 at lists.jboss.org
> > >> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > >>
> > >>
> > >> --
> > >>
> > >> abstractj
> > >> _______________________________________________
> > >> aerogear-dev mailing list
> > >> aerogear-dev at 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
> > >
> >
> >
> >
> > --
> > Matthias Wessendorf
> >
> > blog: http://matthiaswessendorf.wordpress.com/
> > sessions: http://www.slideshare.net/mwessendorf
> > twitter: http://twitter.com/mwessendorf
>
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> --
>
> abstractj
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140618/7c47547d/attachment-0001.html 