12:18 p.m.
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, 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).
What do you think?
—
Tadeas Kriz
4:47 a.m.
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
8:08 a.m.
On 2014-06-05, Matthias Wessendorf wrote:
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?
I think what Tadeas means is pretty much in the context of KC
configuration file
https://github.com/keycloak/keycloak/blob/master/examples/demo-template/t...
> 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)
As far as I can tell if that is really required, we need to include a
public client for REST.
> 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
--
abstractj
8:14 a.m.
New subject: Direct access to UnifiedPush Server's REST without OAuth
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>
To: "Tadeas Kriz" <tkriz(a)redhat.com>
Cc: "AeroGear Developer Mailing List" <aerogear-dev(a)lists.jboss.org>
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
9:07 a.m.
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.
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>
> To: "Tadeas Kriz" <tkriz(a)redhat.com>
> Cc: "AeroGear Developer Mailing List"
<aerogear-dev(a)lists.jboss.org>
> 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
9:08 a.m.
On Thu, Jun 5, 2014 at 2:14 PM, Stian Thorgersen <stian(a)redhat.com> 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.
that would work just fine w/ curl, I think
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
makes sense
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.
abstractj is already on kc.js :-)
----- Original Message -----
> From: "Matthias Wessendorf" <matzew(a)apache.org>
> To: "Tadeas Kriz" <tkriz(a)redhat.com>
> Cc: "AeroGear Developer Mailing List"
<aerogear-dev(a)lists.jboss.org>
> 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
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
9:09 a.m.
On Thu, Jun 5, 2014 at 3:07 PM, Bruno Oliveira <bruno(a)abstractj.org> 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>
> > To: "Tadeas Kriz" <tkriz(a)redhat.com>
> > Cc: "AeroGear Developer Mailing List"
<aerogear-dev(a)lists.jboss.org>
> > 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
9:16 a.m.
—
Tadeas Kriz
On 05 Jun 2014, at 15:09, Matthias Wessendorf <matzew(a)apache.org> wrote:
On Thu, Jun 5, 2014 at 3:07 PM, Bruno Oliveira <bruno(a)abstractj.org> 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.
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>
> > To: "Tadeas Kriz" <tkriz(a)redhat.com>
> > Cc: "AeroGear Developer Mailing List"
<aerogear-dev(a)lists.jboss.org>
> > 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
9:18 a.m.
On Thu, Jun 5, 2014 at 3:16 PM, Tadeas Kriz <tkriz(a)redhat.com> wrote:
—
Tadeas Kriz
On 05 Jun 2014, at 15:09, Matthias Wessendorf <matzew(a)apache.org> wrote:
On Thu, Jun 5, 2014 at 3:07 PM, Bruno Oliveira <bruno(a)abstractj.org>
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>
> > > To: "Tadeas Kriz" <tkriz(a)redhat.com>
> > > Cc: "AeroGear Developer Mailing List"
<aerogear-dev(a)lists.jboss.org>
> > > 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
10:47 a.m.
On Thu, 5 Jun 2014 15:09:56 +0200
Matthias Wessendorf <matzew(a)apache.org> wrote:
On Thu, Jun 5, 2014 at 3:07 PM, Bruno Oliveira
<bruno(a)abstractj.org> 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 ?
cURL, QE testsuite and any app (e.g. an app with your business logic) willing to
communicate with UPS via REST.
That said, I believe it is fine to keep this behavior (documented) for 0.11.0
and fix in 1.0.0. I'd consider that a critical feature for 1.0.0 though.
>
> 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>
> > > To: "Tadeas Kriz" <tkriz(a)redhat.com>
> > > Cc: "AeroGear Developer Mailing List"
<aerogear-dev(a)lists.jboss.org>
> > > 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
>
8:33 a.m.
On 2014-06-05, Matthias Wessendorf wrote:
On Thu, Jun 5, 2014 at 3:16 PM, Tadeas Kriz <tkriz(a)redhat.com>
wrote:
>
> —
> Tadeas Kriz
>
> On 05 Jun 2014, at 15:09, Matthias Wessendorf <matzew(a)apache.org> wrote:
>
>
>
>
> On Thu, Jun 5, 2014 at 3:07 PM, Bruno Oliveira <bruno(a)abstractj.org>
> 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 ?
+1
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>
>> > > To: "Tadeas Kriz" <tkriz(a)redhat.com>
>> > > Cc: "AeroGear Developer Mailing List"
<aerogear-dev(a)lists.jboss.org>
>> > > 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
--
abstractj
3610
days inactive
3612
days old
10 comments
5 participants
participants (5)
-
Bruno Oliveira -
Karel Piwko -
Matthias Wessendorf -
Stian Thorgersen -
Tadeas Kriz