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

Karel Piwko kpiwko at redhat.com
Thu Jun 5 10:47:17 EDT 2014


On Thu, 5 Jun 2014 15:09:56 +0200
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 ?
> 

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




More information about the aerogear-dev mailing list