[keycloak-dev] Audience support

[Marek Posolda]

Cool, should have audience PR ready in next few days then. Will create 
"future" version JIRA for the "Resource" specs.

Marek

On 10/09/18 09:21, Stian Thorgersen wrote:
> As aud field is widely used today that is what we need now. I haven't 
> seen anyone ask for [2] so I think we can safely ignore that spec for 
> now.
>
> I would finish what you have with aud support for now, then we can 
> address [2] in the future if needed.
>
> On Thu, 6 Sep 2018 at 23:37, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     Hi,
>
>     I have some concerns about the audience support. The prototype
>     done few
>     months ago, which I have in my branch [1] is based on client
>     scopes. I
>     showed it on the weekly demo some time ago and changed few things
>     based
>     on the feedback. Just to clarify, the PR:
>     - Adds the AudienceProtocolMapper, which is able to attach single
>     client_id of the specified client (typically will be bearer-only
>     client)
>
>     - Adds the easy way to generate "audience client scope" for specified
>     "service" client (usually bearer-only client). This clientScope
>     contains:
>     -- the audienceProtocolMapper of bearer-only described above
>     -- the scope role mappings of all the client roles of that
>     bearer-only
>     client.
>     The "frontend" clients can then use this clientScope, so that
>     audience +
>     roleMappings will be both available in the accessToken issued for the
>     frontend-client.
>
>     Now there is this specs [2], which Pedro pointed. Short summary about
>     this specs:
>
>     - It is still in draft state for few years and there are some TODO in
>     it. So hard to say how much to rely on it...
>
>     - It specifically talks about "scope" parameter and mentions, that
>     it is
>     often used by various parties for "what the token can be used for"
>     (permissions/claims associated with the token) and "where to use that
>     token" . But it mentions that "where" use-case should be ideally
>     handled
>     by something else.
>
>     - It introduces "resource" parameter, which MUST be an absolute
>     URI per
>     this specification and it should point to the service/resource
>     where the
>     access token will be used. When authorization server is creating
>     token,
>     it may apply audiences, encrypt token by various algorithms based
>     on the
>     requested "resource" etc. For the audience, they specify that:
>
>     "The authorization server may use the exact 'resource' value as the
>     audience or it may map from that value to a more general URI or
>     abstract
>     identifier for the resource server."
>
>     - The "resource" parameter is used in the token request if
>     possible. For
>     the grants where it's not possible (implicit, resource owner password
>     login, client credentials) it is used in the initial authentication
>     request. So for the classic "authorization_code" grant it can be
>     used in
>     code-to-token or refresh-token requests. This is great and allows
>     some
>     cool flexibility (unlike "scope" where the whole SSO login
>     including all
>     the redirects is needed). But it requires some support on adapters.
>
>
>     Now I am thinking about 2 possible ways to continue:
>
>     1) Finish my current work around audience and for now, let it be
>     driven
>     through the "scope" parameter. Then later add the support for the
>     "resource" parameter and the specs above.
>     2) Skip what I currently have and start something different based
>     on the
>     "resource" parameter specs.
>
>     ATM I am more keen to option 1, so that we can have some audience
>     support in master ASAP. Also because the specs is still draft and I
>     don't know how much we can rely on the "resource" parameter being
>     adopted by 3rd party applications (for example Openshift). When we
>     later
>     have the option to drive audiences through both "scope" and
>     "resource"
>     params, it will be good thing IMO.
>
>     The "resource" related support will require changes on the adapter
>     side
>     as it is new parameter to be supported in code-to-token request and
>     refresh-token request. On our adapter's side, it will be good to have
>     some changes to allow "cache" of more access tokens for various
>     resources/audiences, not just one. On server-side, I was thinking
>     about
>     various possibilities, and it still looks good to represent
>     "resource"
>     support through client scopes. So optional clientScopes can be
>     requested
>     either through "scope" parameter (default case) or through "resource"
>     parameter (probably disabled by default) or through both.
>
>     Thoughts?
>
>
>     [1] https://github.com/mposolda/keycloak/tree/audience
>     [2]
>     https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-00
>
>     Marek
>
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>