Inject (Keycloak)Principal

Thursday, 27 March 2014

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&gt;wrote:

...
 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: 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&gt;
 Subject: Re: [keycloak-user] Keycloak and AngularJS
 To: keycloak-user(a)lists.jboss.org
 Message-ID: <5334461B.8040202(a)redhat.com&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
 > 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&gt;
 Subject: Re: [keycloak-user] Keycloak and AngularJS
 To: Bill Burke <bburke(a)redhat.com&gt;
 Cc: keycloak-user(a)lists.jboss.org
 Message-ID:
         <884719116.3009607.1395937081146.JavaMail.zimbra(a)redhat.com&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&gt;
 > To: 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
 > > 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
 >

 ------------------------------

 Message: 3
 Date: Thu, 27 Mar 2014 17:24:06 +0100
 From: Nils Preusker <n.preusker(a)gmail.com&gt;
 Subject: Re: [keycloak-user] Keycloak and AngularJS
 To: keycloak-user(a)lists.jboss.org
 Message-ID:
         <CA+HCLu_XG0xu+KUALgxoDuAMftA=
 rBgV-eFhwbDvaxq48NiOwQ(a)mail.gmail.com&gt;
 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&gt;
 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&gt;
 > > To: 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
 > > > 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
 > >
 > _______________________________________________
 > 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/20140327/b8e5e...

 ------------------------------

 Message: 4
 Date: Thu, 27 Mar 2014 12:29:54 -0400
 From: Bill Burke <bburke(a)redhat.com&gt;
 Subject: Re: [keycloak-user] Keycloak and AngularJS
 To: Stian Thorgersen <stian(a)redhat.com&gt;
 Cc: keycloak-user(a)lists.jboss.org
 Message-ID: <53345202.4060105(a)redhat.com&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&gt;
 >> To: 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
 >>> 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
 >>

 --
 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

 End of keycloak-user Digest, Vol 3, Issue 14
 ********************************************

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014