[aerogear-dev] Keycloak integration and UPS Sender

Thu Jun 19 08:47:07 EDT 2014

Hi,

a few questions:
* for device registration will it be possible to perform the actual
registration by using the variantID and its secret? (Please note that there
is no "user" on the mobile device. Currently, for the registration, we
perform http_basic authentification against a variant (via varianID
/secret))

* isn't it possible to exclude a few URIs (e.g. security-constraint
element(s) in web.xml) from Keycloak? That way 'sender' (and 'device
registration') cloud stay as they are: using their custom http_basic impl

I am NOT against changes, but I am a bit worried that we add new and
instable code for the sender/registration endpoints (and our mobile clients
and our senders), just a few weeks before we will have our 1.0.0 release.

Or are my concerns are invalid and the Android, Cordova, iOS SDKs, as well
as our senders (java and node), will work just fine, without major changes

Thanks,
Matthias

On Thursday, June 19, 2014, Stian Thorgersen <stian at redhat.com> wrote:

> Here's an idea on how it could be done (disclaimer: this is just a rough
> idea so take it with a pinch of salt ;)). Some benefits:
>
> * Relatively simple to maintain backwards compatibility
> * Support public clients directly (by using logged in users permissions)
> * One application can access multiple UPS Apps
> * No need to maintain master secret in UPS (and can support multiple
> methods to auth in the future, for example cert or jwt
> * Manage access through KC - what app/client or user can access what UPS
> App
>
>
> When creating a new UPS App create:
>
> * A role on unified-push-server - the name should be equal to id of UPS app
>
> Applications should have 3 options to authenticate:
>
> * As the logged in user (for client side applications)
> * As themselves (for server side applications)
> * HTTP Basic
>
> The master secret can also be removed from UPS App as it should no longer
> be required.
>
> As the logged in user
> ---------------------
> This allows public applications to send push messages on behalf of the
> logged in user. The steps required are:
>
> 1) Create an application/client in Keycloak
>     * Set to public client
>     * Add scope on UPS App role
> 2) Create user
>     * Add role mapping on UPS App role
> 3) Users logs in with username/password, social, etc through KC login
>    screens
> 4) Application can send push messages with bearer token using users
>    permissions
>
> As themselves
> -------------
> This allows a server-side application to send push messages on behalf of
> itself. The steps required are:
>
> 1) Create an application/client in Keycloak
>     * Add scope on UPS App role
> 2) Create user
>     * Add role mapping on UPS App role
>     * Set a long unique password (equivalent of master secret)
> 3) Application logs in with username/password (equal to UPS App
>    id/master-secret) using direct grant
> 4) Application can send push messages with bearer token using its own
>    permissions
>
> In the future Keycloak will support additional mechanism for a server-side
> application to authenticate on behalf of itself (cert, jwts, etc).
>
> HTTP Basic
> ----------
> For backwards compatibility we can add a valve that extracts the UPS App
> id and master secret from Basic auth. It will then use the direct grant
> mechanism to obtain a token from Keycloak. The steps required to configure
> is the same as "As themselves".
>
>
>
> ----- Original Message -----
> > From: "Bruno Oliveira" <bruno at abstractj.org <javascript:;>>
> > To: "AeroGear Developer Mailing List" <aerogear-dev at lists.jboss.org
> <javascript:;>>
> > Sent: Wednesday, 18 June, 2014 8:12:55 PM
> > Subject: Re: [aerogear-dev] Keycloak integration and UPS Sender
> >
> > Hi guys, let's see the result of the conversation with KC team and we
> > can revisit this discussion if some changed is required.
> >
> > On 2014-06-18, Matthias Wessendorf wrote:
> > > On Wed, Jun 18, 2014 at 12:12 AM, Bruno Oliveira <bruno at abstractj.org
> <javascript:;>>
> > > 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 <javascript:;>>
> > > > > wrote:
> > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Tue, Jun 17, 2014 at 7:17 PM, Bruno Oliveira <
> bruno at abstractj.org <javascript:;>>
> > > > > > 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 <javascript:;>>
> > > > > >> 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 <javascript:;>
> > > > > >> > > 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 <javascript:;>
> > > > > >> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > > > >>
> > > > > >>
> > > > > >> --
> > > > > >>
> > > > > >> abstractj
> > > > > >> _______________________________________________
> > > > > >> aerogear-dev mailing list
> > > > > >> aerogear-dev at lists.jboss.org <javascript:;>
> > > > > >> 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 <javascript:;>
> > > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > >
> > > >
> > > > --
> > > >
> > > > abstractj
> > > > _______________________________________________
> > > > aerogear-dev mailing list
> > > > aerogear-dev at lists.jboss.org <javascript:;>
> > > > 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 <javascript:;>
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> >
> > --
> >
> > abstractj
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org <javascript:;>
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org <javascript:;>
> https://lists.jboss.org/mailman/listinfo/aerogear-dev

-- 
Sent from Gmail Mobile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140619/0022106a/attachment-0001.html 