[keycloak-user] Bearer Only Application access with token

Rodrigo Sasaki rodrigopsasaki at gmail.com
Wed Aug 6 10:21:13 EDT 2014


Oh, that was it. The client needs to have the roles from the application, I
didn't think of that.

Thank you again

copying back the mailing-list because I didn't reply to it by mistake


On Wed, Aug 6, 2014 at 11:18 AM, Bill Burke <bburke at redhat.com> wrote:

> The security-admin-console has a limited scope, so the access token
> doesn't get populated with the roles you desire.  A quick workaround is to
> go to the Scope page on the security-admin-console and click "Full scope
> allowed".
>
> IMO, instead, you should create an oauth client and assign the scope you
> want for that client_id.  This allows you to:
>
> * Reduce the size of the access token created for that client_id
> * Limit the roles that tokens created for that client_id can obtain.
>
> Scope is really an extra security measure.  For example, with scope, you
> can enforce that only the security-console-application can ever get get
> tokens that have admin roles within it.
>
> On 8/6/2014 10:10 AM, Rodrigo Sasaki wrote:
>
>> I get the token sending a POST using *security-admin-console* as
>> *client_id*.
>>
>>
>> The application I'm trying to access is bearer only, so I can't generate
>> a token directly for it
>>
>>
>> On Wed, Aug 6, 2014 at 11:06 AM, Bill Burke <bburke at redhat.com
>> <mailto:bburke at redhat.com>> wrote:
>>
>>     How do you obtain the token?  Access tokens are created specifically
>> for
>>     the application/oauth client that intiated the token protocol.  So the
>>     access token will be stuffed with only the role mappings for that
>>     application/oauth client.  A bearer-only application doesn't need a
>>     scope configured because it never initiates a login.
>>
>>     I changed things in beta 4 to hopefully mitigate the confusion around
>>     "scope".  Applications have a full scope enabled by default now.
>>
>>     On 8/6/2014 9:58 AM, Rodrigo Sasaki wrote:
>>      > Is there any news on this? I tried it on beta-4 on wildfly and I
>>     still
>>      > get the same response.
>>      >
>>      >
>>      > On Tue, Jul 29, 2014 at 5:56 PM, Rodrigo Sasaki
>>      > <rodrigopsasaki at gmail.com <mailto:rodrigopsasaki at gmail.com>
>>     <mailto:rodrigopsasaki at gmail.com <mailto:rodrigopsasaki at gmail.com>>>
>>
>>     wrote:
>>      >
>>      >     I made sure of all that, I just recreated everything using
>> realm
>>      >     roles just for the sake of completeness, but I'm still
>>     getting a 403
>>      >
>>      >
>>      >     On Tue, Jul 29, 2014 at 4:09 PM, Vivek Srivastav (vivsriva)
>>      >     <vivsriva at cisco.com <mailto:vivsriva at cisco.com>
>>     <mailto:vivsriva at cisco.com <mailto:vivsriva at cisco.com>>> wrote:
>>      >
>>      >         Make sure you have the following settings configured for
>> your
>>      >         database service:
>>      >
>>      >
>>      >
>>      >
>>      >
>>      >         In the web.xml, make sure you have the security setup
>>     with the
>>      >         appropriate user role:
>>      >         <?xml version="1.0" encoding="UTF-8"?>
>>      >         <web-app xmlns="http://java.sun.com/xml/ns/javaee"
>>      >                xmlns:xsi="http://www.w3.org/
>> 2001/XMLSchema-instance"
>>      >                xsi:schemaLocation="http://
>> java.sun.com/xml/ns/javaee
>>      > http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
>>      >                version="3.0">
>>      >
>>      >         <module-name>database</module-name>
>>      >              <security-constraint>
>>      >                  <web-resource-collection>
>>      >                      <url-pattern>/*</url-pattern>
>>      >                  </web-resource-collection>
>>      >         <!--        <user-data-constraint>
>>      >
>>       <transport-guarantee>CONFIDENTIAL</transport-guarantee>
>>      >                  </user-data-constraint>  -->
>>      >                  <auth-constraint>
>>      >                      <role-name>user</role-name>
>>      >                  </auth-constraint>
>>      >              </security-constraint>
>>      >
>>      >              <login-config>
>>      >                  <auth-method>KEYCLOAK</auth-method>
>>      >                  <realm-name>demo</realm-name>
>>      >              </login-config>
>>      >
>>      >              <security-role>
>>      >                  <role-name>user</role-name>
>>      >              </security-role>
>>      >         </web-app>
>>      >
>>      >
>>      >
>>      >         From: Rodrigo Sasaki <rodrigopsasaki at gmail.com
>>     <mailto:rodrigopsasaki at gmail.com>
>>      >         <mailto:rodrigopsasaki at gmail.com
>>
>>     <mailto:rodrigopsasaki at gmail.com>>>
>>      >         Date: Tuesday, July 29, 2014 at 12:51 PM
>>      >         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>>"
>>      >         <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>>>
>>      >         Subject: Re: [keycloak-user] Bearer Only Application
>>     access with
>>      >         token
>>      >
>>      >         It is defined under the application itself, so I it's
>>     under the
>>      >         scope. This should be working right?
>>      >
>>      >
>>      >         On Tue, Jul 29, 2014 at 11:59 AM, Bill Burke
>>     <bburke at redhat.com <mailto:bburke at redhat.com>
>>      >         <mailto:bburke at redhat.com <mailto:bburke at redhat.com>>>
>> wrote:
>>      >
>>      >             What kind of role is it?  Is the new role defined
>>     under the
>>      >             "database-service" application?  If not, then you
>>     must add
>>      >             this role to
>>      >             the "database-service"'s scope in the admin console.
>>      >
>>      >             On 7/29/2014 10:51 AM, Rodrigo Sasaki wrote:
>>      >             > Hi,
>>      >             >
>>      >             > I'm trying to secure a bearer-only application with
>>     keycloak, to access
>>      >             > it with access tokens, but I think I'm missing
>>     something.
>>      >             >
>>      >             > I tried it with the database-service of the
>>     unconfigured demo.
>>      >             >
>>      >             > 1. I created the user role in the application.
>>      >             > 2. I assigned that role to my user
>>      >             > 3. I copied the contents of the installation json to
>>      >             > *webapp/META-INF/keycloak.json*
>>      >             >
>>      >             > {
>>      >             >      "realm": "demo",
>>      >             >      "realm-public-key":
>>      >             >
>>     "MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCwRayjzh7W+
>> EfPaeSdyXWLyXof7c3fwD7vb0AEtG+ogLHtMkYiTdX9y/
>> JXOmXwWDzGhx7NM3Q6vkCG0F3lZqOVsSlYH56c5+Ev4QmSGK/+6e+WcZMcgmscoz1OoXKom4+
>> pzqMey42hqdwwMhkvCq/jxJSmUGnZJQuqEKVH00NZ1wIDAQAB",
>>      >             >      "bearer-only": true,
>>      >             >      "ssl-not-required": true,
>>      >             >      "resource": "database-service",
>>      >             >      "use-resource-role-mappings": true
>>      >             > }
>>      >             >
>>      >             > 4. Set the auth-method to *KEYCLOAK* on web.xml
>>      >             > 5. Started the server deploying the
>> *database-service*
>>      >             > 6. Generated a token using *security-admin-console*
>>     client_id and my user
>>      >             > 7. Submitted a GET request to
>>     /localhost:8080/database/customers/
>>      >             >
>>      >             > After these steps I get a 403 error, saying that
>>     I'm not authorized to
>>      >             > access the resource, wasn't this supposed to work?
>>      >             >
>>      >             > --
>>      >             > Rodrigo Sasaki
>>      >             >
>>      >             >
>>      >             > _______________________________________________
>>      >             > 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
>>      >
>>      >
>>      >
>>      >
>>      >         --
>>      >         Rodrigo Sasaki
>>      >
>>      >
>>      >
>>      >
>>      >     --
>>      >     Rodrigo Sasaki
>>      >
>>      >
>>      >
>>      >
>>      > --
>>      > Rodrigo Sasaki
>>      >
>>      >
>>      > _______________________________________________
>>      > keycloak-user mailing list
>>      > keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.
>> jboss.org>
>>
>>      > https://lists.jboss.org/mailman/listinfo/keycloak-user
>>      >
>>
>>     --
>>     Bill Burke
>>     JBoss, a division of Red Hat
>>     http://bill.burkecentral.com
>>     _______________________________________________
>>     keycloak-user mailing list
>>     keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>>
>>
>>
>> --
>> Rodrigo Sasaki
>>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>



-- 
Rodrigo Sasaki
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20140806/819efe21/attachment-0001.html 


More information about the keycloak-user mailing list