Send keycloak-user mailing list submissions to keycloak-user(a)lists.jboss.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.jboss.org/mailman/listinfo/keycloak-user or, via email, send a message with subject or body 'help' to keycloak-user-request(a)lists.jboss.org You can reach the person managing the list at keycloak-user-owner(a)lists.jboss.org When replying, please edit your Subject line so it is more specific than "Re: Contents of keycloak-user digest..." Today's Topics: 1. Re: Inject (Keycloak)Principal (Nils Preusker) ---------------------------------------------------------------------- Message: 1 Date: Fri, 28 Mar 2014 17:14:03 +0100 From: Nils Preusker <n.preusker(a)gmail.com&gt; Subject: Re: [keycloak-user] Inject (Keycloak)Principal To: keycloak-user(a)lists.jboss.org Message-ID: <CA+HCLu-cCPaeZ2mKAJXUOcvt5JMPnMOMNXzSbqegUm6PW=- EUQ(a)mail.gmail.com&gt; Content-Type: text/plain; charset="iso-8859-1" Cheers Bill, I added KeycloakSecurityContext ctx = (KeycloakSecurityContext) servletRequest.getAttribute(KeycloakSecurityContext.class.getName()); and can now access the user name via ctx.getToken().getPreferredUsername(). The only downside to this is that I now need keycloak in my dependencies in irder to know the class KeycloakSecurityContext, but I guess I can live with that :) Thanks again! Nils On Fri, Mar 28, 2014 at 4:57 PM, Bill Burke <bburke(a)redhat.com&gt; wrote: > The KeycloakSecurityContext has access to the IDToken which can contain > information like name, email, address, etc... Depending on how you > configure your realm. Maybe IDToken should be added to the > KeycloakPrincipal? > > On 3/28/2014 11:47 AM, Stian Thorgersen wrote: > > Yes that is expected behaviour. The ID of the user is the unique > reference to a user within Keycloak, and is what we recommend you use to > refer to the user within your application when possible. The reason being > is that there are reasons why a username/email may not refer to the same > user over time. For example we will allow users to change their username (a > feature you'll be able to disable), a user may be deleted, and another user > re-created with the same username. > > > > ----- Original Message ----- > >> From: "Nils Preusker" <n.preusker(a)gmail.com&gt; > >> To: keycloak-user(a)lists.jboss.org > >> Sent: Friday, 28 March, 2014 3:17:37 PM > >> Subject: Re: [keycloak-user] Inject (Keycloak)Principal > >> > >> Hi all, > >> > >> 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). > >> > >> Is this the expected/ intended behavior? > >> > >> Also, @Dirk: let me know if you need any help getting the injection of > the > >> roles and user id to work. > >> > >> Cheers, > >> Nils > >> > >> > >> On Fri, Mar 28, 2014 at 8:16 AM, Juraci Paix?o Kr?hling < > juraci(a)kroehling.de > >>> wrote: > >> > >> > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA512 > >> > >> Dirk, > >> > >> It seems it's missing the @SecurityDomain("keycloak") in your service, > >> at the type level. If that's not the case, I can update the > >> "sample-ejb-roles" quickstart, adapted to use Keycloak, so you can > >> compare and check what's missing. > >> > >> Just to confirm: have you also added the security-domain to the > >> standalone.xml? The instructions are at the end of section 6.2.1 from > >> the user guide: > >> > >> > http://docs.jboss.org/keycloak/docs/1.0-alpha-3/userguide/html_single/ind... > >> > >> Juca. > >> > >> On 03/28/2014 01:31 AM, Dirk Franssen wrote: > >>> Hi, > >>> > >>> 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: > >>> > >>> @Path("customers") public class CustomerService { > >>> > >>> @Inject Principal principal; > >>> > >>> //@Context //SecurityContext sc; //Principal principal = > >>> sc.getUserPrincipal(); > >>> > >>> //@Context //ContainerRequestContext request; //SecurityContext sc > >>> = request.getSecurityContext(); //Principal principal = > >>> sc.getUserPrincipal(); > >>> > >>> @GET @Produces("application/json") @NoCache public List<String> > >>> getCustomers() { ArrayList<String> rtn = new ArrayList<String>(); > >>> rtn.add("Bill Burke"); rtn.add("Stian Thorgersen"); rtn.add("Stan > >>> Silvert"); rtn.add("Gabriel Cardoso"); rtn.add("Viliam Rockai"); > >>> rtn.add("Marek Posolda"); rtn.add("Boleslaw Dawidowicz"); > >>> rtn.add(principal.getName()); //<--- add username to the list > >>> return rtn; } } > >>> > >>> 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. > >>> > >>> 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: > >>> > >>> @POST @Path("/users/{id}/friends") public void > >>> addFriend(@PathParam("id") String userId, Friend friend) { ... } > >>> > >>> Any suggestions? It would be nice if, beside the KeycloakPrincipal > >>> is injectable, to be able to define something like @IsOwner: > >>> > >>> public void addFriend(@PathParam("id") @IsOwner String userId, > >>> Friend friend) > >>> > >>> or even more concise: > >>> > >>> public void addFriend(@IsOwner("id") String userId, Friend friend) > >>> > >>> Kind regards, Dirk Franssen > >>> > >>> > >>> On Thu, Mar 27, 2014 at 5:29 PM, > >>> < keycloak-user-request(a)lists.jboss.org > >>> <mailto: keycloak-user-request(a)lists.jboss.org >> wrote: > >>> > >>> Send keycloak-user mailing list submissions to > >>> keycloak-user(a)lists.jboss.org > >>> <mailto: keycloak-user(a)lists.jboss.org > > >>> > >>> To subscribe or unsubscribe via the World Wide Web, visit > >>> https://lists.jboss.org/mailman/listinfo/keycloak-user or, via > >>> email, send a message with subject or body 'help' to > >>> keycloak-user-request(a)lists.jboss.org > >>> <mailto: keycloak-user-request(a)lists.jboss.org > > >>> > >>> You can reach the person managing the list at > >>> keycloak-user-owner(a)lists.jboss.org > >>> <mailto: keycloak-user-owner(a)lists.jboss.org > > >>> > >>> When replying, please edit your Subject line so it is more > >>> specific than "Re: Contents of keycloak-user digest..." > >>> > >>> > >>> Today's Topics: > >>> > >>> 1. Re: Keycloak and AngularJS (Bill Burke) 2. Re: Keycloak and > >>> AngularJS (Stian Thorgersen) 3. Re: Keycloak and AngularJS (Nils > >>> Preusker) 4. Re: Keycloak and AngularJS (Bill Burke) > >>> > >>> > >>> ---------------------------------------------------------------------- > >>> > >>> Message: 1 Date: Thu, 27 Mar 2014 11:39:07 -0400 From: Bill Burke > >>> < bburke(a)redhat.com <mailto: bburke(a)redhat.com >> Subject: Re: > >>> [keycloak-user] Keycloak and AngularJS To: > >>> keycloak-user(a)lists.jboss.org > >>> <mailto: keycloak-user(a)lists.jboss.org > Message-ID: > >>> < 5334461B.8040202(a)redhat.com <mailto: 5334461B.8040202(a)redhat.com&gt;&gt; > >>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed > >>> > >>> What I like about the current admin console approach is that there > >>> is no book keeping required by the browser. The Angular app has > >>> really no knowledge of how it is being secured as its all driven by > >>> the server. Also, you need to remember that the admin console was > >>> designed to be run in a non-Java EE, non-servlet environment. > >>> While this is a requirement for Keycloak, it may not be for your > >>> application. So, what I'm saying is that for your angular > >>> application, you could rely on the servlet container and keycloak > >>> adapter to maintain a session cookie and identity. > >>> > >>> What I like about the keycloak.js approach is that there is no > >>> server-side adapter required for the UI. The UI could be hosted > >>> off any number of static web sites and use CORS invocations to any > >>> number of Restful services. > >>> > >>> There's also the debate of public vs. confidential clients. The > >>> keycloak.js approach requires a public client. My understanding > >>> was that confidential clients exist so that only an authenticated > >>> client (client *NOT* user) is able to obtain an access token. I'm > >>> not exactly sure what additional security benefits are obtained > >>> here beyond this. I've been trying to ask this very question on > >>> OAuth mail lists but have been unable to get a response so far. > >>> > >>> > >>> > >>> On 3/27/2014 10:41 AM, Nils Preusker wrote: > >>>> Hi Stian and Bill, > >>>> > >>>> I've posted some questions regarding this topic before but I > >>> thought I'd > >>>> start a new thread to keep things focused: > >>>> > >>>> I'm writing an AngularJS application with Java EE 6/7 REST > >>>> (JAX-RS) backend modules. To add authentication and authorization > >>>> to this application, I'd like to use keycloak > >>>> > >>>> * as a user and role management front-end * to provide a > >>>> customizable login page (works very well by the way ;) * as an > >>>> OAuth 2.0 token provider * to add user and role information to > >>>> the HTTPRequests in my REST/ backend modules > >>>> > >>>> To do this, I'm currently looking at keycloak.js and the > >>> customer-app-js > >>>> example. However, I'm wondering whether this is really the best > >>>> way to go. In a reply to an earlier post of mine you mentioned > >>>> that the keycloak admin console is written in AngularJS and that > >>>> you are using HTTP-only cookies there. > >>>> > >>>> However, in keycloak.js and the customer-app-js example you are > >>>> retrieving the token in the JS app and adding an authorization > >>>> header with a bearer token to the HTTP requests. > >>>> > >>>> So here are my questions: > >>>> > >>>> * Is there a reason you are using two different approaches in > >>>> the > >>> admin > >>>> console and the official demo app? * which one of the two > >>>> approaches (bearer tokens vs. HTTP-only cookie) will you support/ > >>>> will be the officially recommended one for HTML5/ client side > >>>> JavaScript applications in keycloak? * am I right in assuming > >>>> that you haven't quite decided yet which approach to use and that > >>>> you are still discussing this in the > >>> keycloak team? > >>>> > >>>> Looking forwards to your reply! Cheers, Nils > >>>> > >>>> > >>>> _______________________________________________ keycloak-user > >>>> mailing list keycloak-user(a)lists.jboss.org > >>>> <mailto: keycloak-user(a)lists.jboss.org > > >>>> https://lists.jboss.org/mailman/listinfo/keycloak-user > >>>> > >>> > >>> -- Bill Burke JBoss, a division of Red Hat > >>> http://bill.burkecentral.com > >>> > >>> > >>> ------------------------------ > >>> > >>> Message: 2 Date: Thu, 27 Mar 2014 12:18:01 -0400 (EDT) From: Stian > >>> Thorgersen < stian(a)redhat.com <mailto: stian(a)redhat.com >> Subject: > >>> Re: [keycloak-user] Keycloak and AngularJS To: Bill Burke > >>> < bburke(a)redhat.com <mailto: bburke(a)redhat.com >> Cc: > >>> keycloak-user(a)lists.jboss.org > >>> <mailto: keycloak-user(a)lists.jboss.org > Message-ID: > >>> < 884719116.3009607.1395937081146.JavaMail.zimbra(a)redhat.com > >>> <mailto: 884719116.3009607.1395937081146.JavaMail.zimbra(a)redhat.com&gt;&gt; > >>> > >>> > >> Content-Type: text/plain; charset=utf-8 > >>> > >>> 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. > >>> > >>> Have a look at > >>> > http://blog.auth0.com/2014/01/07/angularjs-authentication-with-cookies-vs... > >>> , > >>> > >>> > >> I think it provides a good summary of the pros of the token approach. > >>> > >>> ----- Original Message ----- > >>>> From: "Bill Burke" < bburke(a)redhat.com > >>>> <mailto: bburke(a)redhat.com >> To: keycloak-user(a)lists.jboss.org > >>> <mailto: keycloak-user(a)lists.jboss.org > > >>>> Sent: Thursday, 27 March, 2014 3:39:07 PM Subject: Re: > >>>> [keycloak-user] Keycloak and AngularJS > >>>> > >>>> What I like about the current admin console approach is that > >>>> there > >>> is no > >>>> book keeping required by the browser. The Angular app has really > >>>> no knowledge of how it is being secured as its all driven by the > >>>> server. Also, you need to remember that the admin console was > >>>> designed to > >>> be run > >>>> in a non-Java EE, non-servlet environment. While this is a > >>> requirement > >>>> for Keycloak, it may not be for your application. So, what I'm > >>>> saying is that for your angular application, you could rely on > >>>> the servlet container and keycloak adapter to maintain a session > >>>> cookie and > >>> identity. > >>>> > >>>> What I like about the keycloak.js approach is that there is no > >>>> server-side adapter required for the UI. The UI could be hosted > >>> off any > >>>> number of static web sites and use CORS invocations to any number > >>>> of Restful services. > >>>> > >>>> There's also the debate of public vs. confidential clients. The > >>>> keycloak.js approach requires a public client. My understanding > >>>> was that confidential clients exist so that only an authenticated > >>>> client (client *NOT* user) is able to obtain an access token. > >>>> I'm not > >>> exactly > >>>> sure what additional security benefits are obtained here beyond > >>>> this. I've been trying to ask this very question on OAuth mail > >>>> lists but > >>> have > >>>> been unable to get a response so far. > >>>> > >>>> > >>>> > >>>> On 3/27/2014 10:41 AM, Nils Preusker wrote: > >>>>> Hi Stian and Bill, > >>>>> > >>>>> I've posted some questions regarding this topic before but I > >>> thought I'd > >>>>> start a new thread to keep things focused: > >>>>> > >>>>> I'm writing an AngularJS application with Java EE 6/7 REST > >>>>> (JAX-RS) backend modules. To add authentication and > >>>>> authorization to this application, I'd like to use keycloak > >>>>> > >>>>> * as a user and role management front-end * to provide a > >>>>> customizable login page (works very well by the > >>> way ;) > >>>>> * as an OAuth 2.0 token provider * to add user and role > >>>>> information to the HTTPRequests in my REST/ backend modules > >>>>> > >>>>> To do this, I'm currently looking at keycloak.js and the > >>> customer-app-js > >>>>> example. However, I'm wondering whether this is really the > >>>>> best > >>> way to > >>>>> go. In a reply to an earlier post of mine you mentioned that > >>>>> the keycloak admin console is written in AngularJS and that you > >>>>> are > >>> using > >>>>> HTTP-only cookies there. > >>>>> > >>>>> However, in keycloak.js and the customer-app-js example you > >>>>> are retrieving the token in the JS app and adding an > >>>>> authorization > >>> header > >>>>> with a bearer token to the HTTP requests. > >>>>> > >>>>> So here are my questions: > >>>>> > >>>>> * Is there a reason you are using two different approaches in > >>> the admin > >>>>> console and the official demo app? * which one of the two > >>>>> approaches (bearer tokens vs. HTTP-only > >>> cookie) > >>>>> will you support/ will be the officially recommended one for > >>>>> HTML5/ client side JavaScript applications in keycloak? * am I > >>>>> right in assuming that you haven't quite decided yet which > >>>>> approach to use and that you are still discussing this in the > >>> keycloak > >>>>> team? > >>>>> > >>>>> Looking forwards to your reply! Cheers, Nils > >>>>> > >>>>> > >>>>> _______________________________________________ keycloak-user > >>>>> mailing list keycloak-user(a)lists.jboss.org > >>>>> <mailto: keycloak-user(a)lists.jboss.org > > >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user > >>>>> > >>>> > >>>> -- Bill Burke JBoss, a division of Red Hat > >>>> http://bill.burkecentral.com > >>>> _______________________________________________ keycloak-user > >>>> mailing list keycloak-user(a)lists.jboss.org > >>>> <mailto: keycloak-user(a)lists.jboss.org > > >>>> https://lists.jboss.org/mailman/listinfo/keycloak-user > >>>> > >>> > >>> > >>> ------------------------------ > >>> > >>> Message: 3 Date: Thu, 27 Mar 2014 17:24:06 +0100 From: Nils > >>> Preusker < n.preusker(a)gmail.com <mailto: n.preusker(a)gmail.com >> > >>> Subject: Re: [keycloak-user] Keycloak and AngularJS To: > >>> keycloak-user(a)lists.jboss.org > >>> <mailto: keycloak-user(a)lists.jboss.org > Message-ID: > >>> > >>> <CA+HCLu_XG0xu+KUALgxoDuAMftA= rBgV-eFhwbDvaxq48NiOwQ(a)mail.gmail.com > >>> > >>> > >> <mailto: rBgV-eFhwbDvaxq48NiOwQ(a)mail.gmail.com >> > >>> Content-Type: text/plain; charset="iso-8859-1" > >>> > >>> Hi Stian and Bill, > >>> > >>> thanks for your replies! I'll check out the blog post and try the > >>> approach with a web.xml and a keycloak.json in the backend for now. > >>> I'll keep you posted on what I end up with on the client side. > >>> > >>> Cheers, Nils > >>> > >>> > >>> > >>> On Thu, Mar 27, 2014 at 5:18 PM, Stian Thorgersen > >>> < stian(a)redhat.com <mailto: stian(a)redhat.com >> wrote: > >>> > >>>> 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. > >>>> > >>>> Have a look at > >>>> > >>> > http://blog.auth0.com/2014/01/07/angularjs-authentication-with-cookies-vs... > >>> , > >>> > >>> I think it provides a good summary of the pros of the token > >>> approach. > >>>> > >>>> ----- Original Message ----- > >>>>> From: "Bill Burke" < bburke(a)redhat.com > >>>>> <mailto: bburke(a)redhat.com >> To: keycloak-user(a)lists.jboss.org > >>> <mailto: keycloak-user(a)lists.jboss.org > > >>>>> Sent: Thursday, 27 March, 2014 3:39:07 PM Subject: Re: > >>>>> [keycloak-user] Keycloak and AngularJS > >>>>> > >>>>> What I like about the current admin console approach is that > >>> there is no > >>>>> book keeping required by the browser. The Angular app has > >>>>> really no knowledge of how it is being secured as its all > >>>>> driven by the > >>> server. > >>>>> Also, you need to remember that the admin console was designed > >>> to be run > >>>>> in a non-Java EE, non-servlet environment. While this is a > >>> requirement > >>>>> for Keycloak, it may not be for your application. So, what > >>>>> I'm > >>> saying > >>>>> is that for your angular application, you could rely on the > >>>>> servlet container and keycloak adapter to maintain a session > >>>>> cookie and > >>> identity. > >>>>> > >>>>> What I like about the keycloak.js approach is that there is no > >>>>> server-side adapter required for the UI. The UI could be > >>>>> hosted > >>> off any > >>>>> number of static web sites and use CORS invocations to any > >>>>> number of Restful services. > >>>>> > >>>>> There's also the debate of public vs. confidential clients. > >>>>> The keycloak.js approach requires a public client. My > >>>>> understanding was that confidential clients exist so that only > >>>>> an authenticated client (client *NOT* user) is able to obtain > >>>>> an access token. I'm not > >>> exactly > >>>>> sure what additional security benefits are obtained here > >>>>> beyond > >>> this. > >>>>> I've been trying to ask this very question on OAuth mail lists > >>> but have > >>>>> been unable to get a response so far. > >>>>> > >>>>> > >>>>> > >>>>> On 3/27/2014 10:41 AM, Nils Preusker wrote: > >>>>>> Hi Stian and Bill, > >>>>>> > >>>>>> I've posted some questions regarding this topic before but I > >>> thought > >>>> I'd > >>>>>> start a new thread to keep things focused: > >>>>>> > >>>>>> I'm writing an AngularJS application with Java EE 6/7 REST > >>> (JAX-RS) > >>>>>> backend modules. To add authentication and authorization to > >>>>>> this application, I'd like to use keycloak > >>>>>> > >>>>>> * as a user and role management front-end * to provide a > >>>>>> customizable login page (works very well by the > >>> way ;) > >>>>>> * as an OAuth 2.0 token provider * to add user and role > >>>>>> information to the HTTPRequests in my REST/ backend modules > >>>>>> > >>>>>> To do this, I'm currently looking at keycloak.js and the > >>>> customer-app-js > >>>>>> example. However, I'm wondering whether this is really the > >>> best way to > >>>>>> go. In a reply to an earlier post of mine you mentioned that > >>>>>> the keycloak admin console is written in AngularJS and that > >>>>>> you > >>> are using > >>>>>> HTTP-only cookies there. > >>>>>> > >>>>>> However, in keycloak.js and the customer-app-js example you > >>>>>> are retrieving the token in the JS app and adding an > >>>>>> authorization > >>> header > >>>>>> with a bearer token to the HTTP requests. > >>>>>> > >>>>>> So here are my questions: > >>>>>> > >>>>>> * Is there a reason you are using two different approaches > >>>>>> in > >>> the admin > >>>>>> console and the official demo app? * which one of the two > >>>>>> approaches (bearer tokens vs. HTTP-only > >>> cookie) > >>>>>> will you support/ will be the officially recommended one for > >>> HTML5/ > >>>>>> client side JavaScript applications in keycloak? * am I right > >>>>>> in assuming that you haven't quite decided yet which approach > >>>>>> to use and that you are still discussing this in the > >>> keycloak > >>>>>> team? > >>>>>> > >>>>>> Looking forwards to your reply! Cheers, Nils > >>>>>> > >>>>>> > >>>>>> _______________________________________________ keycloak-user > >>>>>> mailing list keycloak-user(a)lists.jboss.org > >>> <mailto: keycloak-user(a)lists.jboss.org > > >>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user > >>>>>> > >>>>> > >>>>> -- Bill Burke JBoss, a division of Red Hat > >>>>> http://bill.burkecentral.com > >>>>> _______________________________________________ keycloak-user > >>>>> mailing list keycloak-user(a)lists.jboss.org > >>>>> <mailto: keycloak-user(a)lists.jboss.org > > >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user > >>>>> > >>>> _______________________________________________ keycloak-user > >>>> mailing list keycloak-user(a)lists.jboss.org > >>>> <mailto: keycloak-user(a)lists.jboss.org > > >>>> https://lists.jboss.org/mailman/listinfo/keycloak-user > >>>> > >>> -------------- next part -------------- An HTML attachment was > >>> scrubbed... URL: > >>> > http://lists.jboss.org/pipermail/keycloak-user/attachments/20140327/b8e5e... > >>> > >>> ------------------------------ > >>> > >>> Message: 4 Date: Thu, 27 Mar 2014 12:29:54 -0400 From: Bill Burke > >>> < bburke(a)redhat.com <mailto: bburke(a)redhat.com >> Subject: Re: > >>> [keycloak-user] Keycloak and AngularJS To: Stian Thorgersen > >>> < stian(a)redhat.com <mailto: stian(a)redhat.com >> Cc: > >>> keycloak-user(a)lists.jboss.org > >>> <mailto: keycloak-user(a)lists.jboss.org > Message-ID: > >>> < 53345202.4060105(a)redhat.com <mailto: 53345202.4060105(a)redhat.com&gt;&gt; > >>> Content-Type: text/plain; charset=UTF-8; format=flowed > >>> > >>> One of the problems with the keycloak.js approach is that we have > >>> no way to perform a single log out or to force a logout of a > >>> specific user. I think the OpenID Connect spec may have a way with > >>> IFrames to do this sort of thing though. I didn't really get it at > >>> first glance though. > >>> > >>> > >>> On 3/27/2014 12:18 PM, Stian Thorgersen wrote: > >>>> 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. > >>>> > >>>> Have a look at > >>> > http://blog.auth0.com/2014/01/07/angularjs-authentication-with-cookies-vs... > >>> , > >>> > >>> > >> I think it provides a good summary of the pros of the token approach. > >>>> > >>>> ----- Original Message ----- > >>>>> From: "Bill Burke" < bburke(a)redhat.com > >>>>> <mailto: bburke(a)redhat.com >> To: keycloak-user(a)lists.jboss.org > >>> <mailto: keycloak-user(a)lists.jboss.org > > >>>>> Sent: Thursday, 27 March, 2014 3:39:07 PM Subject: Re: > >>>>> [keycloak-user] Keycloak and AngularJS > >>>>> > >>>>> What I like about the current admin console approach is that > >>> there is no > >>>>> book keeping required by the browser. The Angular app has > >>>>> really no knowledge of how it is being secured as its all > >>>>> driven by the server. Also, you need to remember that the admin > >>>>> console was designed to > >>> be run > >>>>> in a non-Java EE, non-servlet environment. While this is a > >>> requirement > >>>>> for Keycloak, it may not be for your application. So, what > >>>>> I'm > >>> saying > >>>>> is that for your angular application, you could rely on the > >>>>> servlet container and keycloak adapter to maintain a session > >>>>> cookie and > >>> identity. > >>>>> > >>>>> What I like about the keycloak.js approach is that there is no > >>>>> server-side adapter required for the UI. The UI could be > >>>>> hosted > >>> off any > >>>>> number of static web sites and use CORS invocations to any > >>>>> number of Restful services. > >>>>> > >>>>> There's also the debate of public vs. confidential clients. > >>>>> The keycloak.js approach requires a public client. My > >>>>> understanding was that confidential clients exist so that only > >>>>> an authenticated client (client *NOT* user) is able to obtain > >>>>> an access token. I'm not > >>> exactly > >>>>> sure what additional security benefits are obtained here beyond > >>>>> this. I've been trying to ask this very question on OAuth mail > >>>>> lists > >>> but have > >>>>> been unable to get a response so far. > >>>>> > >>>>> > >>>>> > >>>>> On 3/27/2014 10:41 AM, Nils Preusker wrote: > >>>>>> Hi Stian and Bill, > >>>>>> > >>>>>> I've posted some questions regarding this topic before but I > >>> thought I'd > >>>>>> start a new thread to keep things focused: > >>>>>> > >>>>>> I'm writing an AngularJS application with Java EE 6/7 REST > >>>>>> (JAX-RS) backend modules. To add authentication and > >>>>>> authorization to this application, I'd like to use keycloak > >>>>>> > >>>>>> * as a user and role management front-end * to provide a > >>>>>> customizable login page (works very well by the > >>> way ;) > >>>>>> * as an OAuth 2.0 token provider * to add user and role > >>>>>> information to the HTTPRequests in my REST/ backend modules > >>>>>> > >>>>>> To do this, I'm currently looking at keycloak.js and the > >>> customer-app-js > >>>>>> example. However, I'm wondering whether this is really the > >>>>>> best > >>> way to > >>>>>> go. In a reply to an earlier post of mine you mentioned that > >>>>>> the keycloak admin console is written in AngularJS and that > >>>>>> you are > >>> using > >>>>>> HTTP-only cookies there. > >>>>>> > >>>>>> However, in keycloak.js and the customer-app-js example you > >>>>>> are retrieving the token in the JS app and adding an > >>>>>> authorization > >>> header > >>>>>> with a bearer token to the HTTP requests. > >>>>>> > >>>>>> So here are my questions: > >>>>>> > >>>>>> * Is there a reason you are using two different approaches > >>>>>> in > >>> the admin > >>>>>> console and the official demo app? * which one of the two > >>>>>> approaches (bearer tokens vs. HTTP-only > >>> cookie) > >>>>>> will you support/ will be the officially recommended one for > >>>>>> HTML5/ client side JavaScript applications in keycloak? * am > >>>>>> I right in assuming that you haven't quite decided yet which > >>>>>> approach to use and that you are still discussing this in > >>>>>> the > >>> keycloak > >>>>>> team? > >>>>>> > >>>>>> Looking forwards to your reply! Cheers, Nils > >>>>>> > >>>>>> > >>>>>> _______________________________________________ keycloak-user > >>>>>> mailing list keycloak-user(a)lists.jboss.org > >>>>>> <mailto: keycloak-user(a)lists.jboss.org > > >>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user > >>>>>> > >>>>> > >>>>> -- Bill Burke JBoss, a division of Red Hat > >>>>> http://bill.burkecentral.com > >>>>> _______________________________________________ keycloak-user > >>>>> mailing list keycloak-user(a)lists.jboss.org > >>>>> <mailto: keycloak-user(a)lists.jboss.org > > >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user > >>>>> > >>> > >>> -- Bill Burke JBoss, a division of Red Hat > >>> http://bill.burkecentral.com > >>> > >>> > >>> ------------------------------ > >>> > >>> _______________________________________________ keycloak-user > >>> mailing list keycloak-user(a)lists.jboss.org > >>> <mailto: keycloak-user(a)lists.jboss.org > > >>> https://lists.jboss.org/mailman/listinfo/keycloak-user > >>> > >>> End of keycloak-user Digest, Vol 3, Issue 14 > >>> ******************************************** > >>> > >>> > >>> > >>> > >>> _______________________________________________ keycloak-user > >>> mailing list keycloak-user(a)lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/keycloak-user > >>> > >> _______________________________________________ > >> keycloak-user mailing list > >> keycloak-user(a)lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-user > >> > >> > >> _______________________________________________ > >> keycloak-user mailing list > >> keycloak-user(a)lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > _______________________________________________ > > keycloak-user mailing list > > keycloak-user(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-user mailing list > keycloak-user(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20140328/d14cb... ------------------------------ _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user End of keycloak-user Digest, Vol 3, Issue 21 ********************************************