[keycloak-user] Inject (Keycloak)Principal
Juraci Paixão Kröhling
juraci at kroehling.de
Fri Mar 28 11:35:19 EDT 2014
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
- From what I see on my own tests, yes, that's expected :-) You can get
the other details by giving more claims to the application, and then
casting the Principal to a keycloak identity class, which will provide
methods to get the other information. I can't recall the class name
from the top of my head, but it should be easy to find out in a quick
debugging session.
By the way, I quite like this approach of giving only IDs by default,
as I can control which applications can get the name/email of the
user. Some applications of mine just need a stable ID, no emails nor
names or anything else, so, this is quite convenient.
Juca.
On 03/28/2014 04:17 PM, Nils Preusker wrote:
> 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 <mailto:juraci at kroehling.de>> wrote:
>
> 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>
>> <mailto: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>
>> <mailto: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>
>> <mailto: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>
>> <mailto: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>
> <mailto: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>
>> <mailto: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>
> <mailto: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>
>>> <mailto: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>
> <mailto: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>
> <mailto:bburke at redhat.com <mailto:bburke at redhat.com>>> Cc:
>> keycloak-user at lists.jboss.org
>> <mailto:keycloak-user at lists.jboss.org>
>> <mailto: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>
>>
>
<mailto: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> <mailto:bburke at redhat.com
>>> <mailto:bburke at redhat.com>>> To:
> keycloak-user at lists.jboss.org
> <mailto:keycloak-user at lists.jboss.org>
>> <mailto: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>
>>>> <mailto: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>
>>> <mailto: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>
> <mailto: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>
>> <mailto: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>
>
>
> <mailto: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>
> <mailto: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> <mailto:bburke at redhat.com
>>>> <mailto:bburke at redhat.com>>> To:
> keycloak-user at lists.jboss.org
> <mailto:keycloak-user at lists.jboss.org>
>> <mailto: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>
>> <mailto: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>
>>>> <mailto: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>
>>> <mailto: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>
> <mailto: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>
> <mailto:stian at redhat.com <mailto:stian at redhat.com>>> Cc:
>> keycloak-user at lists.jboss.org
>> <mailto:keycloak-user at lists.jboss.org>
>> <mailto: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>
> <mailto: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> <mailto:bburke at redhat.com
>>>> <mailto:bburke at redhat.com>>> To:
> keycloak-user at lists.jboss.org
> <mailto:keycloak-user at lists.jboss.org>
>> <mailto: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>
>>>>> <mailto: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>
>>>> <mailto: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>
>> <mailto: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
> <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
>
>
>
>
> _______________________________________________ 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/
iQEcBAEBCgAGBQJTNZa3AAoJEDnJtskdmzLMHTsIAJ6DD/ZHonAUliDlWdg/2ahF
WR03fkKyev9TOeRT3BRl8yBKy16ajoXoWX/FqAsISQ/fMq4n+bEzSpP5xuNsmmpQ
qNMWM8/Kyk2GHbx4p1ajizzydRmjzmoKhcy+rm9N6qsy4YyfWfraWHEalKi2Vg5u
KCFMQA5nzDjSkpq8y2RMy+HgtyIjIim3JakpZugszP8FzwXDRFBfwqfCzYpM6JYN
bQ46ExEblTimzBI5vO2erQpUKaeO+a6E24GFMC4Qcq+xudbmW3itV5x+KLdzs6A6
+XXHPufHielNdXNMZknRiDljImlPEs+FdvHrKPSdx0SIylTKpMBjUKXq5E+foDU=
=v0Bq
-----END PGP SIGNATURE-----
More information about the keycloak-user
mailing list