[keycloak-user] Inject (Keycloak)Principal
Dirk Franssen
dirk.franssen at gmail.com
Thu Mar 27 20:31:03 EDT 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 at lists.jboss.org>wrote:
> Send keycloak-user mailing list submissions to
> 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
>
> You can reach the person managing the list at
> 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>
> Subject: Re: [keycloak-user] Keycloak and AngularJS
> To: keycloak-user at lists.jboss.org
> Message-ID: <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
> > 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>
> Subject: Re: [keycloak-user] Keycloak and AngularJS
> To: Bill Burke <bburke at redhat.com>
> Cc: keycloak-user at lists.jboss.org
> Message-ID:
> <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>
> > To: 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
> > > 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
> > 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>
> Subject: Re: [keycloak-user] Keycloak and AngularJS
> To: keycloak-user at lists.jboss.org
> Message-ID:
> <CA+HCLu_XG0xu+KUALgxoDuAMftA=
> 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>
> 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>
> > > To: 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
> > > > 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
> > > 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
> >
> -------------- 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>
> Subject: Re: [keycloak-user] Keycloak and AngularJS
> To: Stian Thorgersen <stian at redhat.com>
> Cc: keycloak-user at lists.jboss.org
> Message-ID: <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>
> >> To: 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
> >>> 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
> >> 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
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
> End of keycloak-user Digest, Vol 3, Issue 14
> ********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20140328/058a6903/attachment-0001.html
More information about the keycloak-user
mailing list