Re: [keycloak-dev] Better support for "scope" in adapters

+1 On Thu, Jan 31, 2019 at 11:14 AM Marek Posolda <mposolda(a)redhat.com&gt; wrote: > On 31/01/2019 14:07, Pedro Igor Silva wrote: > > This what I like most about client scopes (in addition to all mapping you > do to claims in the tokens) :) Would also make sense to do the same thing > to client scopes ? So clients requesting "foo" would also get "bar" and > "xpto", for instance ? > > Maybe this could avoid the client to request 10 scopes but just a more > coarse-grained scope representing all of them. > > There is opened JIRA for client scopes inheritance > https://issues.jboss.org/browse/KEYCLOAK-6633 . I believe this will cover > what you have in mind? It's just not yet done... > > Marek > > > > On Thu, Jan 31, 2019 at 10:43 AM Marek Posolda <mposolda(a)redhat.com&gt; > wrote: > >> On 30/01/2019 14:40, Pedro Igor Silva wrote: >> >> >> >> On Wed, Jan 30, 2019 at 5:25 AM Marek Posolda <mposolda(a)redhat.com&gt; >> wrote: >> >>> On 29/01/2019 19:49, Pedro Igor Silva wrote: >>> >>> I'm not sure if we need to consider that in our adapters. >>> >>> Usually, the front-end knows the set of scopes that it needs to interact >>> with the backend and stay functional. >>> >>> Maybe. I am personally not sure how people expect to use "scope" >>> parameters in their frontend applications. Maybe 90% of frontend clients >>> don't need to use "scope" parameter at all. And from the remaining, they >>> will be fine with the current support of the "scope" parameter. >>> >> I would say so, mainly because I think people are still using RBAC to >> enforce access to APIs. Enterprise scenarios don't really use scopes as >> they are more related with delegation. >> >> Yeah, maybe. Just a note that our client scopes support also allows to >> limit roles in the token. For example you can define role scope mappings of >> client scope "service1" to have role "service1.my-service1-role" . So by >> requesting "scope=service1", you will also receive this role in the token >> and hence can be used for RBAC based authorization. >> >> But anyway, I probably won't create any JIRAs for now. Will wait if there >> is some more feedback or some more requests for better support of "scope" >> parameter in the adapters. >> >> Thanks for the feedback Pedro! >> >> Marek >> >> One possibility, where I can see usage of this, is when frontend client >>> wants to invoke multiple different services and he wants to use different >>> access tokens with properly "isolated" audiences. So for example you want >>> to have: >>> >>> - access token with "scope=service1", which will have in itself audience >>> claim "aud: service1" and you will use it to invoke backend service1 >>> - access token with "scope=service2", which will have in itself audience >>> claim "aud: service2" and you will use it to invoke backend service2 >>> >>> In this case, having the possibility for adapters to "cache" multiple >>> tokens for various scopes can be beneficial IMO, so client can easily >>> retrieve proper access token based on the service he wants to invoke. >>> >>> And the backend by itself is free to exchange tokens to call other >>> services (service chaining). >>> >>> Don't think that brings a lot of complexity to the front-end and, >> probably, indicates a bad design? >> >>> IMO in many cases, you're right. For example when frontend client uses >>> access token to invoke backend "service1", this backend may want to >>> retrieve some other data from "service11". So service1 backend needs to >>> reuse the token or he wants to exchange this token. >>> >>> But in many cases, you want to avoid this. So in my example above, when >>> you have access token with "aud: service1", you want this access token to >>> be used solely to invoke service1. You don't want to have one huge access >>> token, which will have all the audiences like: >>> >>> aud: [ "service1", "service2" ] >>> >> The access token is also tied with the client, what means "this client is >> allowed to invoke service1 and service2". I usually don't see a problem on >> that if you consider that multiple audiences mean that a high degree of >> trust between the parties involved. What I think is true for most >> enterprise use cases where the front-end is basically accessing internal >> services. >> >> It is also worthy to consider, IMO, that the fact that you have distinct >> services, does not mean they are not part of the same API, thus the same >> audience. >> >>> You may want separate access tokens with isolated audiences exactly >>> because you don't want service1 and service2 to be able to invoke each >>> other. IMO this isolation is one of the main usages of the "aud" claim in >>> the tokens. >>> >>> >>> One thing that makes sense though is "incremental authorization" and >>> allow apps to request additional scopes during an authentication session, >>> so the app gets what was previously granted and the new scopes (depending >>> on user consent). But I think we support that already, right ? >>> >>> We don't support it directly and maybe this is something to improve. ATM >>> you will need programatically do something like this: >>> >>> String existingScope = existingAccessToken.getScope(); >>> >>> // I want to use existingScope and add "phone" scope to it >>> String newScope = existingScope + " phone"; >>> >>> // Request the login for new scope now >>> >>> >>> The part of "requesting login for new scope" is possible with javascript >>> adapter, but not easily with the "java" adapter. With java adapter, there >>> is no easy way to manually "build" URL to sent to OIDC authentication >>> endpoint (equivalent of keycloak.js method "createLoginUrl"). That's also >>> one of the things, which I proposed to improve in this email thread. >>> >> Marek >>> >>> >>> Regards. >>> Pedro Igor >>> >>> On Tue, Jan 29, 2019 at 9:36 AM Marek Posolda <mposolda(a)redhat.com&gt; >>> wrote: >>> >>>> During my work on Client Scopes last year, I did not any work on the >>>> adapters side. I think there is a space for improvement here. I will >>>> try >>>> to summary current issues and some initial proposals for improve >>>> things. >>>> Suggestions welcomed! And sorry for longer email :) >>>> >>>> >>>> Both javascript adapter and servlet adapter has some way for requesting >>>> the additional "scope" and ensure that that initial OIDC authentication >>>> request sent to Keycloak will contain some custom "scope" parameter. >>>> The >>>> javascript adapter has support for "scope" as an option of the "login" >>>> method [1]. The servlet adapter has a possibility to inject custom >>>> "scope" with parameters forwarding [2]. I am not sure about node.js and >>>> other adapters TBH. But even for javascript and servlet adapter, the >>>> current support is quite limited for few reasons. For example: >>>> >>>> - The approach of parameters forwarding used in servlet adapters >>>> requires to logout before requesting the additional scope. Because >>>> when >>>> I am already authenticated in the application and I open secured URL >>>> like http://localhost/app/secured?scope=some-custom-scope, the adapter >>>> will just ignore it in case that user is already logged-in and it will >>>> automatically forward to the application. >>>> >>>> - Both servlet and javascript adapters support to have just single >>>> "triplet" of tokens per browser session. In this context "triplet" >>>> means >>>> the single set of 3 tokens (ID token , Access Token , Refresh token). >>>> So >>>> for example when I want to request the custom scope for being able to >>>> invoke "service1", I can use "scope=service1". However after Keycloak >>>> redirects me back to the application, the existing triplet of tokens is >>>> just replaced with the new one for "service1" . Then when I want to >>>> later invoke another service like "service2", I need to request the >>>> additional scope "scope=service2", which will replace my tokens on the >>>> adapter's side with the "service2" tokens . But then later when I want >>>> to switch again to "service1", I need to redirect to Keycloak again as >>>> the current triplet of tokens for "service1" etc. >>>> >>>> >>>> To improve this limitation, I think that it will be good if adapters >>>> easily support the following: >>>> >>>> - Instead of having single triplet of tokens, it will be good if >>>> adapters can contain Map of tokens. Key of the map can be "scope" >>>> parameter. So for example, the adapter will have "default" tokens >>>> (those, which were used for initial login), the tokens for "service1" >>>> and the tokens for "service2" . >>>> >>>> - It will be nice if there is easy way to ask adapter for "service1" >>>> scope. In case that I don't have yet this scope, adapter will redirect >>>> me to Keycloak with "scope=service1". If I already have it, adapter >>>> will >>>> return me an existing token. If existing access token is expired, >>>> adapter will refresh the access token for requested scope in the >>>> background and return me the "updated" token. >>>> >>>> - When I want to invoke service1 and I need to use "scope=service1", I >>>> usually need just access token and refresh token. I don't need ID Token >>>> anymore. I also don't need the "profile" and "email" claims to be >>>> returned in the new access token. This is related to the JIRA of having >>>> the server-side support for client scopes like (always, default, >>>> optional) instead of current (default, optional) [3]. In other words, >>>> the client scopes "profile" and "email" will be default client scopes, >>>> which means that if I don't use "scope=openid" in the OIDC initial >>>> request, the "profile" and "email" will be ommited from the response as >>>> well as the ID Token will be ommited from the response. >>>> >>>> >>>> So how to support this on adapters? For Keycloak.js, I can think about >>>> some variation of existing "update" method like this: >>>> >>>> >>>> keycloak.updateTokenWithScope('service1', >>>> 5).success(function(accessToken, refreshed) { >>>> if (refreshed) { >>>> alert("I had existing accessToken for scope 'service1', >>>> but >>>> it needed to be refreshed as it was expired or about to expire in less >>>> than 5 seconds"); >>>> } else { >>>> alert('I have accessToken for 'service1', which didn't >>>> need to be refreshed'); >>>> } >>>> // I can invoke REST service now with the accessToken >>>> ... >>>> }).error(function() { >>>> alert("Failed to refresh the token OR I don't have yet scope >>>> for 'service1' ."); >>>> // User usually need to call keycloak.login with the requested >>>> scope now... >>>> }); >>>> >>>> >>>> >>>> >>>> For servlet adapter something like: >>>> >>>> KeycloakSecurityContext ctx = ... // Retrieved from HttpServletRequest >>>> or Principal as currently >>>> >>>> if (ctx.hasScope("service1")) { >>>> try { >>>> String accessToken = ctx.getScope("service1"); >>>> // Invoke service1 with accessToken now >>>> } catch (TokenRefreshException ex) { >>>> log.error("I already had scope for service1, but failed to >>>> refresh the token. Need to re-login for the scope service1"); >>>> >>>> // See method below >>>> redirectToKeycloakWithService1Scope(); >>>> } >>>> } else { >>>> // See method below >>>> redirectToKeycloakWithService1Scope(); >>>> } >>>> >>>> >>>> private void redirectToKeycloakWithService1Scope() { >>>> KeycloakRedirectUriBuilder builder = ctx.createLoginUrl(); >>>> URL url = builder.scope("service1").build(); >>>> httpServletResponse.sendRedirect(url); >>>> } >>>> >>>> >>>> Regarding the class KeycloakRedirectUriBuilder, I was thinking about >>>> this class so that servlet adapter are able to easily create login URL >>>> with custom values for things like scope, prompt, max_age etc. This >>>> capability is currently missing in servlet adapters and the current >>>> approach based on parameters forwarding is a bit clunky for few >>>> reasons. >>>> One reason is usability and the other is, that you need to logout first. >>>> >>>> >>>> [1] >>>> >>>> https://www.keycloak.org/docs/latest/securing_apps/index.html#javascript-... >>>> [2] >>>> >>>> https://www.keycloak.org/docs/latest/securing_apps/index.html#_params_for... >>>> [3] https://issues.jboss.org/browse/KEYCLOAK-8323 >>>> >>>> Marek >>>> >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >>> >>> >> > _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev