3:28 p.m.
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
2:21 a.m.
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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
2:37 a.m.
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(a)redhat.com
<mailto:mposolda@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(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
6:56 a.m.
Hi Marek,
I think "resource" will be a good addition but we are already capable of
choosing/processing audiences using scopes. So yeah, IMO, we can go for #1.
On Thu, Sep 6, 2018 at 5:28 PM, Marek Posolda <mposolda(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
2300
days inactive
2304
days old
3 comments
3 participants
participants (3)
-
Marek Posolda -
Pedro Igor Silva -
Stian Thorgersen