On Wed, Jun 4, 2014 at 6:18 PM, Tadeas Kriz <tkriz(a)redhat.com&gt; wrote: > Hey guys, > > as you might know, in the integration tests we only test the REST backend, > making sure it works as intended. Before Keycloak, every action was > achievable using the REST, that included login, logout and user management. > We don’t need the user management for sure, but login and logout is an > another story. Now with Keycloak anyone who wants to just use REST calls, > still need to login using the Keycloak. > > My question is, do we want users to be able to access the REST without > OAuth? If we do, it would probably mean we need to have two Keycloak > applications, What do you mean here? Are you suggestion two WAR files (for each 'keycloak application') ? Or just more a declarative setup?

> one for the UI which would still use OAuth and second one for REST calls > which would use Bearer only. This would also mean that when someone makes a > REST call to an endpoint without being authorized, he would receive 401 > response, instead of 302 redirect (before Keycloak, the response was 401 in > case of unauthorized access). > yeah, I think the RESTful APIs behind the 'AdminUI' for the 'application/variant management' should continue to work. (I doubt there is much usage of those outside of the AdminUI)

> What do you think? > > — > Tadeas Kriz > > -- 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

As I suggested this, I'll add a bit more information. It makes sense to have two applications for UPS in Keycloak: 1) A bearer-only application for the REST endpoints - this application does not allow logins and hence won't redirect to login screens, but return 401/403. It will authenticate through the bearer token passed in the headers. Any roles for UPS should be created for this application. Also, the KC adapter (BootstrapListener) is configured for this application, as that secures the REST endpoints 2) A public application for the Admin Console - this applications allows logins. This should have scope mappings on roles in the application above. This is used for the JS console, and I would recommend using keycloak.js. ----- Original Message ----- > From: "Matthias Wessendorf" <matzew(a)apache.org&gt; > To: "Tadeas Kriz" <tkriz(a)redhat.com&gt; > Cc: "AeroGear Developer Mailing List" <aerogear-dev(a)lists.jboss.org&gt; > Sent: Thursday, 5 June, 2014 9:47:21 AM > Subject: Re: [aerogear-dev] Direct access to UnifiedPush Server's REST without OAuth > > > > > On Wed, Jun 4, 2014 at 6:18 PM, Tadeas Kriz < tkriz(a)redhat.com > wrote: > > > Hey guys, > > as you might know, in the integration tests we only test the REST backend, > making sure it works as intended. Before Keycloak, every action was > achievable using the REST, that included login, logout and user management. > We don’t need the user management for sure, but login and logout is an > another story. Now with Keycloak anyone who wants to just use REST calls, > still need to login using the Keycloak. > > My question is, do we want users to be able to access the REST without OAuth? > If we do, it would probably mean we need to have two Keycloak applications, > > What do you mean here? Are you suggestion two WAR files (for each 'keycloak > application') ? Or just more a declarative setup? > > > one for the UI which would still use OAuth and second one for REST calls > which would use Bearer only. This would also mean that when someone makes a > REST call to an endpoint without being authorized, he would receive 401 > response, instead of 302 redirect (before Keycloak, the response was 401 in > case of unauthorized access). > > yeah, I think the RESTful APIs behind the 'AdminUI' for the > 'application/variant management' should continue to work. (I doubt there is > much usage of those outside of the AdminUI) > > > > > What do you think? > > — > Tadeas Kriz > > > > > -- > 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 _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Thu, Jun 5, 2014 at 3:07 PM, Bruno Oliveira <bruno(a)abstractj.org&gt; wrote: Thank you Stian. @tkriz @matzew Atm I'm working on the item 2 from Stian's comments, as soon as I get admin-ui integrated with keycloak.js. Once the integration is finished I can look at item 1 — IMO not a top priority ATM, because it only affects cURL. Correct me if I'm wrong. correct - and the QE test-suite. I am fine in doing that close to 1.0.0 or even for 1.0.1 (depending on how busy the July will be) Makes sense ?

On 2014-06-05, Stian Thorgersen wrote: > As I suggested this, I'll add a bit more information. > > It makes sense to have two applications for UPS in Keycloak: > > 1) A bearer-only application for the REST endpoints - this application does not allow logins and hence won't redirect to login screens, but return 401/403. It will authenticate through the bearer token passed in the headers. Any roles for UPS should be created for this application. Also, the KC adapter (BootstrapListener) is configured for this application, as that secures the REST endpoints > 2) A public application for the Admin Console - this applications allows logins. This should have scope mappings on roles in the application above. This is used for the JS console, and I would recommend using keycloak.js. > > ----- Original Message ----- > > From: "Matthias Wessendorf" <matzew(a)apache.org&gt; > > To: "Tadeas Kriz" <tkriz(a)redhat.com&gt; > > Cc: "AeroGear Developer Mailing List" <aerogear-dev(a)lists.jboss.org&gt; > > Sent: Thursday, 5 June, 2014 9:47:21 AM > > Subject: Re: [aerogear-dev] Direct access to UnifiedPush Server's REST without OAuth > > > > > > > > > > On Wed, Jun 4, 2014 at 6:18 PM, Tadeas Kriz < tkriz(a)redhat.com > wrote: > > > > > > Hey guys, > > > > as you might know, in the integration tests we only test the REST backend, > > making sure it works as intended. Before Keycloak, every action was > > achievable using the REST, that included login, logout and user management. > > We don’t need the user management for sure, but login and logout is an > > another story. Now with Keycloak anyone who wants to just use REST calls, > > still need to login using the Keycloak. > > > > My question is, do we want users to be able to access the REST without OAuth? > > If we do, it would probably mean we need to have two Keycloak applications, > > > > What do you mean here? Are you suggestion two WAR files (for each 'keycloak > > application') ? Or just more a declarative setup? > > > > > > one for the UI which would still use OAuth and second one for REST calls > > which would use Bearer only. This would also mean that when someone makes a > > REST call to an endpoint without being authorized, he would receive 401 > > response, instead of 302 redirect (before Keycloak, the response was 401 in > > case of unauthorized access). > > > > yeah, I think the RESTful APIs behind the 'AdminUI' for the > > 'application/variant management' should continue to work. (I doubt there is > > much usage of those outside of the AdminUI) > > > > > > > > > > What do you think? > > > > — > > Tadeas Kriz > > > > > > > > > > -- > > 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 > > _______________________________________________ > 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

On Thu, Jun 5, 2014 at 3:16 PM, Tadeas Kriz <tkriz(a)redhat.com&gt; wrote: > > — > Tadeas Kriz > > On 05 Jun 2014, at 15:09, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > > > > > On Thu, Jun 5, 2014 at 3:07 PM, Bruno Oliveira <bruno(a)abstractj.org&gt; > wrote: > >> >> Thank you Stian. >> >> @tkriz @matzew Atm I'm working on the item 2 from Stian's comments, as >> soon as I get admin-ui integrated with keycloak.js. Once the integration >> is finished I can look at item 1 — IMO not a top priority ATM, because >> it only affects cURL. >> >> Correct me if I'm wrong. >> > > correct - and the QE test-suite. > > I am fine in doing that close to 1.0.0 or even for 1.0.1 (depending on how > busy the July will be) > > Makes sense ? > > > > I think it does make sense for the 1.0.0. In the integration tests we are > able to replace the configuration required for the tests to work and > authorize so we don’t have to rewrite it to check for 302 now and then > rewrite it back to check for 401 when it’s fixed. I’ll just add some > comments about this into the integration tests so it’s documented. > ok - let's aim for 1.0.0 ?

but not for 0.11 ? -M > > > > >> >> On 2014-06-05, Stian Thorgersen wrote: >> > As I suggested this, I'll add a bit more information. >> > >> > It makes sense to have two applications for UPS in Keycloak: >> > >> > 1) A bearer-only application for the REST endpoints - this application >> does not allow logins and hence won't redirect to login screens, but return >> 401/403. It will authenticate through the bearer token passed in the >> headers. Any roles for UPS should be created for this application. Also, >> the KC adapter (BootstrapListener) is configured for this application, as >> that secures the REST endpoints >> > 2) A public application for the Admin Console - this applications >> allows logins. This should have scope mappings on roles in the application >> above. This is used for the JS console, and I would recommend using >> keycloak.js. >> > >> > ----- Original Message ----- >> > > From: "Matthias Wessendorf" <matzew(a)apache.org&gt; >> > > To: "Tadeas Kriz" <tkriz(a)redhat.com&gt; >> > > Cc: "AeroGear Developer Mailing List" <aerogear-dev(a)lists.jboss.org&gt; >> > > Sent: Thursday, 5 June, 2014 9:47:21 AM >> > > Subject: Re: [aerogear-dev] Direct access to UnifiedPush Server's >> REST without OAuth >> > > >> > > >> > > >> > > >> > > On Wed, Jun 4, 2014 at 6:18 PM, Tadeas Kriz < tkriz(a)redhat.com > >> wrote: >> > > >> > > >> > > Hey guys, >> > > >> > > as you might know, in the integration tests we only test the REST >> backend, >> > > making sure it works as intended. Before Keycloak, every action was >> > > achievable using the REST, that included login, logout and user >> management. >> > > We don’t need the user management for sure, but login and logout is an >> > > another story. Now with Keycloak anyone who wants to just use REST >> calls, >> > > still need to login using the Keycloak. >> > > >> > > My question is, do we want users to be able to access the REST >> without OAuth? >> > > If we do, it would probably mean we need to have two Keycloak >> applications, >> > > >> > > What do you mean here? Are you suggestion two WAR files (for each >> 'keycloak >> > > application') ? Or just more a declarative setup? >> > > >> > > >> > > one for the UI which would still use OAuth and second one for REST >> calls >> > > which would use Bearer only. This would also mean that when someone >> makes a >> > > REST call to an endpoint without being authorized, he would receive >> 401 >> > > response, instead of 302 redirect (before Keycloak, the response was >> 401 in >> > > case of unauthorized access). >> > > >> > > yeah, I think the RESTful APIs behind the 'AdminUI' for the >> > > 'application/variant management' should continue to work. (I doubt >> there is >> > > much usage of those outside of the AdminUI) >> > > >> > > >> > > >> > > >> > > What do you think? >> > > >> > > — >> > > Tadeas Kriz >> > > >> > > >> > > >> > > >> > > -- >> > > 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 >> > >> > _______________________________________________ >> > 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 > > > > _______________________________________________ > 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

As I suggested this, I'll add a bit more information. It makes sense to have two applications for UPS in Keycloak: 1) A bearer-only application for the REST endpoints - this application does not allow logins and hence won't redirect to login screens, but return 401/403. It will authenticate through the bearer token passed in the headers.

Any roles for UPS should be created for this application. Also, the KC adapter (BootstrapListener) is configured for this application, as that secures the REST endpoints

2) A public application for the Admin Console - this applications allows logins. This should have scope mappings on roles in the application above. This is used for the JS console, and I would recommend using keycloak.js.

----- Original Message ----- > From: "Matthias Wessendorf" <matzew(a)apache.org&gt; > To: "Tadeas Kriz" <tkriz(a)redhat.com&gt; > Cc: "AeroGear Developer Mailing List" <aerogear-dev(a)lists.jboss.org&gt; > Sent: Thursday, 5 June, 2014 9:47:21 AM > Subject: Re: [aerogear-dev] Direct access to UnifiedPush Server's REST without OAuth > > > > > On Wed, Jun 4, 2014 at 6:18 PM, Tadeas Kriz < tkriz(a)redhat.com > wrote: > > > Hey guys, > > as you might know, in the integration tests we only test the REST backend, > making sure it works as intended. Before Keycloak, every action was > achievable using the REST, that included login, logout and user management. > We don’t need the user management for sure, but login and logout is an > another story. Now with Keycloak anyone who wants to just use REST calls, > still need to login using the Keycloak. > > My question is, do we want users to be able to access the REST without OAuth? > If we do, it would probably mean we need to have two Keycloak applications, > > What do you mean here? Are you suggestion two WAR files (for each 'keycloak > application') ? Or just more a declarative setup? > > > one for the UI which would still use OAuth and second one for REST calls > which would use Bearer only. This would also mean that when someone makes a > REST call to an endpoint without being authorized, he would receive 401 > response, instead of 302 redirect (before Keycloak, the response was 401 in > case of unauthorized access). > > yeah, I think the RESTful APIs behind the 'AdminUI' for the > 'application/variant management' should continue to work. (I doubt there is > much usage of those outside of the AdminUI) > > > > > What do you think? > > — > Tadeas Kriz > > > > > -- > 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 _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev