[prev in list] [next in list] [prev in thread] [next in thread] 

List:       keycloak-user
Subject:    [keycloak-user] (no subject)
From:       stian () redhat ! com (Stian Thorgersen)
Date:       2014-10-17 6:50:55
Message-ID: 525328148.70412497.1413528655298.JavaMail.zimbra () redhat ! com
[Download RAW message or body]

Makes sense to add new roles granted to the user. I don't think we should add more \
roles if added to the scope of the application. Also, in the future if/when we add \
support for scope query param, we need to remember that so we don't add roles the \
application didn't request. This would also fix the similar issue we have with the \
admin console, and allow us to use the token directly instead of whoAmI to get \
permitted roles.

What should happen if a role is removed from the user? For consistency it should just \
remove the role from the token, but if an application doesn't recheck the roles in \
the refreshed token it may potentially miss the revocation of the role and still \
provide access to it.

----- Original Message -----
> From: "Corinne Krych" <corinnekrych at gmail.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-user at lists.jboss.org
> Sent: Thursday, 16 October, 2014 8:54:15 PM
> Subject: Re: [keycloak-user] (no subject)
> 
> I missed the ?direct grants only OAuth client? mentioned in original mail.
> Isn?t a direct grant oauth client as trusted as application?
> 
> ++
> Corinne
> On 16 Oct 2014, at 20:04, Bill Burke <bburke at redhat.com> wrote:
> 
> > Applications are "trusted" in Keycloak and don't require the consent
> > screen.  So, I think we should allow roles to be updated on a request.
> > 
> > On 10/16/2014 1:47 PM, Corinne Krych wrote:
> > > Hello Alarik,
> > > 
> > > Interesting use case, I would I thought like you that the newly
> > > refreshed access token would contain the new role grant, but reading the
> > > spec:
> > > http://tools.ietf.org/html/rfc6749#section-1.5
> > > 
> > > refresh tokens are issued to the client by the authorization server
> > > and are
> > > used to obtain a new access token when the current access token
> > > becomes invalid or expires, or to obtain additional access tokens
> > > *with identical or narrower scope* (access tokens may have a shorter
> > > lifetime and fewer permissions than authorized by the resource
> > > owner).
> > > 
> > > Some how makes sense to have to approved the new grants.
> > > I need to check how it behaves with OAuth2 providers like Google?
> > > 
> > > ++
> > > Corinne
> > > ??????
> > > AeroGear iOS team
> > > 
> > > On 16 Oct 2014, at 19:17, Bill Burke <bburke at redhat.com
> > > <mailto:bburke at redhat.com>> wrote:
> > > 
> > > > 
> > > > 
> > > > On 10/16/2014 12:50 PM, Alarik Myrin wrote:
> > > > > I am having a strange situation, which might be arising from a bug in
> > > > > Keycloak.
> > > > > 
> > > > > I have a direct grants only OAuth client which makes invocations against
> > > > > a bearer-only REST interface, running on Wildfly 8.0.0 Final with
> > > > > Keycloak 1.0 final.
> > > > > 
> > > > > A side effect of making one of the invocations is that the user is added
> > > > > to a realm role. So far so good.  The access token used to make that
> > > > > invocation though does not contain the new realm role so he cannot, yet,
> > > > > make invocations against another endpoint (call it endpoint B) without
> > > > > getting a 403 Forbidden. This is expected.
> > > > > 
> > > > > So, the client has to refresh the access token
> > > > > (realms/{realm}/tokens/refresh), in order to get a new access token with
> > > > > the realm role.  The refresh goes OK, but when he tries to make
> > > > > invocations against endpoint B, he still gets a 403 Forbidden.
> > > > > 
> > > > 
> > > > Keycloak will only populate the refreshed token with the original
> > > > granted roles.  The idea is that there may have been consent involved
> > > > and the user can't consent to any newly added roles.
> > > > 
> > > > I guess we could change it in that if the client is an application and
> > > > not an oauth client, it would get the new roles.
> > > > 
> > > > --
> > > > 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
> > > 
> > 
> > --
> > 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


[prev in list] [next in list] [prev in thread] [next in thread]