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 <mailto:juraci@kroehling.de>> wrote: 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@lists.jboss.org> > <mailto:keycloak-user-request@lists.jboss.org <mailto:keycloak-user-request@lists.jboss.org>>> wrote: > Send keycloak-user mailing list submissions to > keycloak-user(a)lists.jboss.org > <mailto:keycloak-user@lists.jboss.org> > <mailto:keycloak-user@lists.jboss.org <mailto:keycloak-user@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@lists.jboss.org> > <mailto:keycloak-user-request@lists.jboss.org <mailto:keycloak-user-request@lists.jboss.org>> > You can reach the person managing the list at > keycloak-user-owner(a)lists.jboss.org <mailto:keycloak-user-owner@lists.jboss.org> > <mailto:keycloak-user-owner@lists.jboss.org <mailto:keycloak-user-owner@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@redhat.com> <mailto:bburke@redhat.com <mailto:bburke@redhat.com>>> Subject: Re: > [keycloak-user] Keycloak and AngularJS To: > keycloak-user(a)lists.jboss.org > <mailto:keycloak-user@lists.jboss.org> > <mailto:keycloak-user@lists.jboss.org <mailto:keycloak-user@lists.jboss.org>> Message-ID: > <5334461B.8040202(a)redhat.com > <mailto:5334461B.8040202@redhat.com> <mailto:5334461B.8040202@redhat.com <mailto:5334461B.8040202@redhat.com>>> > 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@lists.jboss.org> >> <mailto:keycloak-user@lists.jboss.org <mailto:keycloak-user@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@redhat.com> <mailto:stian@redhat.com <mailto:stian@redhat.com>>> Subject: > Re: [keycloak-user] Keycloak and AngularJS To: Bill Burke > <bburke(a)redhat.com <mailto:bburke@redhat.com> <mailto:bburke@redhat.com <mailto:bburke@redhat.com>>> Cc: > keycloak-user(a)lists.jboss.org > <mailto:keycloak-user@lists.jboss.org> > <mailto:keycloak-user@lists.jboss.org <mailto:keycloak-user@lists.jboss.org>> Message-ID: > <884719116.3009607.1395937081146.JavaMail.zimbra(a)redhat.com <mailto:884719116.3009607.1395937081146.JavaMail.zimbra@redhat.com> >

<mailto:884719116.3009607.1395937081146.JavaMail.zimbra@redhat.com>>> 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@redhat.com> <mailto:bburke@redhat.com >> <mailto:bburke@redhat.com>>> To: keycloak-user(a)lists.jboss.org <mailto:keycloak-user@lists.jboss.org> > <mailto:keycloak-user@lists.jboss.org <mailto:keycloak-user@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@lists.jboss.org> >>> <mailto:keycloak-user@lists.jboss.org <mailto:keycloak-user@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@lists.jboss.org> >> <mailto:keycloak-user@lists.jboss.org <mailto:keycloak-user@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@gmail.com> <mailto:n.preusker@gmail.com <mailto:n.preusker@gmail.com>>> > Subject: Re: [keycloak-user] Keycloak and AngularJS To: > keycloak-user(a)lists.jboss.org > <mailto:keycloak-user@lists.jboss.org> > <mailto:keycloak-user@lists.jboss.org <mailto:keycloak-user@lists.jboss.org>> Message-ID: <CA+HCLu_XG0xu+KUALgxoDuAMftA=rBgV-eFhwbDvaxq48NiOwQ(a)mail.gmail.com

<mailto:rBgV-eFhwbDvaxq48NiOwQ@mail.gmail.com <mailto:rBgV-eFhwbDvaxq48NiOwQ@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@redhat.com> <mailto:stian@redhat.com <mailto:stian@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@redhat.com> <mailto:bburke@redhat.com >>> <mailto:bburke@redhat.com>>> To: keycloak-user(a)lists.jboss.org <mailto:keycloak-user@lists.jboss.org> > <mailto:keycloak-user@lists.jboss.org <mailto:keycloak-user@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@lists.jboss.org> > <mailto:keycloak-user@lists.jboss.org <mailto:keycloak-user@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@lists.jboss.org> >>> <mailto:keycloak-user@lists.jboss.org <mailto:keycloak-user@lists.jboss.org>> >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>> >> _______________________________________________ keycloak-user >> mailing list keycloak-user(a)lists.jboss.org <mailto:keycloak-user@lists.jboss.org> >> <mailto:keycloak-user@lists.jboss.org <mailto:keycloak-user@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@redhat.com> <mailto:bburke@redhat.com <mailto:bburke@redhat.com>>> Subject: Re: > [keycloak-user] Keycloak and AngularJS To: Stian Thorgersen > <stian(a)redhat.com <mailto:stian@redhat.com> <mailto:stian@redhat.com <mailto:stian@redhat.com>>> Cc: > keycloak-user(a)lists.jboss.org > <mailto:keycloak-user@lists.jboss.org> > <mailto:keycloak-user@lists.jboss.org <mailto:keycloak-user@lists.jboss.org>> Message-ID: > <53345202.4060105(a)redhat.com > <mailto:53345202.4060105@redhat.com> <mailto:53345202.4060105@redhat.com <mailto:53345202.4060105@redhat.com>>> > 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@redhat.com> <mailto:bburke@redhat.com >>> <mailto:bburke@redhat.com>>> To: keycloak-user(a)lists.jboss.org <mailto:keycloak-user@lists.jboss.org> > <mailto:keycloak-user@lists.jboss.org <mailto:keycloak-user@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@lists.jboss.org> >>>> <mailto:keycloak-user@lists.jboss.org <mailto:keycloak-user@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@lists.jboss.org> >>> <mailto:keycloak-user@lists.jboss.org <mailto:keycloak-user@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@lists.jboss.org> > <mailto:keycloak-user@lists.jboss.org <mailto:keycloak-user@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 <mailto:keycloak-user@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/keycloak-user _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org <mailto:keycloak-user@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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTNZa3AAoJEDnJtskdmzLMHTsIAJ6DD/ZHonAUliDlWdg/2ahF WR03fkKyev9TOeRT3BRl8yBKy16ajoXoWX/FqAsISQ/fMq4n+bEzSpP5xuNsmmpQ qNMWM8/Kyk2GHbx4p1ajizzydRmjzmoKhcy+rm9N6qsy4YyfWfraWHEalKi2Vg5u KCFMQA5nzDjSkpq8y2RMy+HgtyIjIim3JakpZugszP8FzwXDRFBfwqfCzYpM6JYN bQ46ExEblTimzBI5vO2erQpUKaeO+a6E24GFMC4Qcq+xudbmW3itV5x+KLdzs6A6 +XXHPufHielNdXNMZknRiDljImlPEs+FdvHrKPSdx0SIylTKpMBjUKXq5E+foDU= =v0Bq -----END PGP SIGNATURE-----