<div dir="ltr">Hi,<div><br></div><div>I was playing around with the examples, more specifically with the customer-portal-js which is accessing the database resource. In that CustomerService I was trying to get access to the Principal and trying to extend to return in addition the username of the logged-in user:</div>
<div><br></div><div><div>@Path("customers")</div><div>public class CustomerService {</div><div> </div><div> @Inject</div><div> Principal principal;</div><div> </div><div> //@Context</div><div> //SecurityContext sc;</div>
<div> //Principal principal = sc.getUserPrincipal();</div><div> </div><div> //@Context</div><div> //ContainerRequestContext request;</div><div> //SecurityContext sc = request.getSecurityContext();</div><div>
//Principal principal = sc.getUserPrincipal();</div><div><br></div><div> @GET</div><div> @Produces("application/json")</div><div> @NoCache</div><div> public List<String> getCustomers() {</div>
<div> ArrayList<String> rtn = new ArrayList<String>();<br></div><div> rtn.add("Bill Burke");</div><div> rtn.add("Stian Thorgersen");</div><div> rtn.add("Stan Silvert");</div>
<div> rtn.add("Gabriel Cardoso");</div><div> rtn.add("Viliam Rockai");</div><div> rtn.add("Marek Posolda");</div><div> rtn.add("Boleslaw Dawidowicz");</div>
<div> rtn.add(principal.getName()); //<--- add username to the list</div><div> return rtn;</div><div> }</div><div>}</div></div><div><br></div><div>But this throws a npe as the principal is always null. I noticed that the JaxrsBearerTokenFilter is adding to the ContainerRequestContext a new SecurityContex, of which the getUserPrincipal method returns the KeycloakPrincipal. But I can't figure out how to get access to this from the CustomerService.</div>
<div><br></div><div>My intention is to verify if the logged-in user is accessing his own resources, and e.g. is not trying to update data of somebody else. E.g. the id should match principal.getName() in following: </div>
<div><div><br></div><div>@POST</div><div>@Path("/users/{id}/friends")</div><div>public void addFriend(@PathParam("id") String userId, Friend friend) {</div><div> ...</div><div>}</div></div><div><br>
</div><div>Any suggestions? It would be nice if, beside the KeycloakPrincipal is injectable, to be able to define something like @IsOwner:</div><div><br></div><div>public void addFriend(@PathParam("id") @IsOwner String userId, Friend friend)</div>
<div><br></div><div>or even more concise:</div><div><br></div><div>public void addFriend(@IsOwner("id") String userId, Friend friend)</div><div><br></div><div>Kind regards,</div><div>Dirk Franssen</div><div><br>
</div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 27, 2014 at 5:29 PM, <span dir="ltr"><<a href="mailto:keycloak-user-request@lists.jboss.org" target="_blank">keycloak-user-request@lists.jboss.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Send keycloak-user mailing list submissions to<br>
<a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
<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><br>
or, via 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>
<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>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of keycloak-user digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: Keycloak and AngularJS (Bill Burke)<br>
2. Re: Keycloak and AngularJS (Stian Thorgersen)<br>
3. Re: Keycloak and AngularJS (Nils Preusker)<br>
4. Re: Keycloak and AngularJS (Bill Burke)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Thu, 27 Mar 2014 11:39:07 -0400<br>
From: Bill Burke <<a href="mailto:bburke@redhat.com">bburke@redhat.com</a>><br>
Subject: Re: [keycloak-user] Keycloak and AngularJS<br>
To: <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
Message-ID: <<a href="mailto:5334461B.8040202@redhat.com">5334461B.8040202@redhat.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed<br>
<br>
What I like about the current admin console approach is that there is no<br>
book keeping required by the browser. The Angular app has really no<br>
knowledge of how it is being secured as its all driven by the server.<br>
Also, you need to remember that the admin console was designed to be run<br>
in a non-Java EE, non-servlet environment. While this is a requirement<br>
for Keycloak, it may not be for your application. So, what I'm saying<br>
is that for your angular application, you could rely on the servlet<br>
container and keycloak 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 off any<br>
number of static web sites and use CORS invocations to any number of<br>
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 was<br>
that confidential clients exist so that only an authenticated client<br>
(client *NOT* user) is able to obtain an access token. I'm not exactly<br>
sure what additional security benefits are obtained here beyond this.<br>
I've been trying to ask this very question on OAuth mail lists 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 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 (JAX-RS)<br>
> backend modules. To add authentication and authorization to this<br>
> application, I'd like to use keycloak<br>
><br>
> * as a user and role management front-end<br>
> * to provide a customizable login page (works very well by the way ;)<br>
> * as an OAuth 2.0 token provider<br>
> * to add user and role information to the HTTPRequests in my REST/<br>
> backend modules<br>
><br>
> To do this, I'm currently looking at keycloak.js and the customer-app-js<br>
> example. However, I'm wondering whether this is really the best way to<br>
> go. In a reply to an earlier post of mine you mentioned that the<br>
> keycloak admin console is written in AngularJS and that you are using<br>
> 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 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 the admin<br>
> console and the official demo app?<br>
> * which one of the two approaches (bearer tokens vs. HTTP-only cookie)<br>
> will you support/ will be the officially recommended one for HTML5/<br>
> client side JavaScript applications in keycloak?<br>
> * am I right in assuming that you haven't quite decided yet which<br>
> approach to use and that you are still discussing this in the keycloak team?<br>
><br>
> Looking forwards to your reply!<br>
> Cheers,<br>
> Nils<br>
><br>
><br>
> _______________________________________________<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>
><br>
<br>
--<br>
Bill Burke<br>
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<br>
Date: Thu, 27 Mar 2014 12:18:01 -0400 (EDT)<br>
From: Stian Thorgersen <<a href="mailto:stian@redhat.com">stian@redhat.com</a>><br>
Subject: Re: [keycloak-user] Keycloak and AngularJS<br>
To: Bill Burke <<a href="mailto:bburke@redhat.com">bburke@redhat.com</a>><br>
Cc: <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
Message-ID:<br>
<<a href="mailto:884719116.3009607.1395937081146.JavaMail.zimbra@redhat.com">884719116.3009607.1395937081146.JavaMail.zimbra@redhat.com</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
Personally, I think that in most cases for a client-side web app the best approach is to let the client-side do the oauth flow (the approach we're currently taking in keycloak.js). It does depend on your application though, and if you're application has a strict one html5 app calls one REST service then http-only cookies are an option. I don't see any real benefits of it though, and I believe it significantly complicates things.<br>
<br>
Have a look at <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>, 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>
> To: <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
> Sent: Thursday, 27 March, 2014 3:39:07 PM<br>
> Subject: Re: [keycloak-user] Keycloak and AngularJS<br>
><br>
> What I like about the current admin console approach is that there is no<br>
> book keeping required by the browser. The Angular app has really no<br>
> knowledge of how it is being secured as its all driven by the server.<br>
> Also, you need to remember that the admin console was designed to be run<br>
> in a non-Java EE, non-servlet environment. While this is a requirement<br>
> for Keycloak, it may not be for your application. So, what I'm saying<br>
> is that for your angular application, you could rely on the servlet<br>
> container and keycloak 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 off any<br>
> number of static web sites and use CORS invocations to any number of<br>
> 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 was<br>
> that confidential clients exist so that only an authenticated client<br>
> (client *NOT* user) is able to obtain an access token. I'm not exactly<br>
> sure what additional security benefits are obtained here beyond this.<br>
> I've been trying to ask this very question on OAuth mail lists 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 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 (JAX-RS)<br>
> > backend modules. To add authentication and authorization to this<br>
> > application, I'd like to use keycloak<br>
> ><br>
> > * as a user and role management front-end<br>
> > * to provide a customizable login page (works very well by the way ;)<br>
> > * as an OAuth 2.0 token provider<br>
> > * to add user and role information to the HTTPRequests in my REST/<br>
> > backend modules<br>
> ><br>
> > To do this, I'm currently looking at keycloak.js and the customer-app-js<br>
> > example. However, I'm wondering whether this is really the best way to<br>
> > go. In a reply to an earlier post of mine you mentioned that the<br>
> > keycloak admin console is written in AngularJS and that you are using<br>
> > 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 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 the admin<br>
> > console and the official demo app?<br>
> > * which one of the two approaches (bearer tokens vs. HTTP-only cookie)<br>
> > will you support/ will be the officially recommended one for HTML5/<br>
> > client side JavaScript applications in keycloak?<br>
> > * am I right in assuming that you haven't quite decided yet which<br>
> > approach to use and that you are still discussing this in the keycloak<br>
> > team?<br>
> ><br>
> > Looking forwards to your reply!<br>
> > Cheers,<br>
> > Nils<br>
> ><br>
> ><br>
> > _______________________________________________<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>
> ><br>
><br>
> --<br>
> Bill Burke<br>
> JBoss, a division of Red Hat<br>
> <a href="http://bill.burkecentral.com" target="_blank">http://bill.burkecentral.com</a><br>
> _______________________________________________<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>
><br>
<br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Thu, 27 Mar 2014 17:24:06 +0100<br>
From: Nils Preusker <<a href="mailto:n.preusker@gmail.com">n.preusker@gmail.com</a>><br>
Subject: Re: [keycloak-user] Keycloak and AngularJS<br>
To: <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
Message-ID:<br>
<CA+HCLu_XG0xu+KUALgxoDuAMftA=<a href="mailto:rBgV-eFhwbDvaxq48NiOwQ@mail.gmail.com">rBgV-eFhwbDvaxq48NiOwQ@mail.gmail.com</a>><br>
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 approach<br>
with a web.xml and a keycloak.json in the backend for now. I'll keep you<br>
posted on what I end up with on the client side.<br>
<br>
Cheers,<br>
Nils<br>
<br>
<br>
<br>
On Thu, Mar 27, 2014 at 5:18 PM, Stian Thorgersen <<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 the best<br>
> approach is to let the client-side do the oauth flow (the approach we're<br>
> currently taking in keycloak.js). It does depend on your application<br>
> though, and if you're application has a strict one html5 app calls one REST<br>
> service then http-only cookies are an option. I don't see any real benefits<br>
> of it though, and I believe 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>
> 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>
> > To: <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
> > Sent: Thursday, 27 March, 2014 3:39:07 PM<br>
> > Subject: Re: [keycloak-user] Keycloak and AngularJS<br>
> ><br>
> > What I like about the current admin console approach is that there is no<br>
> > book keeping required by the browser. The Angular app has really no<br>
> > knowledge of how it is being secured as its all driven by the server.<br>
> > Also, you need to remember that the admin console was designed to be run<br>
> > in a non-Java EE, non-servlet environment. While this is a requirement<br>
> > for Keycloak, it may not be for your application. So, what I'm saying<br>
> > is that for your angular application, you could rely on the servlet<br>
> > container and keycloak 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 off any<br>
> > number of static web sites and use CORS invocations to any number of<br>
> > 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 was<br>
> > that confidential clients exist so that only an authenticated client<br>
> > (client *NOT* user) is able to obtain an access token. I'm not exactly<br>
> > sure what additional security benefits are obtained here beyond this.<br>
> > I've been trying to ask this very question on OAuth mail lists 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 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 (JAX-RS)<br>
> > > backend modules. To add authentication and authorization to this<br>
> > > application, I'd like to use keycloak<br>
> > ><br>
> > > * as a user and role management front-end<br>
> > > * to provide a customizable login page (works very well by the way ;)<br>
> > > * as an OAuth 2.0 token provider<br>
> > > * to add user and role information to the HTTPRequests in my REST/<br>
> > > 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 way to<br>
> > > go. In a reply to an earlier post of mine you mentioned that the<br>
> > > keycloak admin console is written in AngularJS and that you are using<br>
> > > 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 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 the admin<br>
> > > console and the official demo app?<br>
> > > * which one of the two approaches (bearer tokens vs. HTTP-only cookie)<br>
> > > will you support/ will be the officially recommended one for HTML5/<br>
> > > client side JavaScript applications in keycloak?<br>
> > > * am I right in assuming that you haven't quite decided yet which<br>
> > > approach to use and that you are still discussing this in the keycloak<br>
> > > team?<br>
> > ><br>
> > > Looking forwards to your reply!<br>
> > > Cheers,<br>
> > > Nils<br>
> > ><br>
> > ><br>
> > > _______________________________________________<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>
> > ><br>
> ><br>
> > --<br>
> > Bill Burke<br>
> > JBoss, a division of Red Hat<br>
> > <a href="http://bill.burkecentral.com" target="_blank">http://bill.burkecentral.com</a><br>
> > _______________________________________________<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>
> ><br>
> _______________________________________________<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>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <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<br>
Date: Thu, 27 Mar 2014 12:29:54 -0400<br>
From: Bill Burke <<a href="mailto:bburke@redhat.com">bburke@redhat.com</a>><br>
Subject: Re: [keycloak-user] Keycloak and AngularJS<br>
To: Stian Thorgersen <<a href="mailto:stian@redhat.com">stian@redhat.com</a>><br>
Cc: <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
Message-ID: <<a href="mailto:53345202.4060105@redhat.com">53345202.4060105@redhat.com</a>><br>
Content-Type: text/plain; charset=UTF-8; format=flowed<br>
<br>
One of the problems with the keycloak.js approach is that we have no way<br>
to perform a single log out or to force a logout of a specific user. I<br>
think the OpenID Connect spec may have a way with IFrames to do this<br>
sort of thing though. I didn't really get it at 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 the best approach is to let the client-side do the oauth flow (the approach we're currently taking in keycloak.js). It does depend on your application though, and if you're application has a strict one html5 app calls one REST service then http-only cookies are an option. I don't see any real benefits of it though, and I believe it significantly complicates things.<br>
><br>
> Have a look at <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>, 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>
>> To: <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
>> Sent: Thursday, 27 March, 2014 3:39:07 PM<br>
>> Subject: Re: [keycloak-user] Keycloak and AngularJS<br>
>><br>
>> What I like about the current admin console approach is that there is no<br>
>> book keeping required by the browser. The Angular app has really no<br>
>> knowledge of how it is being secured as its all driven by the server.<br>
>> Also, you need to remember that the admin console was designed to be run<br>
>> in a non-Java EE, non-servlet environment. While this is a requirement<br>
>> for Keycloak, it may not be for your application. So, what I'm saying<br>
>> is that for your angular application, you could rely on the servlet<br>
>> container and keycloak 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 off any<br>
>> number of static web sites and use CORS invocations to any number of<br>
>> 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 was<br>
>> that confidential clients exist so that only an authenticated client<br>
>> (client *NOT* user) is able to obtain an access token. I'm not exactly<br>
>> sure what additional security benefits are obtained here beyond this.<br>
>> I've been trying to ask this very question on OAuth mail lists 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 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 (JAX-RS)<br>
>>> backend modules. To add authentication and authorization to this<br>
>>> application, I'd like to use keycloak<br>
>>><br>
>>> * as a user and role management front-end<br>
>>> * to provide a customizable login page (works very well by the way ;)<br>
>>> * as an OAuth 2.0 token provider<br>
>>> * to add user and role information to the HTTPRequests in my REST/<br>
>>> backend modules<br>
>>><br>
>>> To do this, I'm currently looking at keycloak.js and the customer-app-js<br>
>>> example. However, I'm wondering whether this is really the best way to<br>
>>> go. In a reply to an earlier post of mine you mentioned that the<br>
>>> keycloak admin console is written in AngularJS and that you are using<br>
>>> 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 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 the admin<br>
>>> console and the official demo app?<br>
>>> * which one of the two approaches (bearer tokens vs. HTTP-only cookie)<br>
>>> will you support/ will be the officially recommended one for HTML5/<br>
>>> client side JavaScript applications in keycloak?<br>
>>> * am I right in assuming that you haven't quite decided yet which<br>
>>> approach to use and that you are still discussing this in the keycloak<br>
>>> team?<br>
>>><br>
>>> Looking forwards to your reply!<br>
>>> Cheers,<br>
>>> Nils<br>
>>><br>
>>><br>
>>> _______________________________________________<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>
>>><br>
>><br>
>> --<br>
>> Bill Burke<br>
>> JBoss, a division of Red Hat<br>
>> <a href="http://bill.burkecentral.com" target="_blank">http://bill.burkecentral.com</a><br>
>> _______________________________________________<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>
>><br>
<br>
--<br>
Bill Burke<br>
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>
_______________________________________________<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>
<br>
End of keycloak-user Digest, Vol 3, Issue 14<br>
********************************************<br>
</blockquote></div><br></div></div></div>