Re: [keycloak-user] Inject (Keycloak)Principal

Friday, 28 March 2014

SecurityContext.getUserPrincipal() should be working without any other 
additional JAX-RS filters.  I'll take a look.

On 3/27/2014 8:31 PM, 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>> wrote:
>
>     Send keycloak-user mailing list submissions to
>     keycloak-user(a)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>
>
>     You can reach the person managing the list at
>     keycloak-user-owner(a)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>>
>     Subject: Re: [keycloak-user] Keycloak and AngularJS
>     To: keycloak-user(a)lists.jboss.org <mailto:keycloak-user@lists.jboss.org>
>     Message-ID: <5334461B.8040202(a)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>
>      > 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>>
>     Subject: Re: [keycloak-user] Keycloak and AngularJS
>     To: Bill Burke <bburke(a)redhat.com <mailto:bburke@redhat.com>>
>     Cc: keycloak-user(a)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>>
>     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>>
>      > To: keycloak-user(a)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>
>      > > 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>
>      > 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>>
>     Subject: Re: [keycloak-user] Keycloak and AngularJS
>     To: keycloak-user(a)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>>
>     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>> 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>>
>      > > To: keycloak-user(a)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>
>      > > > 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>
>      > > 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
>      >
>     

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

Re: [keycloak-user] Inject (Keycloak)Principal