<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jun 5, 2014 at 2:14 PM, Stian Thorgersen <span dir="ltr"><<a href="mailto:stian@redhat.com" target="_blank">stian@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">As I suggested this, I'll add a bit more information.<br>
<br>
It makes sense to have two applications for UPS in Keycloak:<br>
<br>
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.</blockquote>
<div><br></div><div>that would work just fine w/ curl, I think</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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<br>
</blockquote><div><br></div><div>makes sense</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
</blockquote><div><br></div><div>abstractj is already on kc.js :-)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
----- Original Message -----<br>
> From: "Matthias Wessendorf" <<a href="mailto:matzew@apache.org">matzew@apache.org</a>><br>
> To: "Tadeas Kriz" <<a href="mailto:tkriz@redhat.com">tkriz@redhat.com</a>><br>
> Cc: "AeroGear Developer Mailing List" <<a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a>><br>
> Sent: Thursday, 5 June, 2014 9:47:21 AM<br>
> Subject: Re: [aerogear-dev] Direct access to UnifiedPush Server's REST without OAuth<br>
><br>
><br>
><br>
><br>
> On Wed, Jun 4, 2014 at 6:18 PM, Tadeas Kriz < <a href="mailto:tkriz@redhat.com">tkriz@redhat.com</a> > wrote:<br>
><br>
><br>
> Hey guys,<br>
><br>
> as you might know, in the integration tests we only test the REST backend,<br>
> making sure it works as intended. Before Keycloak, every action was<br>
> achievable using the REST, that included login, logout and user management.<br>
> We don’t need the user management for sure, but login and logout is an<br>
> another story. Now with Keycloak anyone who wants to just use REST calls,<br>
> still need to login using the Keycloak.<br>
><br>
> My question is, do we want users to be able to access the REST without OAuth?<br>
> If we do, it would probably mean we need to have two Keycloak applications,<br>
><br>
> What do you mean here? Are you suggestion two WAR files (for each 'keycloak<br>
> application') ? Or just more a declarative setup?<br>
><br>
><br>
> one for the UI which would still use OAuth and second one for REST calls<br>
> which would use Bearer only. This would also mean that when someone makes a<br>
> REST call to an endpoint without being authorized, he would receive 401<br>
> response, instead of 302 redirect (before Keycloak, the response was 401 in<br>
> case of unauthorized access).<br>
><br>
> yeah, I think the RESTful APIs behind the 'AdminUI' for the<br>
> 'application/variant management' should continue to work. (I doubt there is<br>
> much usage of those outside of the AdminUI)<br>
><br>
><br>
><br>
><br>
> What do you think?<br>
><br>
> —<br>
> Tadeas Kriz<br>
><br>
><br>
><br>
><br>
> --<br>
> Matthias Wessendorf<br>
><br>
> blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
> sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
> twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a><br>
><br>
</div></div><div class="HOEnZb"><div class="h5">> _______________________________________________<br>
> aerogear-dev mailing list<br>
> <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
<br>
_______________________________________________<br>
aerogear-dev mailing list<br>
<a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a></div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Matthias Wessendorf <br>
<br>blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a>
</div></div>