Tomcat / Jetty adapter
by Davide Ungari
I will take a look at the as7-eap adapter this weekend.
As I will star development I will inform you on the developers list.
--
--
Davide
10 years, 9 months
JSON Export of Realm
by Nils Preusker
Hi all,
I was wondering whether there is a simple way to export the realms you
create in the admin console as JSON like you did with the demo realm. I
didn't find a way to do this in the console UI.
Cheers,
Nils
10 years, 9 months
Re: [keycloak-user] Inject (Keycloak)Principal
by Dirk Franssen
Hey Bill,
I think it would make sense to add the IDToken to the KeycloakPrincipal.
This avoids the additional
servletRequest.getAttribute(KeycloakSecurityContext.class.getName()) call
in order to get the user details.
For info to other users: in order to get more than only the (preferred)
username, you should change in your realm the Allowed Claims at the
application level, otherwise e.g. the email address will stay null however
it was provided in the account of the user.
@Nils/Juca:
the injection of the principal is now working. I didn't had @Stateless on
the CustomerService before, that's why :-).
Just to be sure: in one of the video's the database service was also being
defined in the admin console as an application, but I assume that this is
superfluous as the bundeld demo realm is not describing it?
Thanks.
Dirk Franssen
On Fri, Mar 28, 2014 at 5:14 PM, <keycloak-user-request(a)lists.jboss.org>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: Inject (Keycloak)Principal (Nils Preusker)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 28 Mar 2014 17:14:03 +0100
> From: Nils Preusker <n.preusker(a)gmail.com>
> Subject: Re: [keycloak-user] Inject (Keycloak)Principal
> To: keycloak-user(a)lists.jboss.org
> Message-ID:
> <CA+HCLu-cCPaeZ2mKAJXUOcvt5JMPnMOMNXzSbqegUm6PW=-
> EUQ(a)mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> 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(a)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(a)gmail.com>
> > >> To: keycloak-user(a)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(a)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/ind...
> > >>
> > >> 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(a)lists.jboss.org
> > >>> <mailto: keycloak-user-request(a)lists.jboss.org >> wrote:
> > >>>
> > >>> Send keycloak-user mailing list submissions to
> > >>> keycloak-user(a)lists.jboss.org
> > >>> <mailto: 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
> > >>> <mailto: keycloak-user-request(a)lists.jboss.org >
> > >>>
> > >>> You can reach the person managing the list at
> > >>> keycloak-user-owner(a)lists.jboss.org
> > >>> <mailto: 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 <mailto: bburke(a)redhat.com >> Subject: Re:
> > >>> [keycloak-user] Keycloak and AngularJS To:
> > >>> keycloak-user(a)lists.jboss.org
> > >>> <mailto: keycloak-user(a)lists.jboss.org > Message-ID:
> > >>> < 5334461B.8040202(a)redhat.com <mailto: 5334461B.8040202(a)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(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 <mailto: stian(a)redhat.com >> Subject:
> > >>> Re: [keycloak-user] Keycloak and AngularJS To: Bill Burke
> > >>> < bburke(a)redhat.com <mailto: bburke(a)redhat.com >> Cc:
> > >>> keycloak-user(a)lists.jboss.org
> > >>> <mailto: keycloak-user(a)lists.jboss.org > Message-ID:
> > >>> < 884719116.3009607.1395937081146.JavaMail.zimbra(a)redhat.com
> > >>> <mailto: 884719116.3009607.1395937081146.JavaMail.zimbra(a)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(a)redhat.com >> To: keycloak-user(a)lists.jboss.org
> > >>> <mailto: 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
> > >>>>> <mailto: 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
> > >>>> <mailto: 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 <mailto: n.preusker(a)gmail.com >>
> > >>> Subject: Re: [keycloak-user] Keycloak and AngularJS To:
> > >>> keycloak-user(a)lists.jboss.org
> > >>> <mailto: keycloak-user(a)lists.jboss.org > Message-ID:
> > >>>
> > >>> <CA+HCLu_XG0xu+KUALgxoDuAMftA= rBgV-eFhwbDvaxq48NiOwQ(a)mail.gmail.com
> > >>>
> > >>>
> > >> <mailto: rBgV-eFhwbDvaxq48NiOwQ(a)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(a)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(a)redhat.com >> To: keycloak-user(a)lists.jboss.org
> > >>> <mailto: 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
> > >>> <mailto: 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
> > >>>>> <mailto: keycloak-user(a)lists.jboss.org >
> > >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
> > >>>>>
> > >>>> _______________________________________________ keycloak-user
> > >>>> mailing list keycloak-user(a)lists.jboss.org
> > >>>> <mailto: 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 <mailto: bburke(a)redhat.com >> Subject: Re:
> > >>> [keycloak-user] Keycloak and AngularJS To: Stian Thorgersen
> > >>> < stian(a)redhat.com <mailto: stian(a)redhat.com >> Cc:
> > >>> keycloak-user(a)lists.jboss.org
> > >>> <mailto: keycloak-user(a)lists.jboss.org > Message-ID:
> > >>> < 53345202.4060105(a)redhat.com <mailto: 53345202.4060105(a)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...
> > >>> ,
> > >>>
> > >>>
> > >> 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(a)redhat.com >> To: keycloak-user(a)lists.jboss.org
> > >>> <mailto: 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
> > >>>>>> <mailto: 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
> > >>>>> <mailto: 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
> > >>> <mailto: keycloak-user(a)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(a)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(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
> > >
> > > _______________________________________________
> > > 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
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/keycloak-user/attachments/20140328/d14cb...
>
> ------------------------------
>
> _______________________________________________
> 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 21
> ********************************************
>
10 years, 9 months
Inject (Keycloak)Principal
by Dirk Franssen
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>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>
> Subject: Re: [keycloak-user] Keycloak and AngularJS
> To: keycloak-user(a)lists.jboss.org
> Message-ID: <5334461B.8040202(a)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
> > 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>
> Subject: Re: [keycloak-user] Keycloak and AngularJS
> To: Bill Burke <bburke(a)redhat.com>
> Cc: keycloak-user(a)lists.jboss.org
> Message-ID:
> <884719116.3009607.1395937081146.JavaMail.zimbra(a)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>
> > 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>
> 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>
> 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>
> 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>
> > > 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>
> Subject: Re: [keycloak-user] Keycloak and AngularJS
> To: Stian Thorgersen <stian(a)redhat.com>
> Cc: keycloak-user(a)lists.jboss.org
> Message-ID: <53345202.4060105(a)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...,
> I think it provides a good summary of the pros of the token approach.
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke(a)redhat.com>
> >> 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
> ********************************************
>
10 years, 9 months
Re: [keycloak-user] token expired exception (Stian Thorgersen)
by Toan Nguyen Xuan
Hi,
The current I have not try keycloak with my project. I try reseasy 3.0.6 that has simple oauth2 implement and I can't control expired key in my project. Can you show me how to solve this problem by using keyloak? I install keycloak successfully but I don't know start where. If this is solved I will use keycloak in my project.
Many thanks before.
-----Original Message-----
From: Stian Thorgersen [mailto:stian@redhat.com]
Sent: Wednesday, March 26, 2014 4:20 PM
To: Toan Nguyen Xuan
Cc: keycloak-user(a)lists.jboss.org
Subject: Re: [keycloak-user] token expired exception
Are you using one of our adapters?
The token expiration can be controlled through the admin console, but generally a token should have a relatively short expiration (5-10 min). Then you have a refresh token with a long expiration (days) that can be used to retrieve a new token. Prior to doing a request you should check the expiration time and retrieve a new token if needed.
----- Original Message -----
> From: "Toan Nguyen Xuan" <xuantoan.nguyen(a)vtc.vn>
> To: keycloak-user(a)lists.jboss.org
> Sent: Wednesday, 26 March, 2014 8:24:58 AM
> Subject: [keycloak-user] token expired exception
>
>
>
> Hi you,
>
> I just use keycloak for authen application to access my resource, but
> I don’t know control token key life time. One app will not access my
> resource when token key is expired, this app does not know when reinit
> token key. I want to catch Token key expired to return apps. Please help me.
>
> Have any extend keylocak library? Goal of Keyloak is very good, I like this.
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
10 years, 9 months
Keycloak and AngularJS
by Nils Preusker
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
10 years, 9 months
token expired exception
by Toan Nguyen Xuan
Hi you,
I just use keycloak for authen application to access my resource, but I
don't know control token key life time. One app will not access my resource
when token key is expired, this app does not know when reinit token key. I
want to catch Token key expired to return apps. Please help me.
Have any extend keylocak library? Goal of Keyloak is very good, I like
this.
10 years, 9 months
Install examples
by Nils Preusker
Hey guys,
I just noticed that if you want to install the preconfigured examples, the
README.md file states that you should run mvn clean install. While that
works fine if you have keycloak checked out and the root pom installed in
your local maven repo (in the correct version), it fails if you just
download the keycloak-war-dist-all-1.0-alpha-XX.zip and try to install the
examples. This might be confusing for someone who just wants to quickly
install the examples. I didn't check in detail yet, but I guess it could
easily be avoided by removing the parent pom dependency in the example app
poms.
Cheers,
Nils
10 years, 9 months
Figured out Logging out
by Dean Peterson
When I entered the Admin URL I used a localhost url. I have my test app on
a separate machine from the keycloak server I have running. My redirect
urls all have localhost and that is fine because I am using my app on the
machine it is running on and a localhost redirect is ok when the redirect
happens on my end. It was intuitive for me to put localhost in the admin
url too because the redirect urls and the admin url are all entered on the
same page. When I log out, the keycloak server makes a request on its end
using the management url. Of course that fails because localhost refers to
the keycloak server in that case and not my application. So, long story
short, stupid user error.
10 years, 9 months
Re: [keycloak-user] Logging out
by Dean Peterson
I used a different e-mail and my previous post did not get through.
Ok, that makes sense. I am still trying to figure out how k_logout should
work on my end. I do have the keycloak modules installed on the server
running my app. However, I still get a value of false in logoutApplication:
Response response = client.target(managementUrl).path(AdapterConstants.
*K_LOGOUT*).request().post(Entity.*text*(token));
*boolean* success = response.getStatus() == 204;
The success Boolean is false. I set the Admin url to some path with
"admin" but I do not have a REST service at any location for
.../admin/.../k_logout. Am I supposed to do something on my end or should the
keycloak modules have automatically set something up that understands how
to handle a request to something like .../admin/.../k_logout?
I just would have liked to make all of this a bit easier. Why can't I
create some REST service on my end that calls something like:
KeycloakSecurityContext.logout(); Under the covers
KeycloakSecurityContext.logout() builds the logout uri, sends the request
to the keycloak server and finally logs me out of the local application?
10 years, 9 months
