<div dir="ltr">Hi all,<div><br></div><div>I'm also looking into this right now and got it to work. However, I tried to retrieve the username from the HttpServletRequest with "servletRequest.getRemoteUser()" but instead of the name or e-mail I'm getting the actual ID from the database (62ccf5fd-949b-413d-977b-6f8bc29f94bf).</div>
<div><br></div><div>Is this the expected/ intended behavior? </div><div><br></div><div>Also, @Dirk: let me know if you need any help getting the injection of the roles and user id to work.</div><div><br></div><div>Cheers,</div>
<div>Nils</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Mar 28, 2014 at 8:16 AM, Juraci Paixão Kröhling <span dir="ltr"><<a href="mailto:juraci@kroehling.de" target="_blank">juraci@kroehling.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA512<br>
<br>
Dirk,<br>
<br>
It seems it's missing the @SecurityDomain("keycloak") in your service,<br>
at the type level. If that's not the case, I can update the<br>
"sample-ejb-roles" quickstart, adapted to use Keycloak, so you can<br>
compare and check what's missing.<br>
<br>
Just to confirm: have you also added the security-domain to the<br>
standalone.xml? The instructions are at the end of section 6.2.1 from<br>
the user guide:<br>
<br>
<a href="http://docs.jboss.org/keycloak/docs/1.0-alpha-3/userguide/html_single/index.html#d4e485" target="_blank">http://docs.jboss.org/keycloak/docs/1.0-alpha-3/userguide/html_single/index.html#d4e485</a><br>
<br>
Juca.<br>
<div><div class="h5"><br>
On 03/28/2014 01:31 AM, Dirk Franssen wrote:<br>
> Hi,<br>
><br>
> I was playing around with the examples, more specifically with the<br>
> customer-portal-js which is accessing the database resource. In<br>
> that CustomerService I was trying to get access to the Principal<br>
> and trying to extend to return in addition the username of the<br>
> logged-in user:<br>
><br>
> @Path("customers") public class CustomerService {<br>
><br>
> @Inject Principal principal;<br>
><br>
> //@Context //SecurityContext sc; //Principal principal =<br>
> sc.getUserPrincipal();<br>
><br>
> //@Context //ContainerRequestContext request; //SecurityContext sc<br>
> = request.getSecurityContext(); //Principal principal =<br>
> sc.getUserPrincipal();<br>
><br>
> @GET @Produces("application/json") @NoCache public List<String><br>
> getCustomers() { ArrayList<String> rtn = new ArrayList<String>();<br>
> rtn.add("Bill Burke"); rtn.add("Stian Thorgersen"); rtn.add("Stan<br>
> Silvert"); rtn.add("Gabriel Cardoso"); rtn.add("Viliam Rockai");<br>
> rtn.add("Marek Posolda"); rtn.add("Boleslaw Dawidowicz");<br>
> rtn.add(principal.getName()); //<--- add username to the list<br>
> return rtn; } }<br>
><br>
> But this throws a npe as the principal is always null. I noticed<br>
> that the JaxrsBearerTokenFilter is adding to the<br>
> ContainerRequestContext a new SecurityContex, of which the<br>
> getUserPrincipal method returns the KeycloakPrincipal. But I can't<br>
> figure out how to get access to this from the CustomerService.<br>
><br>
> My intention is to verify if the logged-in user is accessing his<br>
> own resources, and e.g. is not trying to update data of somebody<br>
> else. E.g. the id should match principal.getName() in following:<br>
><br>
> @POST @Path("/users/{id}/friends") public void<br>
> addFriend(@PathParam("id") String userId, Friend friend) { ... }<br>
><br>
> Any suggestions? It would be nice if, beside the KeycloakPrincipal<br>
> is injectable, to be able to define something like @IsOwner:<br>
><br>
> public void addFriend(@PathParam("id") @IsOwner String userId,<br>
> Friend friend)<br>
><br>
> or even more concise:<br>
><br>
> public void addFriend(@IsOwner("id") String userId, Friend friend)<br>
><br>
> Kind regards, Dirk Franssen<br>
><br>
><br>
> On Thu, Mar 27, 2014 at 5:29 PM,<br>
> <<a href="mailto:keycloak-user-request@lists.jboss.org">keycloak-user-request@lists.jboss.org</a><br>
</div></div><div class="">> <mailto:<a href="mailto:keycloak-user-request@lists.jboss.org">keycloak-user-request@lists.jboss.org</a>>> wrote:<br>
><br>
> Send keycloak-user mailing list submissions to<br>
> <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
</div>> <mailto:<a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a>><br>
<div class="">><br>
> To subscribe or unsubscribe via the World Wide Web, visit<br>
> <a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a> or, via<br>
> email, send a message with subject or body 'help' to<br>
> <a href="mailto:keycloak-user-request@lists.jboss.org">keycloak-user-request@lists.jboss.org</a><br>
</div>> <mailto:<a href="mailto:keycloak-user-request@lists.jboss.org">keycloak-user-request@lists.jboss.org</a>><br>
<div class="">><br>
> You can reach the person managing the list at<br>
> <a href="mailto:keycloak-user-owner@lists.jboss.org">keycloak-user-owner@lists.jboss.org</a><br>
</div>> <mailto:<a href="mailto:keycloak-user-owner@lists.jboss.org">keycloak-user-owner@lists.jboss.org</a>><br>
<div class="">><br>
> When replying, please edit your Subject line so it is more<br>
> specific than "Re: Contents of keycloak-user digest..."<br>
><br>
><br>
> Today's Topics:<br>
><br>
> 1. Re: Keycloak and AngularJS (Bill Burke) 2. Re: Keycloak and<br>
> AngularJS (Stian Thorgersen) 3. Re: Keycloak and AngularJS (Nils<br>
> Preusker) 4. Re: Keycloak and AngularJS (Bill Burke)<br>
><br>
><br>
> ----------------------------------------------------------------------<br>
><br>
> Message: 1 Date: Thu, 27 Mar 2014 11:39:07 -0400 From: Bill Burke<br>
</div>> <<a href="mailto:bburke@redhat.com">bburke@redhat.com</a> <mailto:<a href="mailto:bburke@redhat.com">bburke@redhat.com</a>>> Subject: Re:<br>
<div class="">> [keycloak-user] Keycloak and AngularJS To:<br>
> <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
</div>> <mailto:<a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a>> Message-ID:<br>
> <<a href="mailto:5334461B.8040202@redhat.com">5334461B.8040202@redhat.com</a> <mailto:<a href="mailto:5334461B.8040202@redhat.com">5334461B.8040202@redhat.com</a>>><br>
<div><div class="h5">> Content-Type: text/plain; charset=ISO-8859-1; format=flowed<br>
><br>
> What I like about the current admin console approach is that there<br>
> is no book keeping required by the browser. The Angular app has<br>
> really no knowledge of how it is being secured as its all driven by<br>
> the server. Also, you need to remember that the admin console was<br>
> designed to be run in a non-Java EE, non-servlet environment.<br>
> While this is a requirement for Keycloak, it may not be for your<br>
> application. So, what I'm saying is that for your angular<br>
> application, you could rely on the servlet container and keycloak<br>
> adapter to maintain a session cookie and identity.<br>
><br>
> What I like about the keycloak.js approach is that there is no<br>
> server-side adapter required for the UI. The UI could be hosted<br>
> off any number of static web sites and use CORS invocations to any<br>
> number of Restful services.<br>
><br>
> There's also the debate of public vs. confidential clients. The<br>
> keycloak.js approach requires a public client. My understanding<br>
> was that confidential clients exist so that only an authenticated<br>
> client (client *NOT* user) is able to obtain an access token. I'm<br>
> not exactly sure what additional security benefits are obtained<br>
> here beyond this. I've been trying to ask this very question on<br>
> OAuth mail lists but have been unable to get a response so far.<br>
><br>
><br>
><br>
> On 3/27/2014 10:41 AM, Nils Preusker wrote:<br>
>> Hi Stian and Bill,<br>
>><br>
>> I've posted some questions regarding this topic before but I<br>
> thought I'd<br>
>> start a new thread to keep things focused:<br>
>><br>
>> I'm writing an AngularJS application with Java EE 6/7 REST<br>
>> (JAX-RS) backend modules. To add authentication and authorization<br>
>> to this application, I'd like to use keycloak<br>
>><br>
>> * as a user and role management front-end * to provide a<br>
>> customizable login page (works very well by the way ;) * as an<br>
>> OAuth 2.0 token provider * to add user and role information to<br>
>> the HTTPRequests in my REST/ backend modules<br>
>><br>
>> To do this, I'm currently looking at keycloak.js and the<br>
> customer-app-js<br>
>> example. However, I'm wondering whether this is really the best<br>
>> way to go. In a reply to an earlier post of mine you mentioned<br>
>> that the keycloak admin console is written in AngularJS and that<br>
>> you are using HTTP-only cookies there.<br>
>><br>
>> However, in keycloak.js and the customer-app-js example you are<br>
>> retrieving the token in the JS app and adding an authorization<br>
>> header with a bearer token to the HTTP requests.<br>
>><br>
>> So here are my questions:<br>
>><br>
>> * Is there a reason you are using two different approaches in<br>
>> the<br>
> admin<br>
>> console and the official demo app? * which one of the two<br>
>> approaches (bearer tokens vs. HTTP-only cookie) will you support/<br>
>> will be the officially recommended one for HTML5/ client side<br>
>> JavaScript applications in keycloak? * am I right in assuming<br>
>> that you haven't quite decided yet which approach to use and that<br>
>> you are still discussing this in the<br>
> keycloak team?<br>
>><br>
>> Looking forwards to your reply! Cheers, Nils<br>
>><br>
>><br>
>> _______________________________________________ keycloak-user<br>
>> mailing list <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
</div></div>>> <mailto:<a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a>><br>
<div class="">>> <a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
>><br>
><br>
> -- Bill Burke JBoss, a division of Red Hat<br>
> <a href="http://bill.burkecentral.com" target="_blank">http://bill.burkecentral.com</a><br>
><br>
><br>
> ------------------------------<br>
><br>
> Message: 2 Date: Thu, 27 Mar 2014 12:18:01 -0400 (EDT) From: Stian<br>
</div>> Thorgersen <<a href="mailto:stian@redhat.com">stian@redhat.com</a> <mailto:<a href="mailto:stian@redhat.com">stian@redhat.com</a>>> Subject:<br>
<div class="">> Re: [keycloak-user] Keycloak and AngularJS To: Bill Burke<br>
</div>> <<a href="mailto:bburke@redhat.com">bburke@redhat.com</a> <mailto:<a href="mailto:bburke@redhat.com">bburke@redhat.com</a>>> Cc:<br>
> <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
> <mailto:<a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a>> Message-ID:<br>
> <<a href="mailto:884719116.3009607.1395937081146.JavaMail.zimbra@redhat.com">884719116.3009607.1395937081146.JavaMail.zimbra@redhat.com</a><br>
> <mailto:<a href="mailto:884719116.3009607.1395937081146.JavaMail.zimbra@redhat.com">884719116.3009607.1395937081146.JavaMail.zimbra@redhat.com</a>>><br>
<div class="">><br>
><br>
Content-Type: text/plain; charset=utf-8<br>
><br>
> Personally, I think that in most cases for a client-side web app<br>
> the best approach is to let the client-side do the oauth flow (the<br>
> approach we're currently taking in keycloak.js). It does depend on<br>
> your application though, and if you're application has a strict<br>
> one html5 app calls one REST service then http-only cookies are an<br>
> option. I don't see any real benefits of it though, and I believe<br>
> it significantly complicates things.<br>
><br>
> Have a look at<br>
> <a href="http://blog.auth0.com/2014/01/07/angularjs-authentication-with-cookies-vs-token/" target="_blank">http://blog.auth0.com/2014/01/07/angularjs-authentication-with-cookies-vs-token/</a>,<br>
><br>
><br>
I think it provides a good summary of the pros of the token approach.<br>
><br>
> ----- Original Message -----<br>
>> From: "Bill Burke" <<a href="mailto:bburke@redhat.com">bburke@redhat.com</a><br>
</div><div><div class="h5">>> <mailto:<a href="mailto:bburke@redhat.com">bburke@redhat.com</a>>> To: <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
> <mailto:<a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a>><br>
>> Sent: Thursday, 27 March, 2014 3:39:07 PM Subject: Re:<br>
>> [keycloak-user] Keycloak and AngularJS<br>
>><br>
>> What I like about the current admin console approach is that<br>
>> there<br>
> is no<br>
>> book keeping required by the browser. The Angular app has really<br>
>> no knowledge of how it is being secured as its all driven by the<br>
>> server. Also, you need to remember that the admin console was<br>
>> designed to<br>
> be run<br>
>> in a non-Java EE, non-servlet environment. While this is a<br>
> requirement<br>
>> for Keycloak, it may not be for your application. So, what I'm<br>
>> saying is that for your angular application, you could rely on<br>
>> the servlet container and keycloak adapter to maintain a session<br>
>> cookie and<br>
> identity.<br>
>><br>
>> What I like about the keycloak.js approach is that there is no<br>
>> server-side adapter required for the UI. The UI could be hosted<br>
> off any<br>
>> number of static web sites and use CORS invocations to any number<br>
>> of Restful services.<br>
>><br>
>> There's also the debate of public vs. confidential clients. The<br>
>> keycloak.js approach requires a public client. My understanding<br>
>> was that confidential clients exist so that only an authenticated<br>
>> client (client *NOT* user) is able to obtain an access token.<br>
>> I'm not<br>
> exactly<br>
>> sure what additional security benefits are obtained here beyond<br>
>> this. I've been trying to ask this very question on OAuth mail<br>
>> lists but<br>
> have<br>
>> been unable to get a response so far.<br>
>><br>
>><br>
>><br>
>> On 3/27/2014 10:41 AM, Nils Preusker wrote:<br>
>>> Hi Stian and Bill,<br>
>>><br>
>>> I've posted some questions regarding this topic before but I<br>
> thought I'd<br>
>>> start a new thread to keep things focused:<br>
>>><br>
>>> I'm writing an AngularJS application with Java EE 6/7 REST<br>
>>> (JAX-RS) backend modules. To add authentication and<br>
>>> authorization to this application, I'd like to use keycloak<br>
>>><br>
>>> * as a user and role management front-end * to provide a<br>
>>> customizable login page (works very well by the<br>
> way ;)<br>
>>> * as an OAuth 2.0 token provider * to add user and role<br>
>>> information to the HTTPRequests in my REST/ backend modules<br>
>>><br>
>>> To do this, I'm currently looking at keycloak.js and the<br>
> customer-app-js<br>
>>> example. However, I'm wondering whether this is really the<br>
>>> best<br>
> way to<br>
>>> go. In a reply to an earlier post of mine you mentioned that<br>
>>> the keycloak admin console is written in AngularJS and that you<br>
>>> are<br>
> using<br>
>>> HTTP-only cookies there.<br>
>>><br>
>>> However, in keycloak.js and the customer-app-js example you<br>
>>> are retrieving the token in the JS app and adding an<br>
>>> authorization<br>
> header<br>
>>> with a bearer token to the HTTP requests.<br>
>>><br>
>>> So here are my questions:<br>
>>><br>
>>> * Is there a reason you are using two different approaches in<br>
> the admin<br>
>>> console and the official demo app? * which one of the two<br>
>>> approaches (bearer tokens vs. HTTP-only<br>
> cookie)<br>
>>> will you support/ will be the officially recommended one for<br>
>>> HTML5/ client side JavaScript applications in keycloak? * am I<br>
>>> right in assuming that you haven't quite decided yet which<br>
>>> approach to use and that you are still discussing this in the<br>
> keycloak<br>
>>> team?<br>
>>><br>
>>> Looking forwards to your reply! Cheers, Nils<br>
>>><br>
>>><br>
>>> _______________________________________________ keycloak-user<br>
>>> mailing list <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
</div></div>>>> <mailto:<a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a>><br>
<div class="">>>> <a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
>>><br>
>><br>
>> -- Bill Burke JBoss, a division of Red Hat<br>
>> <a href="http://bill.burkecentral.com" target="_blank">http://bill.burkecentral.com</a><br>
>> _______________________________________________ keycloak-user<br>
>> mailing list <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
</div>>> <mailto:<a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a>><br>
<div class="">>> <a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
>><br>
><br>
><br>
> ------------------------------<br>
><br>
> Message: 3 Date: Thu, 27 Mar 2014 17:24:06 +0100 From: Nils<br>
</div>> Preusker <<a href="mailto:n.preusker@gmail.com">n.preusker@gmail.com</a> <mailto:<a href="mailto:n.preusker@gmail.com">n.preusker@gmail.com</a>>><br>
<div class="">> Subject: Re: [keycloak-user] Keycloak and AngularJS To:<br>
> <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
</div>> <mailto:<a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a>> Message-ID:<br>
><br>
> <CA+HCLu_XG0xu+KUALgxoDuAMftA=<a href="mailto:rBgV-eFhwbDvaxq48NiOwQ@mail.gmail.com">rBgV-eFhwbDvaxq48NiOwQ@mail.gmail.com</a><br>
><br>
><br>
<mailto:<a href="mailto:rBgV-eFhwbDvaxq48NiOwQ@mail.gmail.com">rBgV-eFhwbDvaxq48NiOwQ@mail.gmail.com</a>>><br>
<div class="">> Content-Type: text/plain; charset="iso-8859-1"<br>
><br>
> Hi Stian and Bill,<br>
><br>
> thanks for your replies! I'll check out the blog post and try the<br>
> approach with a web.xml and a keycloak.json in the backend for now.<br>
> I'll keep you posted on what I end up with on the client side.<br>
><br>
> Cheers, Nils<br>
><br>
><br>
><br>
> On Thu, Mar 27, 2014 at 5:18 PM, Stian Thorgersen<br>
</div><div class="">> <<a href="mailto:stian@redhat.com">stian@redhat.com</a> <mailto:<a href="mailto:stian@redhat.com">stian@redhat.com</a>>> wrote:<br>
><br>
>> Personally, I think that in most cases for a client-side web app<br>
> the best<br>
>> approach is to let the client-side do the oauth flow (the<br>
>> approach<br>
> we're<br>
>> currently taking in keycloak.js). It does depend on your<br>
>> application though, and if you're application has a strict one<br>
>> html5 app calls<br>
> one REST<br>
>> service then http-only cookies are an option. I don't see any<br>
>> real<br>
> benefits<br>
>> of it though, and I believe it significantly complicates things.<br>
>><br>
>> Have a look at<br>
>><br>
> <a href="http://blog.auth0.com/2014/01/07/angularjs-authentication-with-cookies-vs-token/" target="_blank">http://blog.auth0.com/2014/01/07/angularjs-authentication-with-cookies-vs-token/</a>,<br>
><br>
> I think it provides a good summary of the pros of the token<br>
> approach.<br>
>><br>
>> ----- Original Message -----<br>
>>> From: "Bill Burke" <<a href="mailto:bburke@redhat.com">bburke@redhat.com</a><br>
</div><div><div class="h5">>>> <mailto:<a href="mailto:bburke@redhat.com">bburke@redhat.com</a>>> To: <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
> <mailto:<a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a>><br>
>>> Sent: Thursday, 27 March, 2014 3:39:07 PM Subject: Re:<br>
>>> [keycloak-user] Keycloak and AngularJS<br>
>>><br>
>>> What I like about the current admin console approach is that<br>
> there is no<br>
>>> book keeping required by the browser. The Angular app has<br>
>>> really no knowledge of how it is being secured as its all<br>
>>> driven by the<br>
> server.<br>
>>> Also, you need to remember that the admin console was designed<br>
> to be run<br>
>>> in a non-Java EE, non-servlet environment. While this is a<br>
> requirement<br>
>>> for Keycloak, it may not be for your application. So, what<br>
>>> I'm<br>
> saying<br>
>>> is that for your angular application, you could rely on the<br>
>>> servlet container and keycloak adapter to maintain a session<br>
>>> cookie and<br>
> identity.<br>
>>><br>
>>> What I like about the keycloak.js approach is that there is no<br>
>>> server-side adapter required for the UI. The UI could be<br>
>>> hosted<br>
> off any<br>
>>> number of static web sites and use CORS invocations to any<br>
>>> number of Restful services.<br>
>>><br>
>>> There's also the debate of public vs. confidential clients.<br>
>>> The keycloak.js approach requires a public client. My<br>
>>> understanding was that confidential clients exist so that only<br>
>>> an authenticated client (client *NOT* user) is able to obtain<br>
>>> an access token. I'm not<br>
> exactly<br>
>>> sure what additional security benefits are obtained here<br>
>>> beyond<br>
> this.<br>
>>> I've been trying to ask this very question on OAuth mail lists<br>
> but have<br>
>>> been unable to get a response so far.<br>
>>><br>
>>><br>
>>><br>
>>> On 3/27/2014 10:41 AM, Nils Preusker wrote:<br>
>>>> Hi Stian and Bill,<br>
>>>><br>
>>>> I've posted some questions regarding this topic before but I<br>
> thought<br>
>> I'd<br>
>>>> start a new thread to keep things focused:<br>
>>>><br>
>>>> I'm writing an AngularJS application with Java EE 6/7 REST<br>
> (JAX-RS)<br>
>>>> backend modules. To add authentication and authorization to<br>
>>>> this application, I'd like to use keycloak<br>
>>>><br>
>>>> * as a user and role management front-end * to provide a<br>
>>>> customizable login page (works very well by the<br>
> way ;)<br>
>>>> * as an OAuth 2.0 token provider * to add user and role<br>
>>>> information to the HTTPRequests in my REST/ backend modules<br>
>>>><br>
>>>> To do this, I'm currently looking at keycloak.js and the<br>
>> customer-app-js<br>
>>>> example. However, I'm wondering whether this is really the<br>
> best way to<br>
>>>> go. In a reply to an earlier post of mine you mentioned that<br>
>>>> the keycloak admin console is written in AngularJS and that<br>
>>>> you<br>
> are using<br>
>>>> HTTP-only cookies there.<br>
>>>><br>
>>>> However, in keycloak.js and the customer-app-js example you<br>
>>>> are retrieving the token in the JS app and adding an<br>
>>>> authorization<br>
> header<br>
>>>> with a bearer token to the HTTP requests.<br>
>>>><br>
>>>> So here are my questions:<br>
>>>><br>
>>>> * Is there a reason you are using two different approaches<br>
>>>> in<br>
> the admin<br>
>>>> console and the official demo app? * which one of the two<br>
>>>> approaches (bearer tokens vs. HTTP-only<br>
> cookie)<br>
>>>> will you support/ will be the officially recommended one for<br>
> HTML5/<br>
>>>> client side JavaScript applications in keycloak? * am I right<br>
>>>> in assuming that you haven't quite decided yet which approach<br>
>>>> to use and that you are still discussing this in the<br>
> keycloak<br>
>>>> team?<br>
>>>><br>
>>>> Looking forwards to your reply! Cheers, Nils<br>
>>>><br>
>>>><br>
>>>> _______________________________________________ keycloak-user<br>
>>>> mailing list <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
</div></div>> <mailto:<a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a>><br>
<div class="">>>>> <a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
>>>><br>
>>><br>
>>> -- Bill Burke JBoss, a division of Red Hat<br>
>>> <a href="http://bill.burkecentral.com" target="_blank">http://bill.burkecentral.com</a><br>
>>> _______________________________________________ keycloak-user<br>
>>> mailing list <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
</div>>>> <mailto:<a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a>><br>
<div class="">>>> <a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
>>><br>
>> _______________________________________________ keycloak-user<br>
>> mailing list <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
</div>>> <mailto:<a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a>><br>
<div class="">>> <a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
>><br>
> -------------- next part -------------- An HTML attachment was<br>
> scrubbed... URL:<br>
> <a href="http://lists.jboss.org/pipermail/keycloak-user/attachments/20140327/b8e5ee89/attachment-0001.html" target="_blank">http://lists.jboss.org/pipermail/keycloak-user/attachments/20140327/b8e5ee89/attachment-0001.html</a><br>
><br>
> ------------------------------<br>
><br>
> Message: 4 Date: Thu, 27 Mar 2014 12:29:54 -0400 From: Bill Burke<br>
</div>> <<a href="mailto:bburke@redhat.com">bburke@redhat.com</a> <mailto:<a href="mailto:bburke@redhat.com">bburke@redhat.com</a>>> Subject: Re:<br>
<div class="">> [keycloak-user] Keycloak and AngularJS To: Stian Thorgersen<br>
</div>> <<a href="mailto:stian@redhat.com">stian@redhat.com</a> <mailto:<a href="mailto:stian@redhat.com">stian@redhat.com</a>>> Cc:<br>
> <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
> <mailto:<a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a>> Message-ID:<br>
> <<a href="mailto:53345202.4060105@redhat.com">53345202.4060105@redhat.com</a> <mailto:<a href="mailto:53345202.4060105@redhat.com">53345202.4060105@redhat.com</a>>><br>
<div class="">> Content-Type: text/plain; charset=UTF-8; format=flowed<br>
><br>
> One of the problems with the keycloak.js approach is that we have<br>
> no way to perform a single log out or to force a logout of a<br>
> specific user. I think the OpenID Connect spec may have a way with<br>
> IFrames to do this sort of thing though. I didn't really get it at<br>
> first glance though.<br>
><br>
><br>
> On 3/27/2014 12:18 PM, Stian Thorgersen wrote:<br>
>> Personally, I think that in most cases for a client-side web app<br>
> the best approach is to let the client-side do the oauth flow (the<br>
> approach we're currently taking in keycloak.js). It does depend on<br>
> your application though, and if you're application has a strict<br>
> one html5 app calls one REST service then http-only cookies are an<br>
> option. I don't see any real benefits of it though, and I believe<br>
> it significantly complicates things.<br>
>><br>
>> Have a look at<br>
> <a href="http://blog.auth0.com/2014/01/07/angularjs-authentication-with-cookies-vs-token/" target="_blank">http://blog.auth0.com/2014/01/07/angularjs-authentication-with-cookies-vs-token/</a>,<br>
><br>
><br>
I think it provides a good summary of the pros of the token approach.<br>
>><br>
>> ----- Original Message -----<br>
>>> From: "Bill Burke" <<a href="mailto:bburke@redhat.com">bburke@redhat.com</a><br>
</div><div><div class="h5">>>> <mailto:<a href="mailto:bburke@redhat.com">bburke@redhat.com</a>>> To: <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
> <mailto:<a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a>><br>
>>> Sent: Thursday, 27 March, 2014 3:39:07 PM Subject: Re:<br>
>>> [keycloak-user] Keycloak and AngularJS<br>
>>><br>
>>> What I like about the current admin console approach is that<br>
> there is no<br>
>>> book keeping required by the browser. The Angular app has<br>
>>> really no knowledge of how it is being secured as its all<br>
>>> driven by the server. Also, you need to remember that the admin<br>
>>> console was designed to<br>
> be run<br>
>>> in a non-Java EE, non-servlet environment. While this is a<br>
> requirement<br>
>>> for Keycloak, it may not be for your application. So, what<br>
>>> I'm<br>
> saying<br>
>>> is that for your angular application, you could rely on the<br>
>>> servlet container and keycloak adapter to maintain a session<br>
>>> cookie and<br>
> identity.<br>
>>><br>
>>> What I like about the keycloak.js approach is that there is no<br>
>>> server-side adapter required for the UI. The UI could be<br>
>>> hosted<br>
> off any<br>
>>> number of static web sites and use CORS invocations to any<br>
>>> number of Restful services.<br>
>>><br>
>>> There's also the debate of public vs. confidential clients.<br>
>>> The keycloak.js approach requires a public client. My<br>
>>> understanding was that confidential clients exist so that only<br>
>>> an authenticated client (client *NOT* user) is able to obtain<br>
>>> an access token. I'm not<br>
> exactly<br>
>>> sure what additional security benefits are obtained here beyond<br>
>>> this. I've been trying to ask this very question on OAuth mail<br>
>>> lists<br>
> but have<br>
>>> been unable to get a response so far.<br>
>>><br>
>>><br>
>>><br>
>>> On 3/27/2014 10:41 AM, Nils Preusker wrote:<br>
>>>> Hi Stian and Bill,<br>
>>>><br>
>>>> I've posted some questions regarding this topic before but I<br>
> thought I'd<br>
>>>> start a new thread to keep things focused:<br>
>>>><br>
>>>> I'm writing an AngularJS application with Java EE 6/7 REST<br>
>>>> (JAX-RS) backend modules. To add authentication and<br>
>>>> authorization to this application, I'd like to use keycloak<br>
>>>><br>
>>>> * as a user and role management front-end * to provide a<br>
>>>> customizable login page (works very well by the<br>
> way ;)<br>
>>>> * as an OAuth 2.0 token provider * to add user and role<br>
>>>> information to the HTTPRequests in my REST/ backend modules<br>
>>>><br>
>>>> To do this, I'm currently looking at keycloak.js and the<br>
> customer-app-js<br>
>>>> example. However, I'm wondering whether this is really the<br>
>>>> best<br>
> way to<br>
>>>> go. In a reply to an earlier post of mine you mentioned that<br>
>>>> the keycloak admin console is written in AngularJS and that<br>
>>>> you are<br>
> using<br>
>>>> HTTP-only cookies there.<br>
>>>><br>
>>>> However, in keycloak.js and the customer-app-js example you<br>
>>>> are retrieving the token in the JS app and adding an<br>
>>>> authorization<br>
> header<br>
>>>> with a bearer token to the HTTP requests.<br>
>>>><br>
>>>> So here are my questions:<br>
>>>><br>
>>>> * Is there a reason you are using two different approaches<br>
>>>> in<br>
> the admin<br>
>>>> console and the official demo app? * which one of the two<br>
>>>> approaches (bearer tokens vs. HTTP-only<br>
> cookie)<br>
>>>> will you support/ will be the officially recommended one for<br>
>>>> HTML5/ client side JavaScript applications in keycloak? * am<br>
>>>> I right in assuming that you haven't quite decided yet which<br>
>>>> approach to use and that you are still discussing this in<br>
>>>> the<br>
> keycloak<br>
>>>> team?<br>
>>>><br>
>>>> Looking forwards to your reply! Cheers, Nils<br>
>>>><br>
>>>><br>
>>>> _______________________________________________ keycloak-user<br>
>>>> mailing list <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
</div></div>>>>> <mailto:<a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a>><br>
<div class="">>>>> <a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
>>>><br>
>>><br>
>>> -- Bill Burke JBoss, a division of Red Hat<br>
>>> <a href="http://bill.burkecentral.com" target="_blank">http://bill.burkecentral.com</a><br>
>>> _______________________________________________ keycloak-user<br>
>>> mailing list <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
</div>>>> <mailto:<a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a>><br>
<div class="">>>> <a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
>>><br>
><br>
> -- Bill Burke JBoss, a division of Red Hat<br>
> <a href="http://bill.burkecentral.com" target="_blank">http://bill.burkecentral.com</a><br>
><br>
><br>
> ------------------------------<br>
><br>
> _______________________________________________ keycloak-user<br>
> mailing list <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
</div>> <mailto:<a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a>><br>
<div class="">> <a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
><br>
> End of keycloak-user Digest, Vol 3, Issue 14<br>
> ********************************************<br>
><br>
><br>
><br>
><br>
</div><div class="">> _______________________________________________ keycloak-user<br>
> mailing list <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
><br>
</div>-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v2.0.22 (GNU/Linux)<br>
Comment: Using GnuPG with Thunderbird - <a href="http://www.enigmail.net/" target="_blank">http://www.enigmail.net/</a><br>
<br>
iQEcBAEBCgAGBQJTNSHcAAoJEDnJtskdmzLMHrYH/1D/vMgPxD0WUZ5KdIoD5Cow<br>
gb9fa+RZDQrpPxL1qKpqWJX3g1cKt8hQa1Xz7dX64G3/xcLUUkoJKkAtiJPysp75<br>
xbkdWV+RGQXDHuyZcS75xEXQlPaWt2cEVxdSXMalzfQPzVhq00FBbeJLirKLbYsY<br>
I2CIjJgCSQhmOrVfP5vUSdrwsLsd+TBXee4779YiOceSW16oG9Nfsa5gF1XJSNhi<br>
o2fZCEkoXhbTD7RXuhhrDWlFBCQOIgWf6FUHEAVKnXeIR5oey6U9hv1Z16Kd2Pll<br>
Pv8+LWlJjKMfkmrCQrVQvYSI/n64vxjikta2ByBdOPethsebqXO9oknbiPtjq6E=<br>
=TiWl<br>
-----END PGP SIGNATURE-----<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
keycloak-user mailing list<br>
<a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
</div></div></blockquote></div><br></div>