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