[keycloak-user] Inject (Keycloak)Principal

Nils Preusker n.preusker at gmail.com
Fri Mar 28 12:14:03 EDT 2014


Cheers Bill, I added

KeycloakSecurityContext ctx = (KeycloakSecurityContext)
servletRequest.getAttribute(KeycloakSecurityContext.class.getName());

and can now access the user name via ctx.getToken().getPreferredUsername().

The only downside to this is that I now need keycloak in my dependencies in
irder to know the class KeycloakSecurityContext, but I guess I can live
with that :)

Thanks again!
Nils



On Fri, Mar 28, 2014 at 4:57 PM, Bill Burke <bburke at redhat.com> wrote:

> The KeycloakSecurityContext has access to the IDToken which can contain
> information like name, email, address, etc... Depending on how you
> configure your realm.  Maybe IDToken should be added to the
> KeycloakPrincipal?
>
> On 3/28/2014 11:47 AM, Stian Thorgersen wrote:
> > 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
> >
> > _______________________________________________
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20140328/d14cb7f6/attachment-0001.html 


More information about the keycloak-user mailing list