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

Thu Jun 5 09:18:37 EDT 2014

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 ?
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140605/e0185801/attachment.html 