[keycloak-user] Inject (Keycloak)Principal

Stian Thorgersen stian at redhat.com
Fri Mar 28 11:47:51 EDT 2014


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 at gmail.com>
> To: keycloak-user at 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 at 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/index.html#d4e485
> 
> 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 at lists.jboss.org
> > <mailto: keycloak-user-request at lists.jboss.org >> wrote:
> > 
> > Send keycloak-user mailing list submissions to
> > keycloak-user at lists.jboss.org
> > <mailto: keycloak-user at 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 at lists.jboss.org
> > <mailto: keycloak-user-request at lists.jboss.org >
> > 
> > You can reach the person managing the list at
> > keycloak-user-owner at lists.jboss.org
> > <mailto: keycloak-user-owner at 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 at redhat.com <mailto: bburke at redhat.com >> Subject: Re:
> > [keycloak-user] Keycloak and AngularJS To:
> > keycloak-user at lists.jboss.org
> > <mailto: keycloak-user at lists.jboss.org > Message-ID:
> > < 5334461B.8040202 at redhat.com <mailto: 5334461B.8040202 at 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 at lists.jboss.org
> >> <mailto: keycloak-user at 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 at redhat.com <mailto: stian at redhat.com >> Subject:
> > Re: [keycloak-user] Keycloak and AngularJS To: Bill Burke
> > < bburke at redhat.com <mailto: bburke at redhat.com >> Cc:
> > keycloak-user at lists.jboss.org
> > <mailto: keycloak-user at lists.jboss.org > Message-ID:
> > < 884719116.3009607.1395937081146.JavaMail.zimbra at redhat.com
> > <mailto: 884719116.3009607.1395937081146.JavaMail.zimbra at 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-token/
> > ,
> > 
> > 
> I think it provides a good summary of the pros of the token approach.
> > 
> > ----- Original Message -----
> >> From: "Bill Burke" < bburke at redhat.com
> >> <mailto: bburke at redhat.com >> To: keycloak-user at lists.jboss.org
> > <mailto: keycloak-user at 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 at lists.jboss.org
> >>> <mailto: keycloak-user at 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 at lists.jboss.org
> >> <mailto: keycloak-user at 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 at gmail.com <mailto: n.preusker at gmail.com >>
> > Subject: Re: [keycloak-user] Keycloak and AngularJS To:
> > keycloak-user at lists.jboss.org
> > <mailto: keycloak-user at lists.jboss.org > Message-ID:
> > 
> > <CA+HCLu_XG0xu+KUALgxoDuAMftA= rBgV-eFhwbDvaxq48NiOwQ at mail.gmail.com
> > 
> > 
> <mailto: rBgV-eFhwbDvaxq48NiOwQ at 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 at redhat.com <mailto: stian at 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-token/
> > ,
> > 
> > I think it provides a good summary of the pros of the token
> > approach.
> >> 
> >> ----- Original Message -----
> >>> From: "Bill Burke" < bburke at redhat.com
> >>> <mailto: bburke at redhat.com >> To: keycloak-user at lists.jboss.org
> > <mailto: keycloak-user at 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 at lists.jboss.org
> > <mailto: keycloak-user at 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 at lists.jboss.org
> >>> <mailto: keycloak-user at lists.jboss.org >
> >>> https://lists.jboss.org/mailman/listinfo/keycloak-user
> >>> 
> >> _______________________________________________ keycloak-user
> >> mailing list keycloak-user at lists.jboss.org
> >> <mailto: keycloak-user at 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/b8e5ee89/attachment-0001.html
> > 
> > ------------------------------
> > 
> > Message: 4 Date: Thu, 27 Mar 2014 12:29:54 -0400 From: Bill Burke
> > < bburke at redhat.com <mailto: bburke at redhat.com >> Subject: Re:
> > [keycloak-user] Keycloak and AngularJS To: Stian Thorgersen
> > < stian at redhat.com <mailto: stian at redhat.com >> Cc:
> > keycloak-user at lists.jboss.org
> > <mailto: keycloak-user at lists.jboss.org > Message-ID:
> > < 53345202.4060105 at redhat.com <mailto: 53345202.4060105 at 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-token/
> > ,
> > 
> > 
> I think it provides a good summary of the pros of the token approach.
> >> 
> >> ----- Original Message -----
> >>> From: "Bill Burke" < bburke at redhat.com
> >>> <mailto: bburke at redhat.com >> To: keycloak-user at lists.jboss.org
> > <mailto: keycloak-user at 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 at lists.jboss.org
> >>>> <mailto: keycloak-user at 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 at lists.jboss.org
> >>> <mailto: keycloak-user at 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 at lists.jboss.org
> > <mailto: keycloak-user at 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 at 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/
> 
> iQEcBAEBCgAGBQJTNSHcAAoJEDnJtskdmzLMHrYH/1D/vMgPxD0WUZ5KdIoD5Cow
> gb9fa+RZDQrpPxL1qKpqWJX3g1cKt8hQa1Xz7dX64G3/xcLUUkoJKkAtiJPysp75
> xbkdWV+RGQXDHuyZcS75xEXQlPaWt2cEVxdSXMalzfQPzVhq00FBbeJLirKLbYsY
> I2CIjJgCSQhmOrVfP5vUSdrwsLsd+TBXee4779YiOceSW16oG9Nfsa5gF1XJSNhi
> o2fZCEkoXhbTD7RXuhhrDWlFBCQOIgWf6FUHEAVKnXeIR5oey6U9hv1Z16Kd2Pll
> Pv8+LWlJjKMfkmrCQrVQvYSI/n64vxjikta2ByBdOPethsebqXO9oknbiPtjq6E=
> =TiWl
> -----END PGP SIGNATURE-----
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
> 
> 
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user



More information about the keycloak-user mailing list