9:21 a.m.
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(a)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(a)redhat.com
> <mailto:bburke@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(a)gmail.com <mailto:rodrigopsasaki@gmail.com>
> <mailto:rodrigopsasaki@gmail.com
<mailto:rodrigopsasaki@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(a)cisco.com <mailto:vivsriva@cisco.com>
> <mailto:vivsriva@cisco.com <mailto:vivsriva@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(a)gmail.com
> <mailto:rodrigopsasaki@gmail.com>
> > <mailto:rodrigopsasaki@gmail.com
>
> <mailto:rodrigopsasaki@gmail.com>>>
> > Date: Tuesday, July 29, 2014 at 12:51 PM
> > To: Bill Burke <bburke(a)redhat.com
> <mailto:bburke@redhat.com> <mailto:bburke@redhat.com
>
> <mailto:bburke@redhat.com>>>
> > Cc: "keycloak-user(a)lists.jboss.org
> <mailto:keycloak-user@lists.jboss.org>
> > <mailto:keycloak-user@lists.jboss.org
>
> <mailto:keycloak-user@lists.jboss.org>>"
> > <keycloak-user(a)lists.jboss.org
> <mailto:keycloak-user@lists.jboss.org>
> > <mailto:keycloak-user@lists.jboss.org
>
> <mailto:keycloak-user@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(a)redhat.com <mailto:bburke@redhat.com>
> > <mailto:bburke@redhat.com
<mailto:bburke@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(a)lists.jboss.org
> <mailto:keycloak-user@lists.jboss.org>
> > <mailto:keycloak-user@lists.jboss.org
>
> <mailto:keycloak-user@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@lists.
> jboss.org>
> > <mailto:keycloak-user@lists.jboss.org
>
> <mailto:keycloak-user@lists.jboss.org>>
> > https://lists.jboss.org/mailman/listinfo/keycloak-user
> >
> >
> >
> >
> > --
> > Rodrigo Sasaki
> >
> >
> >
> >
> > --
> > Rodrigo Sasaki
> >
> >
> >
> >
> > --
> > Rodrigo Sasaki
> >
> >
> > _______________________________________________
> > keycloak-user mailing list
> > keycloak-user(a)lists.jboss.org <mailto:keycloak-user@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@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