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.

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/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

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&gt; 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 _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On 2014-06-17, Matthias Wessendorf wrote: > Bom Dia! > > > On Tue, Jun 17, 2014 at 7:23 PM, Bruno Oliveira <bruno(a)abstractj.org&gt; wrote: > > > 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&gt; > > 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 > > > > > > > That sounds like the most safe change to our client-registration and sender > SDKs. Basically a 'minor' change where we issue the HTTP request. > > I'd vote for this change, but only if it is not possible to exclude a few > URLs from Keycloak ;-) Thanks Matthias, we will try to find a consensus on it.

> > Note, that those excluded endpoints (for device-registration and sender) > don't require any <auth-method> setting in web.xml, > as they implement their own simple HTTP_BASIC handling by querying our > database ;-) > https://github.com/abstractj/aerogear-unifiedpush-server/blob/keycloak.js... If you look at KC examples[1], most of them properly make use of auth-method. IMO it's necessary if we want to benefit of bearer tokens on the admin-ui (I can be wrong on my understanding). > > > > But, yeah - if the exclusion is not possible at all, I like your suggested > header usage fix. IMO that's the one with the fewest risks. > > > -Matthias > > > > > > > > > > > > > > > 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 > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev(a)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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

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

On Tue, Jun 17, 2014 at 4:26 PM, Bruno Oliveira <bruno(a)abstractj.org&gt; 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/*).

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?

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/serve...

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.

-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/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 > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf

_______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Tue, Jun 17, 2014 at 7:17 PM, Bruno Oliveira <bruno(a)abstractj.org&gt; wrote: > Hi Matthias, answer inline. > > On 2014-06-17, Matthias Wessendorf wrote: > > On Tue, Jun 17, 2014 at 4:26 PM, Bruno Oliveira <bruno(a)abstractj.org&gt; > 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/serve... > - keycloak.js branch: > > https://github.com/aerogear/aerogear-unifiedpush-server/blob/keycloak.js/... > > 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/aer... 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/2aabd073aaaa... > > > > > 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/serve... > > 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;

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/2aabd073aaaa... 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/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 > > > > > > > > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > -- > > abstractj > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)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

Answers inline. On 2014-06-17, Matthias Wessendorf wrote: > On Tue, Jun 17, 2014 at 8:51 PM, Matthias Wessendorf <matzew(a)apache.org&gt; > wrote: > > > > > > > > > On Tue, Jun 17, 2014 at 7:17 PM, Bruno Oliveira <bruno(a)abstractj.org&gt; > > wrote: > > > >> Hi Matthias, answer inline. > >> > >> On 2014-06-17, Matthias Wessendorf wrote: > >> > On Tue, Jun 17, 2014 at 4:26 PM, Bruno Oliveira < bruno(a)abstractj.org&gt; > >> 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/serve... > >> - keycloak.js branch: > >> > >> https://github.com/aerogear/aerogear-unifiedpush-server/blob/keycloak.js/... > >> > >> 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/aer... > > > > 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/2aabd073aaaa... > > > > > >> > >> > > >> > 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/serve... > >> > >> 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?

> > 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/2aabd073aaaa... > > > > 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/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 > >> > > > >> > > >> > > >> > > >> > -- > >> > Matthias Wessendorf > >> > > >> > blog: http://matthiaswessendorf.wordpress.com/ > >> > sessions: http://www.slideshare.net/mwessendorf > >> > twitter: http://twitter.com/mwessendorf > >> > >> > _______________________________________________ > >> > aerogear-dev mailing list > >> > aerogear-dev(a)lists.jboss.org > >> > https://lists.jboss.org/mailman/listinfo/aerogear-dev > >> > >> > >> -- > >> > >> abstractj > >> _______________________________________________ > >> aerogear-dev mailing list > >> aerogear-dev(a)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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

From: "Bruno Oliveira" <bruno(a)abstractj.org&gt; To: "AeroGear Developer Mailing List" <aerogear-dev(a)lists.jboss.org&gt; 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(a)abstractj.org&gt; > wrote: > > > Answers inline. > > > > On 2014-06-17, Matthias Wessendorf wrote: > > > On Tue, Jun 17, 2014 at 8:51 PM, Matthias Wessendorf > > > <matzew(a)apache.org&gt; > > > wrote: > > > > > > > > > > > > > > > > > > > On Tue, Jun 17, 2014 at 7:17 PM, Bruno Oliveira <bruno(a)abstractj.org&gt; > > > > wrote: > > > > > > > >> Hi Matthias, answer inline. > > > >> > > > >> On 2014-06-17, Matthias Wessendorf wrote: > > > >> > On Tue, Jun 17, 2014 at 4:26 PM, Bruno Oliveira < > > bruno(a)abstractj.org&gt; > > > >> 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/serve... > > > >> - keycloak.js branch: > > > >> > > > >> > > https://github.com/aerogear/aerogear-unifiedpush-server/blob/keycloak.js/... > > > >> > > > >> 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/aer... > > > > > > > > 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/2aabd073aaaa... > > > > > > > > > > > >> > > > >> > > > > >> > 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/serve... > > > >> > > > >> 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/2aabd073aaaa... > > 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/2aabd073aaaa... > > > > > > > > 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/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 > > > >> > > > > > >> > > > > >> > > > > >> > > > > >> > -- > > > >> > Matthias Wessendorf > > > >> > > > > >> > blog: http://matthiaswessendorf.wordpress.com/ > > > >> > sessions: http://www.slideshare.net/mwessendorf > > > >> > twitter: http://twitter.com/mwessendorf > > > >> > > > >> > _______________________________________________ > > > >> > aerogear-dev mailing list > > > >> > aerogear-dev(a)lists.jboss.org > > > >> > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > >> > > > >> > > > >> -- > > > >> > > > >> abstractj > > > >> _______________________________________________ > > > >> aerogear-dev mailing list > > > >> aerogear-dev(a)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(a)lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > -- > > > > abstractj > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev(a)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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

Good morning Stian, thanks for the feedback. I'm totally fine with the idea. I think we could start on keeping the backwards compatibility first and implement the other items for UPS beta1. On 2014-06-19, Stian Thorgersen 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(a)abstractj.org&gt; > > To: "AeroGear Developer Mailing List" <aerogear-dev(a)lists.jboss.org&gt; > > 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(a)abstractj.org&gt; > > > wrote: > > > > > > > Answers inline. > > > > > > > > On 2014-06-17, Matthias Wessendorf wrote: > > > > > On Tue, Jun 17, 2014 at 8:51 PM, Matthias Wessendorf > > > > > <matzew(a)apache.org&gt; > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Jun 17, 2014 at 7:17 PM, Bruno Oliveira <bruno(a)abstractj.org&gt; > > > > > > wrote: > > > > > > > > > > > >> Hi Matthias, answer inline. > > > > > >> > > > > > >> On 2014-06-17, Matthias Wessendorf wrote: > > > > > >> > On Tue, Jun 17, 2014 at 4:26 PM, Bruno Oliveira < > > > > bruno(a)abstractj.org&gt; > > > > > >> 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/serve... > > > > > >> - keycloak.js branch: > > > > > >> > > > > > >> > > > > https://github.com/aerogear/aerogear-unifiedpush-server/blob/keycloak.js/... > > > > > >> > > > > > >> 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/aer... > > > > > > > > > > > > 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/2aabd073aaaa... > > > > > > > > > > > > > > > > > >> > > > > > >> > > > > > > >> > 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/serve... > > > > > >> > > > > > >> 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/2aabd073aaaa... > > > > > > 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/2aabd073aaaa... > > > > > > > > > > > > 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/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 > > > > > >> > > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > -- > > > > > >> > Matthias Wessendorf > > > > > >> > > > > > > >> > blog: http://matthiaswessendorf.wordpress.com/ > > > > > >> > sessions: http://www.slideshare.net/mwessendorf > > > > > >> > twitter: http://twitter.com/mwessendorf > > > > > >> > > > > > >> > _______________________________________________ > > > > > >> > aerogear-dev mailing list > > > > > >> > aerogear-dev(a)lists.jboss.org > > > > > >> > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > >> > > > > > >> > > > > > >> -- > > > > > >> > > > > > >> abstractj > > > > > >> _______________________________________________ > > > > > >> aerogear-dev mailing list > > > > > >> aerogear-dev(a)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(a)lists.jboss.org > > > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > > > > > > > -- > > > > > > > > abstractj > > > > _______________________________________________ > > > > aerogear-dev mailing list > > > > aerogear-dev(a)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(a)lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > -- > > > > 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

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(a)redhat.com&gt; 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(a)abstractj.org <javascript:;>> > > To: "AeroGear Developer Mailing List" <aerogear-dev(a)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(a)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(a)apache.org <javascript:;>> > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Jun 17, 2014 at 7:17 PM, Bruno Oliveira < > bruno(a)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(a)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/serve... > > > > > >> - keycloak.js branch: > > > > > >> > > > > > >> > > > > > https://github.com/aerogear/aerogear-unifiedpush-server/blob/keycloak.js/... > > > > > >> > > > > > >> 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/aer... > > > > > > > > > > > > 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/2aabd073aaaa... > > > > > > > > > > > > > > > > > >> > > > > > >> > > > > > > >> > 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/serve... > > > > > >> > > > > > >> 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/2aabd073aaaa... > > > > > > 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/2aabd073aaaa... > > > > > > > > > > > > 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/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 <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(a)lists.jboss.org <javascript:;> > > > > > >> > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > >> > > > > > >> > > > > > >> -- > > > > > >> > > > > > >> abstractj > > > > > >> _______________________________________________ > > > > > >> aerogear-dev mailing list > > > > > >> aerogear-dev(a)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(a)lists.jboss.org <javascript:;> > > > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > > > > > > > -- > > > > > > > > abstractj > > > > _______________________________________________ > > > > aerogear-dev mailing list > > > > aerogear-dev(a)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(a)lists.jboss.org <javascript:;> > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > -- > > > > abstractj > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev(a)lists.jboss.org <javascript:;> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org <javascript:;> > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- Sent from Gmail Mobile

_______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev