From eric.wittmann at redhat.com Tue Jan 28 14:21:23 2014 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Tue, 28 Jan 2014 14:21:23 -0500 Subject: [keycloak-user] Bearer token expiration question Message-ID: <52E80333.6030702@redhat.com> First of all, Keycloak looks great - the alpha release is a very nice start! I have a question about bearer token expiration. Take the included product portal example. It is configured to use Keycloak for SSO, which allows the user to access the product listing page. That listing page uses the current SkeletonKeySession's token as the Bearer token when invoking the database/products REST endpoint. This makes sense to me, but one interesting thing happens - that token eventually times out. Once that happens all calls to the REST endpoint fail. Note that this occurs even if the user refreshes that product listing page. The timeout is from login, not from the last activity (like an http session timeout would be). So in this scenario, how is the product page supposed to get a new token when the old one expires? This becomes even more relevant if the UI is not a JSP but is instead a JavaScript app (e.g. angular, GWT, etc). I was thinking that I would need to pass the token to the client layer, which would then allow me to make authenticated REST calls directly from the Client/JavaScript layer to a REST API. That would be a great separation, but obviously the user should not get logged out after N minutes despite actively using the app during that time. I'm probably missing something obvious... :) -Eric From bburke at redhat.com Tue Jan 28 15:11:53 2014 From: bburke at redhat.com (Bill Burke) Date: Tue, 28 Jan 2014 15:11:53 -0500 Subject: [keycloak-user] Bearer token expiration question In-Reply-To: <52E80333.6030702@redhat.com> References: <52E80333.6030702@redhat.com> Message-ID: <52E80F09.6010401@redhat.com> You're not missing something obvious. We need to add refresh tokens that can be held by the HTTP session or the Javascript client so a new access token can be obtained. There's also some work still to be done to smooth out Javascript only clients that are servered up via static pages. On 1/28/2014 2:21 PM, Eric Wittmann wrote: > First of all, Keycloak looks great - the alpha release is a very nice start! > > I have a question about bearer token expiration. Take the included > product portal example. It is configured to use Keycloak for SSO, which > allows the user to access the product listing page. That listing page > uses the current SkeletonKeySession's token as the Bearer token when > invoking the database/products REST endpoint. This makes sense to me, > but one interesting thing happens - that token eventually times out. > Once that happens all calls to the REST endpoint fail. > > Note that this occurs even if the user refreshes that product listing > page. The timeout is from login, not from the last activity (like an > http session timeout would be). > > So in this scenario, how is the product page supposed to get a new token > when the old one expires? > > This becomes even more relevant if the UI is not a JSP but is instead a > JavaScript app (e.g. angular, GWT, etc). I was thinking that I would > need to pass the token to the client layer, which would then allow me to > make authenticated REST calls directly from the Client/JavaScript layer > to a REST API. That would be a great separation, but obviously the user > should not get logged out after N minutes despite actively using the app > during that time. > > I'm probably missing something obvious... :) > > -Eric > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From eric.wittmann at redhat.com Tue Jan 28 15:31:59 2014 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Tue, 28 Jan 2014 15:31:59 -0500 Subject: [keycloak-user] Bearer token expiration question In-Reply-To: <52E80F09.6010401@redhat.com> References: <52E80333.6030702@redhat.com> <52E80F09.6010401@redhat.com> Message-ID: <52E813BF.7000702@redhat.com> Thanks for the response Bill. This is great news (both that it's on the roadmap and that I'm not[1] an idiot). Let me know if I can help with testing. There's a new project starting up in JBoss Overlord that I'm in the process of bootstrapping now. I'm going to design it with this approach in mind (Javascript client making REST calls directly to an API that is separate from the webapp that served up the JS). So I'm happy to be an early adopter/tester. -Eric [1] necessarily On 1/28/2014 3:11 PM, Bill Burke wrote: > You're not missing something obvious. We need to add refresh tokens > that can be held by the HTTP session or the Javascript client so a new > access token can be obtained. There's also some work still to be done > to smooth out Javascript only clients that are servered up via static pages. > > > On 1/28/2014 2:21 PM, Eric Wittmann wrote: >> First of all, Keycloak looks great - the alpha release is a very nice start! >> >> I have a question about bearer token expiration. Take the included >> product portal example. It is configured to use Keycloak for SSO, which >> allows the user to access the product listing page. That listing page >> uses the current SkeletonKeySession's token as the Bearer token when >> invoking the database/products REST endpoint. This makes sense to me, >> but one interesting thing happens - that token eventually times out. >> Once that happens all calls to the REST endpoint fail. >> >> Note that this occurs even if the user refreshes that product listing >> page. The timeout is from login, not from the last activity (like an >> http session timeout would be). >> >> So in this scenario, how is the product page supposed to get a new token >> when the old one expires? >> >> This becomes even more relevant if the UI is not a JSP but is instead a >> JavaScript app (e.g. angular, GWT, etc). I was thinking that I would >> need to pass the token to the client layer, which would then allow me to >> make authenticated REST calls directly from the Client/JavaScript layer >> to a REST API. That would be a great separation, but obviously the user >> should not get logged out after N minutes despite actively using the app >> during that time. >> >> I'm probably missing something obvious... :) >> >> -Eric >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> > From n.preusker at gmail.com Wed Jan 29 06:49:01 2014 From: n.preusker at gmail.com (Nils Preusker) Date: Wed, 29 Jan 2014 12:49:01 +0100 Subject: [keycloak-user] Keycloak and OAuth 2.0 Resource Owner Password Credentials Grant Message-ID: Hi all, first of all, congrats on the first alpha release of Keycloak! We're looking for a simple and lean way to add the OAuth 2.0 Resource Owner Password Credentials Grant to a web application written in JavaScript with a Java/REST backend (JBoss AS 7, planning to switch to WildFly, JAX-RS etc.). Since I didn't find any references in the code or the docs, I'm wondering: does Keycloak provide an implementation of the Resource Owner Password Credentials Grant as described in the OAuth Spec ( http://tools.ietf.org/html/rfc6749#section-4.3)? In other words, is there a way to simply send a username and password to the auth server in exchange for an access token (and optionally a refresh token - from previous posts I gather this will be added soon...)? Cheers, Nils -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20140129/1628a53d/attachment.html From bburke at redhat.com Wed Jan 29 09:22:30 2014 From: bburke at redhat.com (Bill Burke) Date: Wed, 29 Jan 2014 09:22:30 -0500 Subject: [keycloak-user] Keycloak and OAuth 2.0 Resource Owner Password Credentials Grant In-Reply-To: References: Message-ID: <52E90EA6.7020402@redhat.com> We do support 4.3, but I'm thinking of removing it as IMO it is a potential security hole. I'm thinking of augmenting 4.3 so that the client additionally has to pass it's own credentials as well as the user's. I guess you want to do this because you want to control your own login screen? IMO, you lose a lot of the benefits of Keycloak by doing this (credential reset, acct mgmt, etc.). Keycloak also allows you to add additional credential types over time without changing your application at all. (i.e. if you wanted to add OTP). On 1/29/2014 6:49 AM, Nils Preusker wrote: > Hi all, > > first of all, congrats on the first alpha release of Keycloak! > > We're looking for a simple and lean way to add the OAuth 2.0 Resource > Owner Password Credentials Grant to a web application written in > JavaScript with a Java/REST backend (JBoss AS 7, planning to switch to > WildFly, JAX-RS etc.). > > Since I didn't find any references in the code or the docs, I'm > wondering: does Keycloak provide an implementation of the Resource Owner > Password Credentials Grant as described in the OAuth Spec > (http://tools.ietf.org/html/rfc6749#section-4.3)? In other words, is > there a way to simply send a username and password to the auth server in > exchange for an access token (and optionally a refresh token - from > previous posts I gather this will be added soon...)? > > Cheers, > Nils > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Wed Jan 29 09:38:36 2014 From: bburke at redhat.com (Bill Burke) Date: Wed, 29 Jan 2014 09:38:36 -0500 Subject: [keycloak-user] test moderation filters Message-ID: <52E9126C.7020406@redhat.com> testing it -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From patriot1burke at gmail.com Wed Jan 29 09:40:08 2014 From: patriot1burke at gmail.com (Bill Burke) Date: Wed, 29 Jan 2014 09:40:08 -0500 Subject: [keycloak-user] test non-member Message-ID: test non-member post -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20140129/77cd2c31/attachment.html From n.preusker at gmail.com Wed Jan 29 09:56:17 2014 From: n.preusker at gmail.com (Nils Preusker) Date: Wed, 29 Jan 2014 15:56:17 +0100 Subject: [keycloak-user] Keycloak and OAuth 2.0 Resource Owner Password Credentials Grant In-Reply-To: <52E90EA6.7020402@redhat.com> References: <52E90EA6.7020402@redhat.com> Message-ID: Hi Bill, maybe you can elaborate a bit on why you think 4.3 (Resource Owner Password Grant) is a potential security hole. Your assumption - that we want to control our own login screen - is correct. About your security concern, it is possible to just add fields (like a client id) to 4.3. As far as I'm aware, Saleforce does this with the "client_id" and "client_secret" parameters for API access to salesforce.com. Cheers, Nils On Wed, Jan 29, 2014 at 3:22 PM, Bill Burke wrote: > We do support 4.3, but I'm thinking of removing it as IMO it is a > potential security hole. I'm thinking of augmenting 4.3 so that the > client additionally has to pass it's own credentials as well as the > user's. > > I guess you want to do this because you want to control your own login > screen? IMO, you lose a lot of the benefits of Keycloak by doing this > (credential reset, acct mgmt, etc.). Keycloak also allows you to add > additional credential types over time without changing your application > at all. (i.e. if you wanted to add OTP). > > On 1/29/2014 6:49 AM, Nils Preusker wrote: > > Hi all, > > > > first of all, congrats on the first alpha release of Keycloak! > > > > We're looking for a simple and lean way to add the OAuth 2.0 Resource > > Owner Password Credentials Grant to a web application written in > > JavaScript with a Java/REST backend (JBoss AS 7, planning to switch to > > WildFly, JAX-RS etc.). > > > > Since I didn't find any references in the code or the docs, I'm > > wondering: does Keycloak provide an implementation of the Resource Owner > > Password Credentials Grant as described in the OAuth Spec > > (http://tools.ietf.org/html/rfc6749#section-4.3)? In other words, is > > there a way to simply send a username and password to the auth server in > > exchange for an access token (and optionally a refresh token - from > > previous posts I gather this will be added soon...)? > > > > Cheers, > > Nils > > > > > > _______________________________________________ > > keycloak-user mailing list > > keycloak-user at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20140129/05a20cd5/attachment-0001.html From stian at redhat.com Wed Jan 29 10:03:24 2014 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 29 Jan 2014 10:03:24 -0500 (EST) Subject: [keycloak-user] Keycloak and OAuth 2.0 Resource Owner Password Credentials Grant In-Reply-To: References: <52E90EA6.7020402@redhat.com> Message-ID: <1039560905.15491400.1391007804749.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Nils Preusker" > To: keycloak-user at lists.jboss.org > Sent: Wednesday, 29 January, 2014 2:56:17 PM > Subject: Re: [keycloak-user] Keycloak and OAuth 2.0 Resource Owner Password Credentials Grant > > Hi Bill, > > maybe you can elaborate a bit on why you think 4.3 (Resource Owner Password > Grant) is a potential security hole. > > Your assumption - that we want to control our own login screen - is correct. In the next alpha we'll provide support for customizing the login screens. Through CSS and/or by custom templates. Would that cover your needs? > > About your security concern, it is possible to just add fields (like a client > id) to 4.3. As far as I'm aware, Saleforce does this with the "client_id" > and "client_secret" parameters for API access to salesforce.com . > > Cheers, > Nils > > > > > On Wed, Jan 29, 2014 at 3:22 PM, Bill Burke < bburke at redhat.com > wrote: > > > We do support 4.3, but I'm thinking of removing it as IMO it is a > potential security hole. I'm thinking of augmenting 4.3 so that the > client additionally has to pass it's own credentials as well as the > user's. > > I guess you want to do this because you want to control your own login > screen? IMO, you lose a lot of the benefits of Keycloak by doing this > (credential reset, acct mgmt, etc.). Keycloak also allows you to add > additional credential types over time without changing your application > at all. (i.e. if you wanted to add OTP). > > On 1/29/2014 6:49 AM, Nils Preusker wrote: > > Hi all, > > > > first of all, congrats on the first alpha release of Keycloak! > > > > We're looking for a simple and lean way to add the OAuth 2.0 Resource > > Owner Password Credentials Grant to a web application written in > > JavaScript with a Java/REST backend (JBoss AS 7, planning to switch to > > WildFly, JAX-RS etc.). > > > > Since I didn't find any references in the code or the docs, I'm > > wondering: does Keycloak provide an implementation of the Resource Owner > > Password Credentials Grant as described in the OAuth Spec > > ( http://tools.ietf.org/html/rfc6749#section-4.3 )? In other words, is > > there a way to simply send a username and password to the auth server in > > exchange for an access token (and optionally a refresh token - from > > previous posts I gather this will be added soon...)? > > > > Cheers, > > Nils > > > > > > _______________________________________________ > > keycloak-user mailing list > > keycloak-user at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user From bburke at redhat.com Wed Jan 29 10:07:50 2014 From: bburke at redhat.com (Bill Burke) Date: Wed, 29 Jan 2014 10:07:50 -0500 Subject: [keycloak-user] Keycloak and OAuth 2.0 Resource Owner Password Credentials Grant In-Reply-To: References: <52E90EA6.7020402@redhat.com> Message-ID: <52E91946.5040400@redhat.com> On 1/29/2014 9:56 AM, Nils Preusker wrote: > Hi Bill, > > maybe you can elaborate a bit on why you think 4.3 (Resource Owner > Password Grant) is a potential security hole. > Keycloak has the concept of "scope". Scope is the roles that a client is allowed to request for. For instance, a user may have "admin" privileges, but you may not want to grant a token with admin privileges to specific client. > Your assumption - that we want to control our own login screen - is > correct. > We're adding style sheets and pluggable themes, maybe that could push you to move to a Keycloak hosted login screen? I don't know. > About your security concern, it is possible to just add fields (like a > client id) to 4.3. As far as I'm aware, Saleforce does this with the > "client_id" and "client_secret" parameters for API access to > salesforce.com . > Yes, that's what I'm planning to do. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From n.preusker at gmail.com Wed Jan 29 10:32:53 2014 From: n.preusker at gmail.com (Nils Preusker) Date: Wed, 29 Jan 2014 16:32:53 +0100 Subject: [keycloak-user] Keycloak and OAuth 2.0 Resource Owner Password Credentials Grant In-Reply-To: <52E91946.5040400@redhat.com> References: <52E90EA6.7020402@redhat.com> <52E91946.5040400@redhat.com> Message-ID: Hey, that all sounds pretty good! So far I was a bit reluctant to use a third party login screen... But on second thought, the argument of being able to add credential types over time without having to change your application sounds pretty compelling. Would you be interested in working together on a small AngularJS example to showcase the integration of keycloak and client side web-applications? Cheers, Nils On Wed, Jan 29, 2014 at 4:07 PM, Bill Burke wrote: > > > On 1/29/2014 9:56 AM, Nils Preusker wrote: > > Hi Bill, > > > > maybe you can elaborate a bit on why you think 4.3 (Resource Owner > > Password Grant) is a potential security hole. > > > > Keycloak has the concept of "scope". Scope is the roles that a client > is allowed to request for. For instance, a user may have "admin" > privileges, but you may not want to grant a token with admin privileges > to specific client. > > > Your assumption - that we want to control our own login screen - is > > correct. > > > > We're adding style sheets and pluggable themes, maybe that could push > you to move to a Keycloak hosted login screen? I don't know. > > > About your security concern, it is possible to just add fields (like a > > client id) to 4.3. As far as I'm aware, Saleforce does this with the > > "client_id" and "client_secret" parameters for API access to > > salesforce.com . > > > > Yes, that's what I'm planning to do. > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20140129/227e8f6c/attachment.html From bburke at redhat.com Wed Jan 29 10:50:57 2014 From: bburke at redhat.com (Bill Burke) Date: Wed, 29 Jan 2014 10:50:57 -0500 Subject: [keycloak-user] Keycloak and OAuth 2.0 Resource Owner Password Credentials Grant In-Reply-To: References: <52E90EA6.7020402@redhat.com> <52E91946.5040400@redhat.com> Message-ID: <52E92361.5090404@redhat.com> On 1/29/2014 10:32 AM, Nils Preusker wrote: > Hey, that all sounds pretty good! So far I was a bit reluctant to use a > third party login screen... But on second thought, the argument of being > able to add credential types over time without having to change your > application sounds pretty compelling. > Its not just that. Also each secured app gets "Forgot Password" "Lost Authenticator" for free. Admin console can also force users to change their password or update their authenticator. > Would you be interested in working together on a small AngularJS example > to showcase the integration of keycloak and client side web-applications? > We support this already. Keycloak Admin console is actually written in Angular JS. We have two flavors for client side web apps. * App's Server manages Keycloak interaction. Token is stored in the Http Session. Client can obtain token after authentication by a REST call to the App's Server. Keycloak Admin console uses this form. * Pure client side app. Stian has written a JS lib for this. basically performs all the same OAuth redirect protocol. Client (in addition to the user) is authenticated by checking/matching redirect URIs. This requires CORS set up though (which we also support). For CORS we only support "validated CORS" currently. The auth token contains the authorized origins which are validated on CORS requests. Next release we want the App's Server to query the Keycloak admin server for valid origins. This way you can make unauthenticated CORS requests which can sstill protect against XSS. We need to put an example and docs for all of this for the next release. Bill -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From n.preusker at gmail.com Wed Jan 29 10:58:34 2014 From: n.preusker at gmail.com (Nils Preusker) Date: Wed, 29 Jan 2014 16:58:34 +0100 Subject: [keycloak-user] Verifying Bearer Tokens in Vert.x Message-ID: Hi everybody, we are developing an application that consists of several REST web-applications written with different application frameworks (Java EE 6/ JBoss AS and Vert.x). So far we are using org.jboss.resteasy.skeleton.key.as7.OAuthAuthenticationServerValve from the skelton-key-as7 template (which as far as I can see, keycloak is based on?) as an OAuth provider and just add bearer tokens to the authentication headers of the HTTP requests between the modules. One of the really nice features for us is that the role mapping of users is included in the tokens (which is also described in the keycloak docs with a reference to JSON Web Tokens). Now the modules that are deployed to JBoss AS transparently verify the bearer tokens and RESTEasy even takes care of adding the username and the user roles to the HttpServletRequest which also allows us to use @RolesAllowed (very convenient!). What I'm wondering now is whether there is an easy way of adding validation and decoding of bearer tokens to Vert.x modules. Ideally, I would like to be able to add a jar dependency that provides me with a few methods to validate the token (make sure it is a real token, hasn't been modified and didn't expire...) and extract the user and roles from it. Since a private key is needed, I guess I would add a json config file or even just pass the required values to the API directly. Does that make sense? Cheers, Nils -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20140129/8547a9f6/attachment.html From bburke at redhat.com Wed Jan 29 11:05:58 2014 From: bburke at redhat.com (Bill Burke) Date: Wed, 29 Jan 2014 11:05:58 -0500 Subject: [keycloak-user] Verifying Bearer Tokens in Vert.x In-Reply-To: References: Message-ID: <52E926E6.9080100@redhat.com> On 1/29/2014 10:58 AM, Nils Preusker wrote: > Hi everybody, > > we are developing an application that consists of several REST > web-applications written with different application frameworks (Java EE > 6/ JBoss AS and Vert.x). So far we are > using org.jboss.resteasy.skeleton.key.as7.OAuthAuthenticationServerValve > from the skelton-key-as7 template (which as far as I can see, keycloak > is based on?) as an OAuth provider and just add bearer tokens to the > authentication headers of the HTTP requests between the modules. > > One of the really nice features for us is that the role mapping of users > is included in the tokens (which is also described in the keycloak docs > with a reference to JSON Web Tokens). > > Now the modules that are deployed to JBoss AS transparently verify the > bearer tokens and RESTEasy even takes care of adding the username and > the user roles to the HttpServletRequest which also allows us to use > @RolesAllowed (very convenient!). > > What I'm wondering now is whether there is an easy way of adding > validation and decoding of bearer tokens to Vert.x modules. Ideally, I > would like to be able to add a jar dependency that provides me with a > few methods to validate the token (make sure it is a real token, hasn't > been modified and didn't expire...) and extract the user and roles from > it. Since a private key is needed, I guess I would add a json config > file or even just pass the required values to the API directly. > Don't know anything about vert.x, but if you use the keycloak-core module, it has all the code needed to unmarshal and verify the token. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From stian at redhat.com Wed Jan 29 11:53:01 2014 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 29 Jan 2014 11:53:01 -0500 (EST) Subject: [keycloak-user] Verifying Bearer Tokens in Vert.x In-Reply-To: <52E926E6.9080100@redhat.com> References: <52E926E6.9080100@redhat.com> Message-ID: <1860045553.15609005.1391014381746.JavaMail.root@redhat.com> Have a look at: https://github.com/keycloak/keycloak/blob/master/testsuite/integration/src/test/java/org/keycloak/testsuite/OAuthClient.java#L146 ----- Original Message ----- > From: "Bill Burke" > To: keycloak-user at lists.jboss.org > Sent: Wednesday, 29 January, 2014 4:05:58 PM > Subject: Re: [keycloak-user] Verifying Bearer Tokens in Vert.x > > > > On 1/29/2014 10:58 AM, Nils Preusker wrote: > > Hi everybody, > > > > we are developing an application that consists of several REST > > web-applications written with different application frameworks (Java EE > > 6/ JBoss AS and Vert.x). So far we are > > using org.jboss.resteasy.skeleton.key.as7.OAuthAuthenticationServerValve > > from the skelton-key-as7 template (which as far as I can see, keycloak > > is based on?) as an OAuth provider and just add bearer tokens to the > > authentication headers of the HTTP requests between the modules. > > > > One of the really nice features for us is that the role mapping of users > > is included in the tokens (which is also described in the keycloak docs > > with a reference to JSON Web Tokens). > > > > Now the modules that are deployed to JBoss AS transparently verify the > > bearer tokens and RESTEasy even takes care of adding the username and > > the user roles to the HttpServletRequest which also allows us to use > > @RolesAllowed (very convenient!). > > > > What I'm wondering now is whether there is an easy way of adding > > validation and decoding of bearer tokens to Vert.x modules. Ideally, I > > would like to be able to add a jar dependency that provides me with a > > few methods to validate the token (make sure it is a real token, hasn't > > been modified and didn't expire...) and extract the user and roles from > > it. Since a private key is needed, I guess I would add a json config > > file or even just pass the required values to the API directly. > > > > Don't know anything about vert.x, but if you use the keycloak-core > module, it has all the code needed to unmarshal and verify the token. > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > From n.preusker at gmail.com Thu Jan 30 03:50:55 2014 From: n.preusker at gmail.com (Nils Preusker) Date: Thu, 30 Jan 2014 09:50:55 +0100 Subject: [keycloak-user] Verifying Bearer Tokens in Vert.x In-Reply-To: <1860045553.15609005.1391014381746.JavaMail.root@redhat.com> References: <52E926E6.9080100@redhat.com> <1860045553.15609005.1391014381746.JavaMail.root@redhat.com> Message-ID: Hey Stian, thanks for the link, that's exactly what I was looking for! On Wed, Jan 29, 2014 at 5:53 PM, Stian Thorgersen wrote: > Have a look at: > > > https://github.com/keycloak/keycloak/blob/master/testsuite/integration/src/test/java/org/keycloak/testsuite/OAuthClient.java#L146 > > ----- Original Message ----- > > From: "Bill Burke" > > To: keycloak-user at lists.jboss.org > > Sent: Wednesday, 29 January, 2014 4:05:58 PM > > Subject: Re: [keycloak-user] Verifying Bearer Tokens in Vert.x > > > > > > > > On 1/29/2014 10:58 AM, Nils Preusker wrote: > > > Hi everybody, > > > > > > we are developing an application that consists of several REST > > > web-applications written with different application frameworks (Java EE > > > 6/ JBoss AS and Vert.x). So far we are > > > using > org.jboss.resteasy.skeleton.key.as7.OAuthAuthenticationServerValve > > > from the skelton-key-as7 template (which as far as I can see, keycloak > > > is based on?) as an OAuth provider and just add bearer tokens to the > > > authentication headers of the HTTP requests between the modules. > > > > > > One of the really nice features for us is that the role mapping of > users > > > is included in the tokens (which is also described in the keycloak docs > > > with a reference to JSON Web Tokens). > > > > > > Now the modules that are deployed to JBoss AS transparently verify the > > > bearer tokens and RESTEasy even takes care of adding the username and > > > the user roles to the HttpServletRequest which also allows us to use > > > @RolesAllowed (very convenient!). > > > > > > What I'm wondering now is whether there is an easy way of adding > > > validation and decoding of bearer tokens to Vert.x modules. Ideally, I > > > would like to be able to add a jar dependency that provides me with a > > > few methods to validate the token (make sure it is a real token, hasn't > > > been modified and didn't expire...) and extract the user and roles from > > > it. Since a private key is needed, I guess I would add a json config > > > file or even just pass the required values to the API directly. > > > > > > > Don't know anything about vert.x, but if you use the keycloak-core > > module, it has all the code needed to unmarshal and verify the token. > > > > -- > > Bill Burke > > JBoss, a division of Red Hat > > http://bill.burkecentral.com > > _______________________________________________ > > keycloak-user mailing list > > keycloak-user at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20140130/f5096636/attachment.html From n.preusker at gmail.com Thu Jan 30 06:24:25 2014 From: n.preusker at gmail.com (Nils Preusker) Date: Thu, 30 Jan 2014 12:24:25 +0100 Subject: [keycloak-user] Keycloak and OAuth 2.0 Resource Owner Password Credentials Grant In-Reply-To: <52E92361.5090404@redhat.com> References: <52E90EA6.7020402@redhat.com> <52E91946.5040400@redhat.com> <52E92361.5090404@redhat.com> Message-ID: Hi, I looked at the admin console and examined the HTTP requests and redirects and, as far as I can see, you are using a cookie (KEYCLOAK_SAAS_COOKIE) to exchange the authentication information (OAuth token) between the JavaScript client app and the REST services. Is there a specific reason you chose to use a cookie instead of a bearer token in an authorization header? Also, are you planning to integrate the cookie mechanism as transparently as bearer tokens (transparently validating by configuring web.xml, adding user and roles to HttpServletRequest etc.)? Cheers, Nils On Wed, Jan 29, 2014 at 4:50 PM, Bill Burke wrote: > > > On 1/29/2014 10:32 AM, Nils Preusker wrote: > > Hey, that all sounds pretty good! So far I was a bit reluctant to use a > > third party login screen... But on second thought, the argument of being > > able to add credential types over time without having to change your > > application sounds pretty compelling. > > > > Its not just that. Also each secured app gets "Forgot Password" "Lost > Authenticator" for free. Admin console can also force users to change > their password or update their authenticator. > > > Would you be interested in working together on a small AngularJS example > > to showcase the integration of keycloak and client side web-applications? > > > > We support this already. Keycloak Admin console is actually written in > Angular JS. We have two flavors for client side web apps. > > * App's Server manages Keycloak interaction. Token is stored in the > Http Session. Client can obtain token after authentication by a REST > call to the App's Server. Keycloak Admin console uses this form. > > * Pure client side app. Stian has written a JS lib for this. basically > performs all the same OAuth redirect protocol. Client (in addition to > the user) is authenticated by checking/matching redirect URIs. This > requires CORS set up though (which we also support). > > For CORS we only support "validated CORS" currently. The auth token > contains the authorized origins which are validated on CORS requests. > Next release we want the App's Server to query the Keycloak admin server > for valid origins. This way you can make unauthenticated CORS requests > which can sstill protect against XSS. > > We need to put an example and docs for all of this for the next release. > > Bill > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20140130/cb36f0d2/attachment.html From bburke at redhat.com Thu Jan 30 08:30:25 2014 From: bburke at redhat.com (Bill Burke) Date: Thu, 30 Jan 2014 08:30:25 -0500 Subject: [keycloak-user] Keycloak and OAuth 2.0 Resource Owner Password Credentials Grant In-Reply-To: References: <52E90EA6.7020402@redhat.com> <52E91946.5040400@redhat.com> <52E92361.5090404@redhat.com> Message-ID: <52EA53F1.1050205@redhat.com> On 1/30/2014 6:24 AM, Nils Preusker wrote: > Hi, > > I looked at the admin console and examined the HTTP requests and > redirects and, as far as I can see, you are using a cookie > (KEYCLOAK_SAAS_COOKIE) to exchange the authentication information (OAuth > token) between the JavaScript client app and the REST services. > > Is there a specific reason you chose to use a cookie instead of a bearer > token in an authorization header? > The cookie, if you see, is Http-only. So, the browser app has no access to the token and can't be hit with Javascript attacks. This is all very specific to the admin console which assumes that it is not running in a servlet container and getting a HttpSession. For servlet apps (and those with a http session), token can be stored in the HTTP session and the browser app just makes rest invocations that are validated against the http session. This of course, doesn't quite work well if the browser needs to make CORS requests. So, there's also a REST invocation that you can turn on in the adapter that allows the client to get the token. Or, you can just use the pure Javascript lib that Stian wrote for pure HTML5 clients. > Also, are you planning to integrate the cookie mechanism as > transparently as bearer tokens (transparently validating by configuring > web.xml, adding user and roles to HttpServletRequest etc.)? > Not sure what you mean by that. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From n.preusker at gmail.com Thu Jan 30 09:29:01 2014 From: n.preusker at gmail.com (Nils Preusker) Date: Thu, 30 Jan 2014 15:29:01 +0100 Subject: [keycloak-user] Keycloak and OAuth 2.0 Resource Owner Password Credentials Grant In-Reply-To: <52EA53F1.1050205@redhat.com> References: <52E90EA6.7020402@redhat.com> <52E91946.5040400@redhat.com> <52E92361.5090404@redhat.com> <52EA53F1.1050205@redhat.com> Message-ID: Hey Bill, thanks for the clarification, I didn't realize that the cookie was Http-only, neat! We are building a pure HTML5 client that is also hosted separately from the REST-backends. The thing is that we use a reverse proxy so for the browser it all looks like one app since everything comes from different paths in the same domain. I'll try to clarify the last part of my last mail: We are currently using org.jboss.resteasy.skeleton.key.as7.OAuthAuthenticationServerValve (skeleton-key-as7) in our REST-backend modules. If I'm not mistaken, some parts of the code base and concepts are the same as in keycloak, right? So far, in the AngularJS application we've been adding bearer tokens to the HTTP Authorization header. Since the backend uses JAX-RS/ RestEasy, the verification of the bearer tokens was done transparently by OAuthAuthenticationServerValve and RESTEasy automatically added the roles etc. to the HttpServletRequest. Now in the REST backend of the admin app in keycloak you're doing the same thing (validating the tokens and extracting the roles) manually with the AuthenticationManager (authenticateSaasIdentityCookie(...)). So I was just wondering whether you are planning to make that process more transparent in the future? I think it would be nice to be able to write REST services with @RolesAllowed etc. Does that make more sense? Cheers! Nils On Thu, Jan 30, 2014 at 2:30 PM, Bill Burke wrote: > > > On 1/30/2014 6:24 AM, Nils Preusker wrote: > > Hi, > > > > I looked at the admin console and examined the HTTP requests and > > redirects and, as far as I can see, you are using a cookie > > (KEYCLOAK_SAAS_COOKIE) to exchange the authentication information (OAuth > > token) between the JavaScript client app and the REST services. > > > > Is there a specific reason you chose to use a cookie instead of a bearer > > token in an authorization header? > > > > The cookie, if you see, is Http-only. So, the browser app has no access > to the token and can't be hit with Javascript attacks. This is all very > specific to the admin console which assumes that it is not running in a > servlet container and getting a HttpSession. > > For servlet apps (and those with a http session), token can be stored in > the HTTP session and the browser app just makes rest invocations that > are validated against the http session. > > This of course, doesn't quite work well if the browser needs to make > CORS requests. So, there's also a REST invocation that you can turn on > in the adapter that allows the client to get the token. Or, you can > just use the pure Javascript lib that Stian wrote for pure HTML5 clients. > > > Also, are you planning to integrate the cookie mechanism as > > transparently as bearer tokens (transparently validating by configuring > > web.xml, adding user and roles to HttpServletRequest etc.)? > > > > Not sure what you mean by that. > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20140130/0211a987/attachment-0001.html From bburke at redhat.com Thu Jan 30 10:46:52 2014 From: bburke at redhat.com (Bill Burke) Date: Thu, 30 Jan 2014 10:46:52 -0500 Subject: [keycloak-user] Keycloak and OAuth 2.0 Resource Owner Password Credentials Grant In-Reply-To: References: <52E90EA6.7020402@redhat.com> <52E91946.5040400@redhat.com> <52E92361.5090404@redhat.com> <52EA53F1.1050205@redhat.com> Message-ID: <52EA73EC.3010909@redhat.com> On 1/30/2014 9:29 AM, Nils Preusker wrote: > Hey Bill, thanks for the clarification, I didn't realize that the cookie > was Http-only, neat! > > We are building a pure HTML5 client that is also hosted separately from > the REST-backends. The thing is that we use a reverse proxy so for the > browser it all looks like one app since everything comes from different > paths in the same domain. > > I'll try to clarify the last part of my last mail: We are currently > using org.jboss.resteasy.skeleton.key.as7.OAuthAuthenticationServerValve > (skeleton-key-as7) in our REST-backend modules. If I'm not mistaken, > some parts of the code base and concepts are the same as in keycloak, right? > > So far, in the AngularJS application we've been adding bearer tokens to > the HTTP Authorization header. Since the backend uses JAX-RS/ RestEasy, > the verification of the bearer tokens was done transparently by > OAuthAuthenticationServerValve and RESTEasy automatically added the > roles etc. to the HttpServletRequest. Now in the REST backend of the > admin app in keycloak you're doing the same thing (validating the tokens > and extracting the roles) manually with the AuthenticationManager > (authenticateSaasIdentityCookie(...)). So I was just wondering whether > you are planning to make that process more transparent in the future? > We're doing it manually because the original idea was that the admin service could manage multiple organizations (a SaaS), so you'd have to set up the cookie path's correctly. For your app, it sounds like @RolesAllowed will work. You just have to set up the appropriate web.xml security constraints for your REST urls in web.xml. Just set up the REST apis to require authentication and let @RolesAllowed do the rest. The keycloak jboss/wildfly adapter can handle BEARER token auth at the same time as regular browser oauth. If the server is initiating the login, then you can just follow the current keycloak examples. If not, then the Javascript lib Stian wrote is an option (and something we'll have to document). -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From stian at redhat.com Thu Jan 30 11:23:00 2014 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 30 Jan 2014 11:23:00 -0500 (EST) Subject: [keycloak-user] Keycloak and OAuth 2.0 Resource Owner Password Credentials Grant In-Reply-To: <52EA73EC.3010909@redhat.com> References: <52E91946.5040400@redhat.com> <52E92361.5090404@redhat.com> <52EA53F1.1050205@redhat.com> <52EA73EC.3010909@redhat.com> Message-ID: <351215940.16537136.1391098980154.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Bill Burke" > To: keycloak-user at lists.jboss.org > Sent: Thursday, 30 January, 2014 3:46:52 PM > Subject: Re: [keycloak-user] Keycloak and OAuth 2.0 Resource Owner Password Credentials Grant > > > > On 1/30/2014 9:29 AM, Nils Preusker wrote: > > Hey Bill, thanks for the clarification, I didn't realize that the cookie > > was Http-only, neat! > > > > We are building a pure HTML5 client that is also hosted separately from > > the REST-backends. The thing is that we use a reverse proxy so for the > > browser it all looks like one app since everything comes from different > > paths in the same domain. > > > > I'll try to clarify the last part of my last mail: We are currently > > using org.jboss.resteasy.skeleton.key.as7.OAuthAuthenticationServerValve > > (skeleton-key-as7) in our REST-backend modules. If I'm not mistaken, > > some parts of the code base and concepts are the same as in keycloak, > > right? > > > > So far, in the AngularJS application we've been adding bearer tokens to > > the HTTP Authorization header. Since the backend uses JAX-RS/ RestEasy, > > the verification of the bearer tokens was done transparently by > > OAuthAuthenticationServerValve and RESTEasy automatically added the > > roles etc. to the HttpServletRequest. Now in the REST backend of the > > admin app in keycloak you're doing the same thing (validating the tokens > > and extracting the roles) manually with the AuthenticationManager > > (authenticateSaasIdentityCookie(...)). So I was just wondering whether > > you are planning to make that process more transparent in the future? > > > > We're doing it manually because the original idea was that the admin > service could manage multiple organizations (a SaaS), so you'd have to > set up the cookie path's correctly. > > For your app, it sounds like @RolesAllowed will work. You just have to > set up the appropriate web.xml security constraints for your REST urls > in web.xml. Just set up the REST apis to require authentication and let > @RolesAllowed do the rest. The keycloak jboss/wildfly adapter can > handle BEARER token auth at the same time as regular browser oauth. If > the server is initiating the login, then you can just follow the current > keycloak examples. If not, then the Javascript lib Stian wrote is an > option (and something we'll have to document). JS lib needs a bit of work as well, if it's something you want I can make it a priority > > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user >