[aerogear-dev] Direct access to UnifiedPush Server's REST without OAuth

[Bruno Oliveira]

On 2014-06-05, Matthias Wessendorf wrote:
> On Thu, Jun 5, 2014 at 3:16 PM, Tadeas Kriz <tkriz at redhat.com> wrote:
>
> >
> > —
> > Tadeas Kriz
> >
> > On 05 Jun 2014, at 15:09, Matthias Wessendorf <matzew at apache.org> wrote:
> >
> >
> >
> >
> > On Thu, Jun 5, 2014 at 3:07 PM, Bruno Oliveira <bruno at 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 at apache.org>
> >> > > To: "Tadeas Kriz" <tkriz at redhat.com>
> >> > > Cc: "AeroGear Developer Mailing List" <aerogear-dev at 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 at 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 at lists.jboss.org
> >> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >> >
> >> > _______________________________________________
> >> > aerogear-dev mailing list
> >> > aerogear-dev at lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>
> >> --
> >>
> >> abstractj
> >> _______________________________________________
> >> aerogear-dev mailing list
> >> aerogear-dev at 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 at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> >
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


--

abstractj