Hello, It has been a long time since my last message to this group. Since then we have implemented quite a few things in Keycloak [1] in order to support fine-grained permissions and UMA 1.0. We are not full compliant yet and some pieces are still missing in our implementation. But we already have the backbone to start implementing now the rest of the spec. One of my main tasks is now update our implementation to UMA 2.0 and it seems that one of the main changes is related with the removal of AAT in favor of a specific grant type for UMA. In UMA 1.0 clients were not really forced to authenticate using client credentials when interacting with the RPT endpoint (Authorization API), but just use a AAT as a bearer token. Now, with UMA 2.0, it seems that clients really need to be confidential and use its credentials (e.g.: id/secret or jwt) to authenticate with the token endpoint when using UMA Grant. Is that correct ? [1] https://keycloak.gitbooks.io/documentation/authorization_services/index.html Thanks. Pedro Igor
That is not correct. You can have a public client in UMA 2.0, and in fact you inherit all of the various OAuth client types and authentication methods since you’re talking directly to the token endpoint to get the RPT instead of a special thing. But remember, you needed to talk to the AS to get an AAT previously anyway, so you’ve already needed to have those bits in place in your client. Really, do whatever you’d have done previously to get the AAT (which required an OAuth transaction with the token endpoint) and use it with the token endpoint to get the RPT now. So you always needed a client ID before anyway, that’s not new, and now you can use your secret or key or nothing just like you used to, but in a different part of the process. Is it recommended that you use a confidential client where possible? Definitely, as the increased security is well worth the minimal effort that’s usually required. There are a lot of cases where it doesn’t make sense though, like a browser or native app that’s not using dynamic registration. In any event, this is all now directly inherited from OAuth instead of being reinvented from OAuth, as it was in 1.0. — Justin
On Jun 7, 2017, at 10:58 AM, Pedro Igor Silva <psilva@redhat.com> wrote:
Hello,
It has been a long time since my last message to this group. Since then we have implemented quite a few things in Keycloak [1] in order to support fine-grained permissions and UMA 1.0.
We are not full compliant yet and some pieces are still missing in our implementation. But we already have the backbone to start implementing now the rest of the spec.
One of my main tasks is now update our implementation to UMA 2.0 and it seems that one of the main changes is related with the removal of AAT in favor of a specific grant type for UMA.
In UMA 1.0 clients were not really forced to authenticate using client credentials when interacting with the RPT endpoint (Authorization API), but just use a AAT as a bearer token. Now, with UMA 2.0, it seems that clients really need to be confidential and use its credentials (e.g.: id/secret or jwt) to authenticate with the token endpoint when using UMA Grant.
Is that correct ?
[1] https://keycloak.gitbooks.io/documentation/authorization_services/index.html <https://keycloak.gitbooks.io/documentation/authorization_services/index.html>
Thanks. Pedro Igor _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
On Wed, Jun 7, 2017 at 12:21 PM, Justin Richer <jricher@mit.edu> wrote:
That is not correct. You can have a public client in UMA 2.0, and in fact you inherit all of the various OAuth client types and authentication methods since you’re talking directly to the token endpoint to get the RPT instead of a special thing. But remember, you needed to talk to the AS to get an AAT previously anyway, so you’ve already needed to have those bits in place in your client.
Really, do whatever you’d have done previously to get the AAT (which required an OAuth transaction with the token endpoint) and use it with the token endpoint to get the RPT now. So you always needed a client ID before anyway, that’s not new, and now you can use your secret or key or nothing just like you used to, but in a different part of the process.
Yes, use the AAT with the token endpoint is what I have in mind. If that is fine and still in sync with the spec for me is fine. But, is there anything in spec about public clients ?
Is it recommended that you use a confidential client where possible? Definitely, as the increased security is well worth the minimal effort that’s usually required. There are a lot of cases where it doesn’t make sense though, like a browser or native app that’s not using dynamic registration. In any event, this is all now directly inherited from OAuth instead of being reinvented from OAuth, as it was in 1.0.
That is exactly one of the use cases we need to support.
— Justin
On Jun 7, 2017, at 10:58 AM, Pedro Igor Silva <psilva@redhat.com> wrote:
Hello,
It has been a long time since my last message to this group. Since then we have implemented quite a few things in Keycloak [1] in order to support fine-grained permissions and UMA 1.0.
We are not full compliant yet and some pieces are still missing in our implementation. But we already have the backbone to start implementing now the rest of the spec.
One of my main tasks is now update our implementation to UMA 2.0 and it seems that one of the main changes is related with the removal of AAT in favor of a specific grant type for UMA.
In UMA 1.0 clients were not really forced to authenticate using client credentials when interacting with the RPT endpoint (Authorization API), but just use a AAT as a bearer token. Now, with UMA 2.0, it seems that clients really need to be confidential and use its credentials (e.g.: id/secret or jwt) to authenticate with the token endpoint when using UMA Grant.
Is that correct ?
[1] https://keycloak.gitbooks.io/documentation/authorization _services/index.html
Thanks. Pedro Igor _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
There’s nothing in the spec about public clients because it’s all covered in OAuth 2 (RFC6749 specifically). — Justin
On Jun 7, 2017, at 12:57 PM, Pedro Igor Silva <psilva@redhat.com> wrote:
On Wed, Jun 7, 2017 at 12:21 PM, Justin Richer <jricher@mit.edu <mailto:jricher@mit.edu>> wrote: That is not correct. You can have a public client in UMA 2.0, and in fact you inherit all of the various OAuth client types and authentication methods since you’re talking directly to the token endpoint to get the RPT instead of a special thing. But remember, you needed to talk to the AS to get an AAT previously anyway, so you’ve already needed to have those bits in place in your client.
Really, do whatever you’d have done previously to get the AAT (which required an OAuth transaction with the token endpoint) and use it with the token endpoint to get the RPT now. So you always needed a client ID before anyway, that’s not new, and now you can use your secret or key or nothing just like you used to, but in a different part of the process.
Yes, use the AAT with the token endpoint is what I have in mind. If that is fine and still in sync with the spec for me is fine. But, is there anything in spec about public clients ?
Is it recommended that you use a confidential client where possible? Definitely, as the increased security is well worth the minimal effort that’s usually required. There are a lot of cases where it doesn’t make sense though, like a browser or native app that’s not using dynamic registration. In any event, this is all now directly inherited from OAuth instead of being reinvented from OAuth, as it was in 1.0.
That is exactly one of the use cases we need to support.
— Justin
On Jun 7, 2017, at 10:58 AM, Pedro Igor Silva <psilva@redhat.com <mailto:psilva@redhat.com>> wrote:
Hello,
It has been a long time since my last message to this group. Since then we have implemented quite a few things in Keycloak [1] in order to support fine-grained permissions and UMA 1.0.
We are not full compliant yet and some pieces are still missing in our implementation. But we already have the backbone to start implementing now the rest of the spec.
One of my main tasks is now update our implementation to UMA 2.0 and it seems that one of the main changes is related with the removal of AAT in favor of a specific grant type for UMA.
In UMA 1.0 clients were not really forced to authenticate using client credentials when interacting with the RPT endpoint (Authorization API), but just use a AAT as a bearer token. Now, with UMA 2.0, it seems that clients really need to be confidential and use its credentials (e.g.: id/secret or jwt) to authenticate with the token endpoint when using UMA Grant.
Is that correct ?
[1] https://keycloak.gitbooks.io/documentation/authorization_services/index.html <https://keycloak.gitbooks.io/documentation/authorization_services/index.html>
Thanks. Pedro Igor _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org <mailto:WG-UMA@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/wg-uma <http://kantarainitiative.org/mailman/listinfo/wg-uma>
OK. Thanks, Justin. OAuth2 spec does cover public clients, which are usually related with usage of a implicit grant. But in UMA 2.0 it seems we have now a specific grant type, which flow and examples are really specific to confidential clients. And more important, UMA grant type does not seem to support redirection which is something essential if you want to support public clients. Based on OAuth2 specs, public clients are able to obtain tokens from the authorization endpoint (not token endpoint) based on their client_id and redirection_uri when using implicit grant. Like I previously mentioned, to avoid using implicit grant we would just support a bearer token when using UMA grant type (and token endpoint). Some of our use cases are related with public clients authenticating with Keycloak based on OpenID Connect where an ID token and AT is already available to them. One last question, this one about UMA compliance. We would like to include Keycloak in the list of UMA implementations after reviewing what we have in order to conform with latest version of the spec. Is there a TCK or some other process we need to follow to achieve this ? On Wed, Jun 7, 2017 at 10:27 PM, Justin Richer <jricher@mit.edu> wrote:
There’s nothing in the spec about public clients because it’s all covered in OAuth 2 (RFC6749 specifically).
— Justin
On Jun 7, 2017, at 12:57 PM, Pedro Igor Silva <psilva@redhat.com> wrote:
On Wed, Jun 7, 2017 at 12:21 PM, Justin Richer <jricher@mit.edu> wrote:
That is not correct. You can have a public client in UMA 2.0, and in fact you inherit all of the various OAuth client types and authentication methods since you’re talking directly to the token endpoint to get the RPT instead of a special thing. But remember, you needed to talk to the AS to get an AAT previously anyway, so you’ve already needed to have those bits in place in your client.
Really, do whatever you’d have done previously to get the AAT (which required an OAuth transaction with the token endpoint) and use it with the token endpoint to get the RPT now. So you always needed a client ID before anyway, that’s not new, and now you can use your secret or key or nothing just like you used to, but in a different part of the process.
Yes, use the AAT with the token endpoint is what I have in mind. If that is fine and still in sync with the spec for me is fine. But, is there anything in spec about public clients ?
Is it recommended that you use a confidential client where possible? Definitely, as the increased security is well worth the minimal effort that’s usually required. There are a lot of cases where it doesn’t make sense though, like a browser or native app that’s not using dynamic registration. In any event, this is all now directly inherited from OAuth instead of being reinvented from OAuth, as it was in 1.0.
That is exactly one of the use cases we need to support.
— Justin
On Jun 7, 2017, at 10:58 AM, Pedro Igor Silva <psilva@redhat.com> wrote:
Hello,
It has been a long time since my last message to this group. Since then we have implemented quite a few things in Keycloak [1] in order to support fine-grained permissions and UMA 1.0.
We are not full compliant yet and some pieces are still missing in our implementation. But we already have the backbone to start implementing now the rest of the spec.
One of my main tasks is now update our implementation to UMA 2.0 and it seems that one of the main changes is related with the removal of AAT in favor of a specific grant type for UMA.
In UMA 1.0 clients were not really forced to authenticate using client credentials when interacting with the RPT endpoint (Authorization API), but just use a AAT as a bearer token. Now, with UMA 2.0, it seems that clients really need to be confidential and use its credentials (e.g.: id/secret or jwt) to authenticate with the token endpoint when using UMA Grant.
Is that correct ?
[1] https://keycloak.gitbooks.io/documentation/authorization _services/index.html
Thanks. Pedro Igor _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
You're conflating the grant type (and its associated redirect) with public clients. They're two separate aspects of the protocol and are not tightly tied together, though you do often find one with the other. It's not "public clients" that obtain tokens from the authorization endpoint, it's "implicit grant" clients. You can use a public client with non-implicit flows if you want to -- in fact, a public client with the authorization code flow (and PKCE) is the recommended method for native applications these days. You don't use the implicit grant with UMA, you use the UMA grant. The UMA grant doesn't use the authorization endpoint at all. There is no "implicit UMA grant". If you want to use the UMA grant with an in-browser client, you can do so. The in-browser client just calls the token endpoint like any other client would. I don't understand your statement about a bearer token instead of the implicit grant -- if you're doing the implicit grant today in just about every implementation, you're getting a bearer token. And to do UMA you need to do the UMA grant anyway, so the implicit grant doesn't apply here. And there aren't standardized non-bearer tokens defined yet, so you're likely doing bearer tokens whether you're doing UMA or plain OAuth anyway. OpenID Connect is built on OAuth, not UMA. There's no definition for doing OpenID Connect on top of UMA, and I would argue that it doesn't really make sense: OpenID Connect is an identity protocol and the whole point is to delegate access to the current user's identity API, which is what OAuth does. UMA would give you access to some other party's identity API, which doesn't tell you who's logged in right now. While they're often used together, they solve very different use cases. Think of it like having a hammer, a saw, and a screwdriver in the toolbox. They're all there for different reasons but you can use them all to build your cabinet or whatever. Hopefully this helps untangle some things. -- Justin On 6/8/2017 7:29 AM, Pedro Igor Silva wrote:
OK. Thanks, Justin.
OAuth2 spec does cover public clients, which are usually related with usage of a implicit grant. But in UMA 2.0 it seems we have now a specific grant type, which flow and examples are really specific to confidential clients. And more important, UMA grant type does not seem to support redirection which is something essential if you want to support public clients. Based on OAuth2 specs, public clients are able to obtain tokens from the authorization endpoint (not token endpoint) based on their client_id and redirection_uri when using implicit grant.
Like I previously mentioned, to avoid using implicit grant we would just support a bearer token when using UMA grant type (and token endpoint). Some of our use cases are related with public clients authenticating with Keycloak based on OpenID Connect where an ID token and AT is already available to them.
One last question, this one about UMA compliance. We would like to include Keycloak in the list of UMA implementations after reviewing what we have in order to conform with latest version of the spec. Is there a TCK or some other process we need to follow to achieve this ?
On Wed, Jun 7, 2017 at 10:27 PM, Justin Richer <jricher@mit.edu <mailto:jricher@mit.edu>> wrote:
There’s nothing in the spec about public clients because it’s all covered in OAuth 2 (RFC6749 specifically).
— Justin
On Jun 7, 2017, at 12:57 PM, Pedro Igor Silva <psilva@redhat.com <mailto:psilva@redhat.com>> wrote:
On Wed, Jun 7, 2017 at 12:21 PM, Justin Richer <jricher@mit.edu <mailto:jricher@mit.edu>> wrote:
That is not correct. You can have a public client in UMA 2.0, and in fact you inherit all of the various OAuth client types and authentication methods since you’re talking directly to the token endpoint to get the RPT instead of a special thing. But remember, you needed to talk to the AS to get an AAT previously anyway, so you’ve already needed to have those bits in place in your client.
Really, do whatever you’d have done previously to get the AAT (which required an OAuth transaction with the token endpoint) and use it with the token endpoint to get the RPT now. So you always needed a client ID before anyway, that’s not new, and now you can use your secret or key or nothing just like you used to, but in a different part of the process.
Yes, use the AAT with the token endpoint is what I have in mind. If that is fine and still in sync with the spec for me is fine. But, is there anything in spec about public clients ?
Is it recommended that you use a confidential client where possible? Definitely, as the increased security is well worth the minimal effort that’s usually required. There are a lot of cases where it doesn’t make sense though, like a browser or native app that’s not using dynamic registration. In any event, this is all now directly inherited from OAuth instead of being reinvented from OAuth, as it was in 1.0.
That is exactly one of the use cases we need to support.
— Justin
On Jun 7, 2017, at 10:58 AM, Pedro Igor Silva <psilva@redhat.com <mailto:psilva@redhat.com>> wrote:
Hello,
It has been a long time since my last message to this group. Since then we have implemented quite a few things in Keycloak [1] in order to support fine-grained permissions and UMA 1.0.
We are not full compliant yet and some pieces are still missing in our implementation. But we already have the backbone to start implementing now the rest of the spec.
One of my main tasks is now update our implementation to UMA 2.0 and it seems that one of the main changes is related with the removal of AAT in favor of a specific grant type for UMA.
In UMA 1.0 clients were not really forced to authenticate using client credentials when interacting with the RPT endpoint (Authorization API), but just use a AAT as a bearer token. Now, with UMA 2.0, it seems that clients really need to be confidential and use its credentials (e.g.: id/secret or jwt) to authenticate with the token endpoint when using UMA Grant.
Is that correct ?
[1] https://keycloak.gitbooks.io/documentation/authorization_services/index.html <https://keycloak.gitbooks.io/documentation/authorization_services/index.html>
Thanks. Pedro Igor _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org <mailto:WG-UMA@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/wg-uma <http://kantarainitiative.org/mailman/listinfo/wg-uma>
Welcome back, Pedro! A few notes: - Aren't many other grant types applicable to multiple client types? And if someone is interested to restrict the UMA grant to apply only to confidential clients by writing a formal profile, we have the example of the extension Assertion Framework <https://tools.ietf.org/html/rfc7521>, which gets specialized by the SAML bearer assertion profile <https://tools.ietf.org/html/rfc7522> (not that the latter actually does this particular kind of specialization...). - It would be good to learn more about the contexts in which you're using OIDC. From time to time, we've talked about the potential benefits of a sort of "OIDC or at least UserInfo endpoint that is UMA-protected", because then the resource owner could share standardized identity data with autonomous third parties, gain positive control over that data, not have to be present when the data is requested, etc. In fact, a person in a requesting party role could potentially use this mechanism to protect the claims sought by a resource owner's AS for authorization assessment. - We do not yet have an interop or testing conformance program, but the number of serious requests is increasing, and we put some effort into this in the past. Time to pick up where we left off; I will make a note to follow up. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Thu, Jun 8, 2017 at 5:57 AM, Justin Richer <jricher@mit.edu> wrote:
You're conflating the grant type (and its associated redirect) with public clients. They're two separate aspects of the protocol and are not tightly tied together, though you do often find one with the other. It's not "public clients" that obtain tokens from the authorization endpoint, it's "implicit grant" clients. You can use a public client with non-implicit flows if you want to -- in fact, a public client with the authorization code flow (and PKCE) is the recommended method for native applications these days.
You don't use the implicit grant with UMA, you use the UMA grant. The UMA grant doesn't use the authorization endpoint at all. There is no "implicit UMA grant". If you want to use the UMA grant with an in-browser client, you can do so. The in-browser client just calls the token endpoint like any other client would.
I don't understand your statement about a bearer token instead of the implicit grant -- if you're doing the implicit grant today in just about every implementation, you're getting a bearer token. And to do UMA you need to do the UMA grant anyway, so the implicit grant doesn't apply here. And there aren't standardized non-bearer tokens defined yet, so you're likely doing bearer tokens whether you're doing UMA or plain OAuth anyway.
OpenID Connect is built on OAuth, not UMA. There's no definition for doing OpenID Connect on top of UMA, and I would argue that it doesn't really make sense: OpenID Connect is an identity protocol and the whole point is to delegate access to the current user's identity API, which is what OAuth does. UMA would give you access to some other party's identity API, which doesn't tell you who's logged in right now. While they're often used together, they solve very different use cases. Think of it like having a hammer, a saw, and a screwdriver in the toolbox. They're all there for different reasons but you can use them all to build your cabinet or whatever.
Hopefully this helps untangle some things.
-- Justin
On 6/8/2017 7:29 AM, Pedro Igor Silva wrote:
OK. Thanks, Justin.
OAuth2 spec does cover public clients, which are usually related with usage of a implicit grant. But in UMA 2.0 it seems we have now a specific grant type, which flow and examples are really specific to confidential clients. And more important, UMA grant type does not seem to support redirection which is something essential if you want to support public clients. Based on OAuth2 specs, public clients are able to obtain tokens from the authorization endpoint (not token endpoint) based on their client_id and redirection_uri when using implicit grant.
Like I previously mentioned, to avoid using implicit grant we would just support a bearer token when using UMA grant type (and token endpoint). Some of our use cases are related with public clients authenticating with Keycloak based on OpenID Connect where an ID token and AT is already available to them.
One last question, this one about UMA compliance. We would like to include Keycloak in the list of UMA implementations after reviewing what we have in order to conform with latest version of the spec. Is there a TCK or some other process we need to follow to achieve this ?
On Wed, Jun 7, 2017 at 10:27 PM, Justin Richer <jricher@mit.edu> wrote:
There’s nothing in the spec about public clients because it’s all covered in OAuth 2 (RFC6749 specifically).
— Justin
On Jun 7, 2017, at 12:57 PM, Pedro Igor Silva <psilva@redhat.com> wrote:
On Wed, Jun 7, 2017 at 12:21 PM, Justin Richer <jricher@mit.edu> wrote:
That is not correct. You can have a public client in UMA 2.0, and in fact you inherit all of the various OAuth client types and authentication methods since you’re talking directly to the token endpoint to get the RPT instead of a special thing. But remember, you needed to talk to the AS to get an AAT previously anyway, so you’ve already needed to have those bits in place in your client.
Really, do whatever you’d have done previously to get the AAT (which required an OAuth transaction with the token endpoint) and use it with the token endpoint to get the RPT now. So you always needed a client ID before anyway, that’s not new, and now you can use your secret or key or nothing just like you used to, but in a different part of the process.
Yes, use the AAT with the token endpoint is what I have in mind. If that is fine and still in sync with the spec for me is fine. But, is there anything in spec about public clients ?
Is it recommended that you use a confidential client where possible? Definitely, as the increased security is well worth the minimal effort that’s usually required. There are a lot of cases where it doesn’t make sense though, like a browser or native app that’s not using dynamic registration. In any event, this is all now directly inherited from OAuth instead of being reinvented from OAuth, as it was in 1.0.
That is exactly one of the use cases we need to support.
— Justin
On Jun 7, 2017, at 10:58 AM, Pedro Igor Silva <psilva@redhat.com> wrote:
Hello,
It has been a long time since my last message to this group. Since then we have implemented quite a few things in Keycloak [1] in order to support fine-grained permissions and UMA 1.0.
We are not full compliant yet and some pieces are still missing in our implementation. But we already have the backbone to start implementing now the rest of the spec.
One of my main tasks is now update our implementation to UMA 2.0 and it seems that one of the main changes is related with the removal of AAT in favor of a specific grant type for UMA.
In UMA 1.0 clients were not really forced to authenticate using client credentials when interacting with the RPT endpoint (Authorization API), but just use a AAT as a bearer token. Now, with UMA 2.0, it seems that clients really need to be confidential and use its credentials (e.g.: id/secret or jwt) to authenticate with the token endpoint when using UMA Grant.
Is that correct ?
[1] https://keycloak.gitbooks.io/documentation/authorization _services/index.html
Thanks. Pedro Igor _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
On Thu, Jun 8, 2017 at 2:05 PM, Eve Maler <eve@xmlgrrl.com> wrote:
Welcome back, Pedro! A few notes:
Thanks, Eve.
- Aren't many other grant types applicable to multiple client types? And if someone is interested to restrict the UMA grant to apply only to confidential clients by writing a formal profile, we have the example of the extension Assertion Framework <https://tools.ietf.org/html/rfc7521>, which gets specialized by the SAML bearer assertion profile <https://tools.ietf.org/html/rfc7522> (not that the latter actually does this particular kind of specialization...).
Yes. You just nailed down the points I've brought to this discussion. Although not mentioned explicitly in UMA 2.0, we can authenticate clients when doing UMA Grant by pushing a previously issued access token. Just wanted to make it clear and confirm we could follow this path with a bless from the expert group. As I did not find anything explicitly in the specs, I found better to ask first before coding.
- It would be good to learn more about the contexts in which you're using OIDC. From time to time, we've talked about the potential benefits of a sort of "OIDC or at least UserInfo endpoint that is UMA-protected", because then the resource owner could share standardized identity data with autonomous third parties, gain positive control over that data, not have to be present when the data is requested, etc. In fact, a person in a requesting party role could potentially use this mechanism to protect the claims sought by a resource owner's AS for authorization assessment.
For sure there are a lot of benefits for resource owners in protecting
UserInfo with UMA. And I don't think this is something hard to achieve if you have UserInfo and its data/claims properly represented as resources and scopes in the AS. I know you'll get angry with me :) But right now we don't fully support UMA. Our plan is now focus on updating our stuff to UMA 2.0 and implement the missing pieces. We have very limited resources to work on this and our requirements are really driven by demands from our community and customers. But we already had people asking for more features from UMA, specially those related with user managed access/resource sharing (the honeypot).
- We do not yet have an interop or testing conformance program, but the number of serious requests is increasing, and we put some effort into this in the past. Time to pick up where we left off; I will make a note to follow up.
Great, thanks for the update.
*Eve Maler*Cell +1 425.345.6756 <(425)%20345-6756> | Skype: xmlgrrl | Twitter: @xmlgrrl
On Thu, Jun 8, 2017 at 5:57 AM, Justin Richer <jricher@mit.edu> wrote:
You're conflating the grant type (and its associated redirect) with public clients. They're two separate aspects of the protocol and are not tightly tied together, though you do often find one with the other. It's not "public clients" that obtain tokens from the authorization endpoint, it's "implicit grant" clients. You can use a public client with non-implicit flows if you want to -- in fact, a public client with the authorization code flow (and PKCE) is the recommended method for native applications these days.
You don't use the implicit grant with UMA, you use the UMA grant. The UMA grant doesn't use the authorization endpoint at all. There is no "implicit UMA grant". If you want to use the UMA grant with an in-browser client, you can do so. The in-browser client just calls the token endpoint like any other client would.
I don't understand your statement about a bearer token instead of the implicit grant -- if you're doing the implicit grant today in just about every implementation, you're getting a bearer token. And to do UMA you need to do the UMA grant anyway, so the implicit grant doesn't apply here. And there aren't standardized non-bearer tokens defined yet, so you're likely doing bearer tokens whether you're doing UMA or plain OAuth anyway.
OpenID Connect is built on OAuth, not UMA. There's no definition for doing OpenID Connect on top of UMA, and I would argue that it doesn't really make sense: OpenID Connect is an identity protocol and the whole point is to delegate access to the current user's identity API, which is what OAuth does. UMA would give you access to some other party's identity API, which doesn't tell you who's logged in right now. While they're often used together, they solve very different use cases. Think of it like having a hammer, a saw, and a screwdriver in the toolbox. They're all there for different reasons but you can use them all to build your cabinet or whatever.
Hopefully this helps untangle some things.
-- Justin
On 6/8/2017 7:29 AM, Pedro Igor Silva wrote:
OK. Thanks, Justin.
OAuth2 spec does cover public clients, which are usually related with usage of a implicit grant. But in UMA 2.0 it seems we have now a specific grant type, which flow and examples are really specific to confidential clients. And more important, UMA grant type does not seem to support redirection which is something essential if you want to support public clients. Based on OAuth2 specs, public clients are able to obtain tokens from the authorization endpoint (not token endpoint) based on their client_id and redirection_uri when using implicit grant.
Like I previously mentioned, to avoid using implicit grant we would just support a bearer token when using UMA grant type (and token endpoint). Some of our use cases are related with public clients authenticating with Keycloak based on OpenID Connect where an ID token and AT is already available to them.
One last question, this one about UMA compliance. We would like to include Keycloak in the list of UMA implementations after reviewing what we have in order to conform with latest version of the spec. Is there a TCK or some other process we need to follow to achieve this ?
On Wed, Jun 7, 2017 at 10:27 PM, Justin Richer <jricher@mit.edu> wrote:
There’s nothing in the spec about public clients because it’s all covered in OAuth 2 (RFC6749 specifically).
— Justin
On Jun 7, 2017, at 12:57 PM, Pedro Igor Silva <psilva@redhat.com> wrote:
On Wed, Jun 7, 2017 at 12:21 PM, Justin Richer <jricher@mit.edu> wrote:
That is not correct. You can have a public client in UMA 2.0, and in fact you inherit all of the various OAuth client types and authentication methods since you’re talking directly to the token endpoint to get the RPT instead of a special thing. But remember, you needed to talk to the AS to get an AAT previously anyway, so you’ve already needed to have those bits in place in your client.
Really, do whatever you’d have done previously to get the AAT (which required an OAuth transaction with the token endpoint) and use it with the token endpoint to get the RPT now. So you always needed a client ID before anyway, that’s not new, and now you can use your secret or key or nothing just like you used to, but in a different part of the process.
Yes, use the AAT with the token endpoint is what I have in mind. If that is fine and still in sync with the spec for me is fine. But, is there anything in spec about public clients ?
Is it recommended that you use a confidential client where possible? Definitely, as the increased security is well worth the minimal effort that’s usually required. There are a lot of cases where it doesn’t make sense though, like a browser or native app that’s not using dynamic registration. In any event, this is all now directly inherited from OAuth instead of being reinvented from OAuth, as it was in 1.0.
That is exactly one of the use cases we need to support.
— Justin
On Jun 7, 2017, at 10:58 AM, Pedro Igor Silva <psilva@redhat.com> wrote:
Hello,
It has been a long time since my last message to this group. Since then we have implemented quite a few things in Keycloak [1] in order to support fine-grained permissions and UMA 1.0.
We are not full compliant yet and some pieces are still missing in our implementation. But we already have the backbone to start implementing now the rest of the spec.
One of my main tasks is now update our implementation to UMA 2.0 and it seems that one of the main changes is related with the removal of AAT in favor of a specific grant type for UMA.
In UMA 1.0 clients were not really forced to authenticate using client credentials when interacting with the RPT endpoint (Authorization API), but just use a AAT as a bearer token. Now, with UMA 2.0, it seems that clients really need to be confidential and use its credentials (e.g.: id/secret or jwt) to authenticate with the token endpoint when using UMA Grant.
Is that correct ?
[1] https://keycloak.gitbooks.io/documentation/authorization _services/index.html
Thanks. Pedro Igor _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
Angry, never. :) Excited about the demand, and that UMA 2.0 looks relevant for meeting that demand. Agreed about an UMA-protected UserInfo being interesting and pretty doable. And given that it would be synergistic with UMA authorization itself, perhaps it's finally time for interested parties to work on that... BTW, don't forget that the Public Comment period closes July 12, so if you have implementation feedback, our best chance for addressing it would be to have comments submitted during this period. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Thu, Jun 8, 2017 at 10:35 AM, Pedro Igor Silva <psilva@redhat.com> wrote:
On Thu, Jun 8, 2017 at 2:05 PM, Eve Maler <eve@xmlgrrl.com> wrote:
Welcome back, Pedro! A few notes:
Thanks, Eve.
- Aren't many other grant types applicable to multiple client types? And if someone is interested to restrict the UMA grant to apply only to confidential clients by writing a formal profile, we have the example of the extension Assertion Framework <https://tools.ietf.org/html/rfc7521>, which gets specialized by the SAML bearer assertion profile <https://tools.ietf.org/html/rfc7522> (not that the latter actually does this particular kind of specialization...).
Yes. You just nailed down the points I've brought to this discussion. Although not mentioned explicitly in UMA 2.0, we can authenticate clients when doing UMA Grant by pushing a previously issued access token. Just wanted to make it clear and confirm we could follow this path with a bless from the expert group. As I did not find anything explicitly in the specs, I found better to ask first before coding.
- It would be good to learn more about the contexts in which you're using OIDC. From time to time, we've talked about the potential benefits of a sort of "OIDC or at least UserInfo endpoint that is UMA-protected", because then the resource owner could share standardized identity data with autonomous third parties, gain positive control over that data, not have to be present when the data is requested, etc. In fact, a person in a requesting party role could potentially use this mechanism to protect the claims sought by a resource owner's AS for authorization assessment.
For sure there are a lot of benefits for resource owners in protecting
UserInfo with UMA. And I don't think this is something hard to achieve if you have UserInfo and its data/claims properly represented as resources and scopes in the AS.
I know you'll get angry with me :) But right now we don't fully support UMA. Our plan is now focus on updating our stuff to UMA 2.0 and implement the missing pieces. We have very limited resources to work on this and our requirements are really driven by demands from our community and customers. But we already had people asking for more features from UMA, specially those related with user managed access/resource sharing (the honeypot).
- We do not yet have an interop or testing conformance program, but the number of serious requests is increasing, and we put some effort into this in the past. Time to pick up where we left off; I will make a note to follow up.
Great, thanks for the update.
*Eve Maler*Cell +1 425.345.6756 <(425)%20345-6756> | Skype: xmlgrrl | Twitter: @xmlgrrl
On Thu, Jun 8, 2017 at 5:57 AM, Justin Richer <jricher@mit.edu> wrote:
You're conflating the grant type (and its associated redirect) with public clients. They're two separate aspects of the protocol and are not tightly tied together, though you do often find one with the other. It's not "public clients" that obtain tokens from the authorization endpoint, it's "implicit grant" clients. You can use a public client with non-implicit flows if you want to -- in fact, a public client with the authorization code flow (and PKCE) is the recommended method for native applications these days.
You don't use the implicit grant with UMA, you use the UMA grant. The UMA grant doesn't use the authorization endpoint at all. There is no "implicit UMA grant". If you want to use the UMA grant with an in-browser client, you can do so. The in-browser client just calls the token endpoint like any other client would.
I don't understand your statement about a bearer token instead of the implicit grant -- if you're doing the implicit grant today in just about every implementation, you're getting a bearer token. And to do UMA you need to do the UMA grant anyway, so the implicit grant doesn't apply here. And there aren't standardized non-bearer tokens defined yet, so you're likely doing bearer tokens whether you're doing UMA or plain OAuth anyway.
OpenID Connect is built on OAuth, not UMA. There's no definition for doing OpenID Connect on top of UMA, and I would argue that it doesn't really make sense: OpenID Connect is an identity protocol and the whole point is to delegate access to the current user's identity API, which is what OAuth does. UMA would give you access to some other party's identity API, which doesn't tell you who's logged in right now. While they're often used together, they solve very different use cases. Think of it like having a hammer, a saw, and a screwdriver in the toolbox. They're all there for different reasons but you can use them all to build your cabinet or whatever.
Hopefully this helps untangle some things.
-- Justin
On 6/8/2017 7:29 AM, Pedro Igor Silva wrote:
OK. Thanks, Justin.
OAuth2 spec does cover public clients, which are usually related with usage of a implicit grant. But in UMA 2.0 it seems we have now a specific grant type, which flow and examples are really specific to confidential clients. And more important, UMA grant type does not seem to support redirection which is something essential if you want to support public clients. Based on OAuth2 specs, public clients are able to obtain tokens from the authorization endpoint (not token endpoint) based on their client_id and redirection_uri when using implicit grant.
Like I previously mentioned, to avoid using implicit grant we would just support a bearer token when using UMA grant type (and token endpoint). Some of our use cases are related with public clients authenticating with Keycloak based on OpenID Connect where an ID token and AT is already available to them.
One last question, this one about UMA compliance. We would like to include Keycloak in the list of UMA implementations after reviewing what we have in order to conform with latest version of the spec. Is there a TCK or some other process we need to follow to achieve this ?
On Wed, Jun 7, 2017 at 10:27 PM, Justin Richer <jricher@mit.edu> wrote:
There’s nothing in the spec about public clients because it’s all covered in OAuth 2 (RFC6749 specifically).
— Justin
On Jun 7, 2017, at 12:57 PM, Pedro Igor Silva <psilva@redhat.com> wrote:
On Wed, Jun 7, 2017 at 12:21 PM, Justin Richer <jricher@mit.edu> wrote:
That is not correct. You can have a public client in UMA 2.0, and in fact you inherit all of the various OAuth client types and authentication methods since you’re talking directly to the token endpoint to get the RPT instead of a special thing. But remember, you needed to talk to the AS to get an AAT previously anyway, so you’ve already needed to have those bits in place in your client.
Really, do whatever you’d have done previously to get the AAT (which required an OAuth transaction with the token endpoint) and use it with the token endpoint to get the RPT now. So you always needed a client ID before anyway, that’s not new, and now you can use your secret or key or nothing just like you used to, but in a different part of the process.
Yes, use the AAT with the token endpoint is what I have in mind. If that is fine and still in sync with the spec for me is fine. But, is there anything in spec about public clients ?
Is it recommended that you use a confidential client where possible? Definitely, as the increased security is well worth the minimal effort that’s usually required. There are a lot of cases where it doesn’t make sense though, like a browser or native app that’s not using dynamic registration. In any event, this is all now directly inherited from OAuth instead of being reinvented from OAuth, as it was in 1.0.
That is exactly one of the use cases we need to support.
— Justin
On Jun 7, 2017, at 10:58 AM, Pedro Igor Silva <psilva@redhat.com> wrote:
Hello,
It has been a long time since my last message to this group. Since then we have implemented quite a few things in Keycloak [1] in order to support fine-grained permissions and UMA 1.0.
We are not full compliant yet and some pieces are still missing in our implementation. But we already have the backbone to start implementing now the rest of the spec.
One of my main tasks is now update our implementation to UMA 2.0 and it seems that one of the main changes is related with the removal of AAT in favor of a specific grant type for UMA.
In UMA 1.0 clients were not really forced to authenticate using client credentials when interacting with the RPT endpoint (Authorization API), but just use a AAT as a bearer token. Now, with UMA 2.0, it seems that clients really need to be confidential and use its credentials (e.g.: id/secret or jwt) to authenticate with the token endpoint when using UMA Grant.
Is that correct ?
[1] https://keycloak.gitbooks.io/documentation/authorization _services/index.html
Thanks. Pedro Igor _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
UMA-protected access to UserInfo is fine, but it's not an authentication protocol and not OpenID Connect. I think we'd need to be very careful about how it's presented. OAuth has a hard enough time with the whole authentication myth. -- Justin On 6/9/2017 10:11 PM, Eve Maler wrote:
Angry, never. :) Excited about the demand, and that UMA 2.0 looks relevant for meeting that demand.
Agreed about an UMA-protected UserInfo being interesting and pretty doable. And given that it would be synergistic with UMA authorization itself, perhaps it's finally time for interested parties to work on that...
BTW, don't forget that the Public Comment period closes July 12, so if you have implementation feedback, our best chance for addressing it would be to have comments submitted during this period.
*Eve Maler *Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
On Thu, Jun 8, 2017 at 10:35 AM, Pedro Igor Silva <psilva@redhat.com <mailto:psilva@redhat.com>> wrote:
On Thu, Jun 8, 2017 at 2:05 PM, Eve Maler <eve@xmlgrrl.com <mailto:eve@xmlgrrl.com>> wrote:
Welcome back, Pedro! A few notes:
Thanks, Eve.
* Aren't many other grant types applicable to multiple client types? And if someone is interested to restrict the UMA grant to apply only to confidential clients by writing a formal profile, we have the example of the extension Assertion Framework <https://tools.ietf.org/html/rfc7521>, which gets specialized by the SAML bearer assertion profile <https://tools.ietf.org/html/rfc7522> (not that the latter actually does this particular kind of specialization...).
Yes. You just nailed down the points I've brought to this discussion. Although not mentioned explicitly in UMA 2.0, we can authenticate clients when doing UMA Grant by pushing a previously issued access token. Just wanted to make it clear and confirm we could follow this path with a bless from the expert group. As I did not find anything explicitly in the specs, I found better to ask first before coding.
* It would be good to learn more about the contexts in which you're using OIDC. From time to time, we've talked about the potential benefits of a sort of "OIDC or at least UserInfo endpoint that is UMA-protected", because then the resource owner could share standardized identity data with autonomous third parties, gain positive control over that data, not have to be present when the data is requested, etc. In fact, a person in a requesting party role could potentially use this mechanism to protect the claims sought by a resource owner's AS for authorization assessment.
For sure there are a lot of benefits for resource owners in protecting UserInfo with UMA. And I don't think this is something hard to achieve if you have UserInfo and its data/claims properly represented as resources and scopes in the AS.
I know you'll get angry with me :) But right now we don't fully support UMA. Our plan is now focus on updating our stuff to UMA 2.0 and implement the missing pieces. We have very limited resources to work on this and our requirements are really driven by demands from our community and customers. But we already had people asking for more features from UMA, specially those related with user managed access/resource sharing (the honeypot).
* We do not yet have an interop or testing conformance program, but the number of serious requests is increasing, and we put some effort into this in the past. Time to pick up where we left off; I will make a note to follow up.
Great, thanks for the update.
*Eve Maler *Cell +1 425.345.6756 <tel:%28425%29%20345-6756> | Skype: xmlgrrl | Twitter: @xmlgrrl
On Thu, Jun 8, 2017 at 5:57 AM, Justin Richer <jricher@mit.edu <mailto:jricher@mit.edu>> wrote:
You're conflating the grant type (and its associated redirect) with public clients. They're two separate aspects of the protocol and are not tightly tied together, though you do often find one with the other. It's not "public clients" that obtain tokens from the authorization endpoint, it's "implicit grant" clients. You can use a public client with non-implicit flows if you want to -- in fact, a public client with the authorization code flow (and PKCE) is the recommended method for native applications these days.
You don't use the implicit grant with UMA, you use the UMA grant. The UMA grant doesn't use the authorization endpoint at all. There is no "implicit UMA grant". If you want to use the UMA grant with an in-browser client, you can do so. The in-browser client just calls the token endpoint like any other client would.
I don't understand your statement about a bearer token instead of the implicit grant -- if you're doing the implicit grant today in just about every implementation, you're getting a bearer token. And to do UMA you need to do the UMA grant anyway, so the implicit grant doesn't apply here. And there aren't standardized non-bearer tokens defined yet, so you're likely doing bearer tokens whether you're doing UMA or plain OAuth anyway.
OpenID Connect is built on OAuth, not UMA. There's no definition for doing OpenID Connect on top of UMA, and I would argue that it doesn't really make sense: OpenID Connect is an identity protocol and the whole point is to delegate access to the current user's identity API, which is what OAuth does. UMA would give you access to some other party's identity API, which doesn't tell you who's logged in right now. While they're often used together, they solve very different use cases. Think of it like having a hammer, a saw, and a screwdriver in the toolbox. They're all there for different reasons but you can use them all to build your cabinet or whatever.
Hopefully this helps untangle some things.
-- Justin
On 6/8/2017 7:29 AM, Pedro Igor Silva wrote:
OK. Thanks, Justin.
OAuth2 spec does cover public clients, which are usually related with usage of a implicit grant. But in UMA 2.0 it seems we have now a specific grant type, which flow and examples are really specific to confidential clients. And more important, UMA grant type does not seem to support redirection which is something essential if you want to support public clients. Based on OAuth2 specs, public clients are able to obtain tokens from the authorization endpoint (not token endpoint) based on their client_id and redirection_uri when using implicit grant.
Like I previously mentioned, to avoid using implicit grant we would just support a bearer token when using UMA grant type (and token endpoint). Some of our use cases are related with public clients authenticating with Keycloak based on OpenID Connect where an ID token and AT is already available to them.
One last question, this one about UMA compliance. We would like to include Keycloak in the list of UMA implementations after reviewing what we have in order to conform with latest version of the spec. Is there a TCK or some other process we need to follow to achieve this ?
On Wed, Jun 7, 2017 at 10:27 PM, Justin Richer <jricher@mit.edu <mailto:jricher@mit.edu>> wrote:
There’s nothing in the spec about public clients because it’s all covered in OAuth 2 (RFC6749 specifically).
— Justin
On Jun 7, 2017, at 12:57 PM, Pedro Igor Silva <psilva@redhat.com <mailto:psilva@redhat.com>> wrote:
On Wed, Jun 7, 2017 at 12:21 PM, Justin Richer <jricher@mit.edu <mailto:jricher@mit.edu>> wrote:
That is not correct. You can have a public client in UMA 2.0, and in fact you inherit all of the various OAuth client types and authentication methods since you’re talking directly to the token endpoint to get the RPT instead of a special thing. But remember, you needed to talk to the AS to get an AAT previously anyway, so you’ve already needed to have those bits in place in your client.
Really, do whatever you’d have done previously to get the AAT (which required an OAuth transaction with the token endpoint) and use it with the token endpoint to get the RPT now. So you always needed a client ID before anyway, that’s not new, and now you can use your secret or key or nothing just like you used to, but in a different part of the process.
Yes, use the AAT with the token endpoint is what I have in mind. If that is fine and still in sync with the spec for me is fine. But, is there anything in spec about public clients ?
Is it recommended that you use a confidential client where possible? Definitely, as the increased security is well worth the minimal effort that’s usually required. There are a lot of cases where it doesn’t make sense though, like a browser or native app that’s not using dynamic registration. In any event, this is all now directly inherited from OAuth instead of being reinvented from OAuth, as it was in 1.0.
That is exactly one of the use cases we need to support.
— Justin
On Jun 7, 2017, at 10:58 AM, Pedro Igor Silva <psilva@redhat.com <mailto:psilva@redhat.com>> wrote:
Hello,
It has been a long time since my last message to this group. Since then we have implemented quite a few things in Keycloak [1] in order to support fine-grained permissions and UMA 1.0.
We are not full compliant yet and some pieces are still missing in our implementation. But we already have the backbone to start implementing now the rest of the spec.
One of my main tasks is now update our implementation to UMA 2.0 and it seems that one of the main changes is related with the removal of AAT in favor of a specific grant type for UMA.
In UMA 1.0 clients were not really forced to authenticate using client credentials when interacting with the RPT endpoint (Authorization API), but just use a AAT as a bearer token. Now, with UMA 2.0, it seems that clients really need to be confidential and use its credentials (e.g.: id/secret or jwt) to authenticate with the token endpoint when using UMA Grant.
Is that correct ?
[1] https://keycloak.gitbooks.io/documentation/authorization_services/index.html <https://keycloak.gitbooks.io/documentation/authorization_services/index.html>
Thanks. Pedro Igor _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org <mailto:WG-UMA@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/wg-uma <http://kantarainitiative.org/mailman/listinfo/wg-uma>
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org <mailto:WG-UMA@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/wg-uma <http://kantarainitiative.org/mailman/listinfo/wg-uma>
The difference, however subtle or large, is one I'd like to understand. Perhaps it's the subject of a post or blog or presentation. Many times UMA has been suggested to us over Authorize&userinfo, for example protecting the tax return file vs the user authorizing the processing of their tax return. We opted for the latter (since DOR already had the file). I'd like to know when to apply which of these where... if that question made sense. David 🌎 Sent from my iPhone On Jun 10, 2017, at 7:54 AM, Justin Richer <jricher@mit.edu<mailto:jricher@mit.edu>> wrote: UMA-protected access to UserInfo is fine, but it's not an authentication protocol and not OpenID Connect. I think we'd need to be very careful about how it's presented. OAuth has a hard enough time with the whole authentication myth. -- Justin On 6/9/2017 10:11 PM, Eve Maler wrote: Angry, never. :) Excited about the demand, and that UMA 2.0 looks relevant for meeting that demand. Agreed about an UMA-protected UserInfo being interesting and pretty doable. And given that it would be synergistic with UMA authorization itself, perhaps it's finally time for interested parties to work on that... BTW, don't forget that the Public Comment period closes July 12, so if you have implementation feedback, our best chance for addressing it would be to have comments submitted during this period. Eve Maler Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Thu, Jun 8, 2017 at 10:35 AM, Pedro Igor Silva <psilva@redhat.com<mailto:psilva@redhat.com>> wrote: On Thu, Jun 8, 2017 at 2:05 PM, Eve Maler <eve@xmlgrrl.com<mailto:eve@xmlgrrl.com>> wrote: Welcome back, Pedro! A few notes: Thanks, Eve. * Aren't many other grant types applicable to multiple client types? And if someone is interested to restrict the UMA grant to apply only to confidential clients by writing a formal profile, we have the example of the extension Assertion Framework<https://tools.ietf.org/html/rfc7521>, which gets specialized by the SAML bearer assertion profile<https://tools.ietf.org/html/rfc7522> (not that the latter actually does this particular kind of specialization...). Yes. You just nailed down the points I've brought to this discussion. Although not mentioned explicitly in UMA 2.0, we can authenticate clients when doing UMA Grant by pushing a previously issued access token. Just wanted to make it clear and confirm we could follow this path with a bless from the expert group. As I did not find anything explicitly in the specs, I found better to ask first before coding. * It would be good to learn more about the contexts in which you're using OIDC. From time to time, we've talked about the potential benefits of a sort of "OIDC or at least UserInfo endpoint that is UMA-protected", because then the resource owner could share standardized identity data with autonomous third parties, gain positive control over that data, not have to be present when the data is requested, etc. In fact, a person in a requesting party role could potentially use this mechanism to protect the claims sought by a resource owner's AS for authorization assessment. For sure there are a lot of benefits for resource owners in protecting UserInfo with UMA. And I don't think this is something hard to achieve if you have UserInfo and its data/claims properly represented as resources and scopes in the AS. I know you'll get angry with me :) But right now we don't fully support UMA. Our plan is now focus on updating our stuff to UMA 2.0 and implement the missing pieces. We have very limited resources to work on this and our requirements are really driven by demands from our community and customers. But we already had people asking for more features from UMA, specially those related with user managed access/resource sharing (the honeypot). * We do not yet have an interop or testing conformance program, but the number of serious requests is increasing, and we put some effort into this in the past. Time to pick up where we left off; I will make a note to follow up. Great, thanks for the update. Eve Maler Cell +1 425.345.6756<tel:%28425%29%20345-6756> | Skype: xmlgrrl | Twitter: @xmlgrrl On Thu, Jun 8, 2017 at 5:57 AM, Justin Richer <jricher@mit.edu<mailto:jricher@mit.edu>> wrote: You're conflating the grant type (and its associated redirect) with public clients. They're two separate aspects of the protocol and are not tightly tied together, though you do often find one with the other. It's not "public clients" that obtain tokens from the authorization endpoint, it's "implicit grant" clients. You can use a public client with non-implicit flows if you want to -- in fact, a public client with the authorization code flow (and PKCE) is the recommended method for native applications these days. You don't use the implicit grant with UMA, you use the UMA grant. The UMA grant doesn't use the authorization endpoint at all. There is no "implicit UMA grant". If you want to use the UMA grant with an in-browser client, you can do so. The in-browser client just calls the token endpoint like any other client would. I don't understand your statement about a bearer token instead of the implicit grant -- if you're doing the implicit grant today in just about every implementation, you're getting a bearer token. And to do UMA you need to do the UMA grant anyway, so the implicit grant doesn't apply here. And there aren't standardized non-bearer tokens defined yet, so you're likely doing bearer tokens whether you're doing UMA or plain OAuth anyway. OpenID Connect is built on OAuth, not UMA. There's no definition for doing OpenID Connect on top of UMA, and I would argue that it doesn't really make sense: OpenID Connect is an identity protocol and the whole point is to delegate access to the current user's identity API, which is what OAuth does. UMA would give you access to some other party's identity API, which doesn't tell you who's logged in right now. While they're often used together, they solve very different use cases. Think of it like having a hammer, a saw, and a screwdriver in the toolbox. They're all there for different reasons but you can use them all to build your cabinet or whatever. Hopefully this helps untangle some things. -- Justin On 6/8/2017 7:29 AM, Pedro Igor Silva wrote: OK. Thanks, Justin. OAuth2 spec does cover public clients, which are usually related with usage of a implicit grant. But in UMA 2.0 it seems we have now a specific grant type, which flow and examples are really specific to confidential clients. And more important, UMA grant type does not seem to support redirection which is something essential if you want to support public clients. Based on OAuth2 specs, public clients are able to obtain tokens from the authorization endpoint (not token endpoint) based on their client_id and redirection_uri when using implicit grant. Like I previously mentioned, to avoid using implicit grant we would just support a bearer token when using UMA grant type (and token endpoint). Some of our use cases are related with public clients authenticating with Keycloak based on OpenID Connect where an ID token and AT is already available to them. One last question, this one about UMA compliance. We would like to include Keycloak in the list of UMA implementations after reviewing what we have in order to conform with latest version of the spec. Is there a TCK or some other process we need to follow to achieve this ? On Wed, Jun 7, 2017 at 10:27 PM, Justin Richer <jricher@mit.edu<mailto:jricher@mit.edu>> wrote: There’s nothing in the spec about public clients because it’s all covered in OAuth 2 (RFC6749 specifically). — Justin On Jun 7, 2017, at 12:57 PM, Pedro Igor Silva <psilva@redhat.com<mailto:psilva@redhat.com>> wrote: On Wed, Jun 7, 2017 at 12:21 PM, Justin Richer <jricher@mit.edu<mailto:jricher@mit.edu>> wrote: That is not correct. You can have a public client in UMA 2.0, and in fact you inherit all of the various OAuth client types and authentication methods since you’re talking directly to the token endpoint to get the RPT instead of a special thing. But remember, you needed to talk to the AS to get an AAT previously anyway, so you’ve already needed to have those bits in place in your client. Really, do whatever you’d have done previously to get the AAT (which required an OAuth transaction with the token endpoint) and use it with the token endpoint to get the RPT now. So you always needed a client ID before anyway, that’s not new, and now you can use your secret or key or nothing just like you used to, but in a different part of the process. Yes, use the AAT with the token endpoint is what I have in mind. If that is fine and still in sync with the spec for me is fine. But, is there anything in spec about public clients ? Is it recommended that you use a confidential client where possible? Definitely, as the increased security is well worth the minimal effort that’s usually required. There are a lot of cases where it doesn’t make sense though, like a browser or native app that’s not using dynamic registration. In any event, this is all now directly inherited from OAuth instead of being reinvented from OAuth, as it was in 1.0. That is exactly one of the use cases we need to support. — Justin On Jun 7, 2017, at 10:58 AM, Pedro Igor Silva <psilva@redhat.com<mailto:psilva@redhat.com>> wrote: Hello, It has been a long time since my last message to this group. Since then we have implemented quite a few things in Keycloak [1] in order to support fine-grained permissions and UMA 1.0. We are not full compliant yet and some pieces are still missing in our implementation. But we already have the backbone to start implementing now the rest of the spec. One of my main tasks is now update our implementation to UMA 2.0 and it seems that one of the main changes is related with the removal of AAT in favor of a specific grant type for UMA. In UMA 1.0 clients were not really forced to authenticate using client credentials when interacting with the RPT endpoint (Authorization API), but just use a AAT as a bearer token. Now, with UMA 2.0, it seems that clients really need to be confidential and use its credentials (e.g.: id/secret or jwt) to authenticate with the token endpoint when using UMA Grant. Is that correct ? [1] https://keycloak.gitbooks.io/documentation/authorization_services/index.html Thanks. Pedro Igor _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org<mailto:WG-UMA@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/wg-uma _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org<mailto:WG-UMA@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/wg-uma _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org<mailto:WG-UMA@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/wg-uma ________________________________ This message is only for the use of the intended recipient and may contain information that is CONFIDENTIAL and PROPRIETARY to MorphoTrust USA, LLC. If you are not the intended recipient, please erase all copies of the message and its attachments and notify the sender immediately.
I'd call it user-managed access to an identity claims API (y'know, a "user info endpoint" :-) ). That endpoint would have the benefit of being already pretty well standardized, but UMA-protecting it wouldn't be primarily for the purpose of authentication of the user in question. (Actually, the OAuth authorization endpoint is still where that happens in OIDC...but I digress, and that's the myth problem Justin was talking about.) It would be primarily for the purpose of enabling selective sharing/constrained delegated access to that user info. Eve Maler (sent from my iPad) | cell +1 425 345 6756
On Jun 10, 2017, at 6:33 AM, Kelts, David <DKelts@morphotrust.com> wrote:
The difference, however subtle or large, is one I'd like to understand. Perhaps it's the subject of a post or blog or presentation.
Many times UMA has been suggested to us over Authorize&userinfo, for example protecting the tax return file vs the user authorizing the processing of their tax return. We opted for the latter (since DOR already had the file).
I'd like to know when to apply which of these where... if that question made sense.
David
🌎 Sent from my iPhone
On Jun 10, 2017, at 7:54 AM, Justin Richer <jricher@mit.edu> wrote:
UMA-protected access to UserInfo is fine, but it's not an authentication protocol and not OpenID Connect. I think we'd need to be very careful about how it's presented. OAuth has a hard enough time with the whole authentication myth.
-- Justin
On 6/9/2017 10:11 PM, Eve Maler wrote: Angry, never. :) Excited about the demand, and that UMA 2.0 looks relevant for meeting that demand.
Agreed about an UMA-protected UserInfo being interesting and pretty doable. And given that it would be synergistic with UMA authorization itself, perhaps it's finally time for interested parties to work on that...
BTW, don't forget that the Public Comment period closes July 12, so if you have implementation feedback, our best chance for addressing it would be to have comments submitted during this period.
Eve Maler Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
On Thu, Jun 8, 2017 at 10:35 AM, Pedro Igor Silva <psilva@redhat.com> wrote:
On Thu, Jun 8, 2017 at 2:05 PM, Eve Maler <eve@xmlgrrl.com> wrote: Welcome back, Pedro! A few notes:
Thanks, Eve.
Aren't many other grant types applicable to multiple client types? And if someone is interested to restrict the UMA grant to apply only to confidential clients by writing a formal profile, we have the example of the extension Assertion Framework, which gets specialized by the SAML bearer assertion profile (not that the latter actually does this particular kind of specialization...).
Yes. You just nailed down the points I've brought to this discussion. Although not mentioned explicitly in UMA 2.0, we can authenticate clients when doing UMA Grant by pushing a previously issued access token. Just wanted to make it clear and confirm we could follow this path with a bless from the expert group. As I did not find anything explicitly in the specs, I found better to ask first before coding.
It would be good to learn more about the contexts in which you're using OIDC. From time to time, we've talked about the potential benefits of a sort of "OIDC or at least UserInfo endpoint that is UMA-protected", because then the resource owner could share standardized identity data with autonomous third parties, gain positive control over that data, not have to be present when the data is requested, etc. In fact, a person in a requesting party role could potentially use this mechanism to protect the claims sought by a resource owner's AS for authorization assessment.
For sure there are a lot of benefits for resource owners in protecting UserInfo with UMA. And I don't think this is something hard to achieve if you have UserInfo and its data/claims properly represented as resources and scopes in the AS.
I know you'll get angry with me :) But right now we don't fully support UMA. Our plan is now focus on updating our stuff to UMA 2.0 and implement the missing pieces. We have very limited resources to work on this and our requirements are really driven by demands from our community and customers. But we already had people asking for more features from UMA, specially those related with user managed access/resource sharing (the honeypot).
We do not yet have an interop or testing conformance program, but the number of serious requests is increasing, and we put some effort into this in the past. Time to pick up where we left off; I will make a note to follow up.
Great, thanks for the update.
Eve Maler Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
On Thu, Jun 8, 2017 at 5:57 AM, Justin Richer <jricher@mit.edu> wrote: You're conflating the grant type (and its associated redirect) with public clients. They're two separate aspects of the protocol and are not tightly tied together, though you do often find one with the other. It's not "public clients" that obtain tokens from the authorization endpoint, it's "implicit grant" clients. You can use a public client with non-implicit flows if you want to -- in fact, a public client with the authorization code flow (and PKCE) is the recommended method for native applications these days. You don't use the implicit grant with UMA, you use the UMA grant. The UMA grant doesn't use the authorization endpoint at all. There is no "implicit UMA grant". If you want to use the UMA grant with an in-browser client, you can do so. The in-browser client just calls the token endpoint like any other client would. I don't understand your statement about a bearer token instead of the implicit grant -- if you're doing the implicit grant today in just about every implementation, you're getting a bearer token. And to do UMA you need to do the UMA grant anyway, so the implicit grant doesn't apply here. And there aren't standardized non-bearer tokens defined yet, so you're likely doing bearer tokens whether you're doing UMA or plain OAuth anyway. OpenID Connect is built on OAuth, not UMA. There's no definition for doing OpenID Connect on top of UMA, and I would argue that it doesn't really make sense: OpenID Connect is an identity protocol and the whole point is to delegate access to the current user's identity API, which is what OAuth does. UMA would give you access to some other party's identity API, which doesn't tell you who's logged in right now. While they're often used together, they solve very different use cases. Think of it like having a hammer, a saw, and a screwdriver in the toolbox. They're all there for different reasons but you can use them all to build your cabinet or whatever.
Hopefully this helps untangle some things.
-- Justin
> On 6/8/2017 7:29 AM, Pedro Igor Silva wrote: > OK. Thanks, Justin. > > OAuth2 spec does cover public clients, which are usually related with usage of a implicit grant. But in UMA 2.0 it seems we have now a specific grant type, which flow and examples are really specific to confidential clients. And more important, UMA grant type does not seem to support redirection which is something essential if you want to support public clients. Based on OAuth2 specs, public clients are able to obtain tokens from the authorization endpoint (not token endpoint) based on their client_id and redirection_uri when using implicit grant. > > Like I previously mentioned, to avoid using implicit grant we would just support a bearer token when using UMA grant type (and token endpoint). Some of our use cases are related with public clients authenticating with Keycloak based on OpenID Connect where an ID token and AT is already available to them. > > One last question, this one about UMA compliance. We would like to include Keycloak in the list of UMA implementations after reviewing what we have in order to conform with latest version of the spec. Is there a TCK or some other process we need to follow to achieve this ? > >> On Wed, Jun 7, 2017 at 10:27 PM, Justin Richer <jricher@mit.edu> wrote: >> There’s nothing in the spec about public clients because it’s all covered in OAuth 2 (RFC6749 specifically). >> >> — Justin >> >>> On Jun 7, 2017, at 12:57 PM, Pedro Igor Silva <psilva@redhat.com> wrote: >>> >>> >>>> On Wed, Jun 7, 2017 at 12:21 PM, Justin Richer <jricher@mit.edu> wrote: >>>> That is not correct. You can have a public client in UMA 2.0, and in fact you inherit all of the various OAuth client types and authentication methods since you’re talking directly to the token endpoint to get the RPT instead of a special thing. But remember, you needed to talk to the AS to get an AAT previously anyway, so you’ve already needed to have those bits in place in your client. >>>> >>>> Really, do whatever you’d have done previously to get the AAT (which required an OAuth transaction with the token endpoint) and use it with the token endpoint to get the RPT now. So you always needed a client ID before anyway, that’s not new, and now you can use your secret or key or nothing just like you used to, but in a different part of the process. >>> >>> Yes, use the AAT with the token endpoint is what I have in mind. If that is fine and still in sync with the spec for me is fine. But, is there anything in spec about public clients ? >>> >>>> >>>> Is it recommended that you use a confidential client where possible? Definitely, as the increased security is well worth the minimal effort that’s usually required. There are a lot of cases where it doesn’t make sense though, like a browser or native app that’s not using dynamic registration. In any event, this is all now directly inherited from OAuth instead of being reinvented from OAuth, as it was in 1.0. >>> >>> That is exactly one of the use cases we need to support. >>> >>>> >>>> >>>> — Justin >>>> >>>>> On Jun 7, 2017, at 10:58 AM, Pedro Igor Silva <psilva@redhat.com> wrote: >>>>> >>>>> Hello, >>>>> >>>>> It has been a long time since my last message to this group. Since then we have implemented quite a few things in Keycloak [1] in order to support fine-grained permissions and UMA 1.0. >>>>> >>>>> We are not full compliant yet and some pieces are still missing in our implementation. But we already have the backbone to start implementing now the rest of the spec. >>>>> >>>>> One of my main tasks is now update our implementation to UMA 2.0 and it seems that one of the main changes is related with the removal of AAT in favor of a specific grant type for UMA. >>>>> >>>>> In UMA 1.0 clients were not really forced to authenticate using client credentials when interacting with the RPT endpoint (Authorization API), but just use a AAT as a bearer token. Now, with UMA 2.0, it seems that clients really need to be confidential and use its credentials (e.g.: id/secret or jwt) to authenticate with the token endpoint when using UMA Grant. >>>>> >>>>> Is that correct ? >>>>> >>>>> [1] https://keycloak.gitbooks.io/documentation/authorization_services/index.html >>>>> >>>>> Thanks. >>>>> Pedro Igor >>>>> _______________________________________________ >>>>> WG-UMA mailing list >>>>> WG-UMA@kantarainitiative.org >>>>> http://kantarainitiative.org/mailman/listinfo/wg-uma >>>> >>> >> >
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
This message is only for the use of the intended recipient and may contain information that is CONFIDENTIAL and PROPRIETARY to MorphoTrust USA, LLC. If you are not the intended recipient, please erase all copies of the message and its attachments and notify the sender immediately.
To get more specific: If you were to use the UMA grant to protect a UserInfo endpoint, you'd switch to using a claims interaction endpoint, vs using an authorization endpoint, in dealing with attempted access by a requesting party. The purpose is to vet their access to the resource owner's UserInfo endpoint. (Small detail: Claims collection could also be done non-interactively.) Is it possible that, with UMA2 and the extension grant, this mashup would be more straightforward than previously? Eve (sent from my iPhone, possibly with Siri's "help": +1-425-345-6756)
On Jun 10, 2017, at 8:51 AM, Eve Maler <eve@xmlgrrl.com> wrote:
I'd call it user-managed access to an identity claims API (y'know, a "user info endpoint" :-) ). That endpoint would have the benefit of being already pretty well standardized, but UMA-protecting it wouldn't be primarily for the purpose of authentication of the user in question. (Actually, the OAuth authorization endpoint is still where that happens in OIDC...but I digress, and that's the myth problem Justin was talking about.) It would be primarily for the purpose of enabling selective sharing/constrained delegated access to that user info.
Eve Maler (sent from my iPad) | cell +1 425 345 6756
On Jun 10, 2017, at 6:33 AM, Kelts, David <DKelts@morphotrust.com> wrote:
The difference, however subtle or large, is one I'd like to understand. Perhaps it's the subject of a post or blog or presentation.
Many times UMA has been suggested to us over Authorize&userinfo, for example protecting the tax return file vs the user authorizing the processing of their tax return. We opted for the latter (since DOR already had the file).
I'd like to know when to apply which of these where... if that question made sense.
David
🌎 Sent from my iPhone
On Jun 10, 2017, at 7:54 AM, Justin Richer <jricher@mit.edu> wrote:
UMA-protected access to UserInfo is fine, but it's not an authentication protocol and not OpenID Connect. I think we'd need to be very careful about how it's presented. OAuth has a hard enough time with the whole authentication myth.
-- Justin
On 6/9/2017 10:11 PM, Eve Maler wrote: Angry, never. :) Excited about the demand, and that UMA 2.0 looks relevant for meeting that demand.
Agreed about an UMA-protected UserInfo being interesting and pretty doable. And given that it would be synergistic with UMA authorization itself, perhaps it's finally time for interested parties to work on that...
BTW, don't forget that the Public Comment period closes July 12, so if you have implementation feedback, our best chance for addressing it would be to have comments submitted during this period.
Eve Maler Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
On Thu, Jun 8, 2017 at 10:35 AM, Pedro Igor Silva <psilva@redhat.com> wrote:
On Thu, Jun 8, 2017 at 2:05 PM, Eve Maler <eve@xmlgrrl.com> wrote: Welcome back, Pedro! A few notes:
Thanks, Eve.
Aren't many other grant types applicable to multiple client types? And if someone is interested to restrict the UMA grant to apply only to confidential clients by writing a formal profile, we have the example of the extension Assertion Framework, which gets specialized by the SAML bearer assertion profile (not that the latter actually does this particular kind of specialization...).
Yes. You just nailed down the points I've brought to this discussion. Although not mentioned explicitly in UMA 2.0, we can authenticate clients when doing UMA Grant by pushing a previously issued access token. Just wanted to make it clear and confirm we could follow this path with a bless from the expert group. As I did not find anything explicitly in the specs, I found better to ask first before coding.
It would be good to learn more about the contexts in which you're using OIDC. From time to time, we've talked about the potential benefits of a sort of "OIDC or at least UserInfo endpoint that is UMA-protected", because then the resource owner could share standardized identity data with autonomous third parties, gain positive control over that data, not have to be present when the data is requested, etc. In fact, a person in a requesting party role could potentially use this mechanism to protect the claims sought by a resource owner's AS for authorization assessment.
For sure there are a lot of benefits for resource owners in protecting UserInfo with UMA. And I don't think this is something hard to achieve if you have UserInfo and its data/claims properly represented as resources and scopes in the AS.
I know you'll get angry with me :) But right now we don't fully support UMA. Our plan is now focus on updating our stuff to UMA 2.0 and implement the missing pieces. We have very limited resources to work on this and our requirements are really driven by demands from our community and customers. But we already had people asking for more features from UMA, specially those related with user managed access/resource sharing (the honeypot).
We do not yet have an interop or testing conformance program, but the number of serious requests is increasing, and we put some effort into this in the past. Time to pick up where we left off; I will make a note to follow up.
Great, thanks for the update.
Eve Maler Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
> On Thu, Jun 8, 2017 at 5:57 AM, Justin Richer <jricher@mit.edu> wrote: > You're conflating the grant type (and its associated redirect) with public clients. They're two separate aspects of the protocol and are not tightly tied together, though you do often find one with the other. It's not "public clients" that obtain tokens from the authorization endpoint, it's "implicit grant" clients. You can use a public client with non-implicit flows if you want to -- in fact, a public client with the authorization code flow (and PKCE) is the recommended method for native applications these days. > You don't use the implicit grant with UMA, you use the UMA grant. The UMA grant doesn't use the authorization endpoint at all. There is no "implicit UMA grant". If you want to use the UMA grant with an in-browser client, you can do so. The in-browser client just calls the token endpoint like any other client would. > I don't understand your statement about a bearer token instead of the implicit grant -- if you're doing the implicit grant today in just about every implementation, you're getting a bearer token. And to do UMA you need to do the UMA grant anyway, so the implicit grant doesn't apply here. And there aren't standardized non-bearer tokens defined yet, so you're likely doing bearer tokens whether you're doing UMA or plain OAuth anyway. > OpenID Connect is built on OAuth, not UMA. There's no definition for doing OpenID Connect on top of UMA, and I would argue that it doesn't really make sense: OpenID Connect is an identity protocol and the whole point is to delegate access to the current user's identity API, which is what OAuth does. UMA would give you access to some other party's identity API, which doesn't tell you who's logged in right now. While they're often used together, they solve very different use cases. Think of it like having a hammer, a saw, and a screwdriver in the toolbox. They're all there for different reasons but you can use them all to build your cabinet or whatever. > > Hopefully this helps untangle some things. > > -- Justin > >> On 6/8/2017 7:29 AM, Pedro Igor Silva wrote: >> OK. Thanks, Justin. >> >> OAuth2 spec does cover public clients, which are usually related with usage of a implicit grant. But in UMA 2.0 it seems we have now a specific grant type, which flow and examples are really specific to confidential clients. And more important, UMA grant type does not seem to support redirection which is something essential if you want to support public clients. Based on OAuth2 specs, public clients are able to obtain tokens from the authorization endpoint (not token endpoint) based on their client_id and redirection_uri when using implicit grant. >> >> Like I previously mentioned, to avoid using implicit grant we would just support a bearer token when using UMA grant type (and token endpoint). Some of our use cases are related with public clients authenticating with Keycloak based on OpenID Connect where an ID token and AT is already available to them. >> >> One last question, this one about UMA compliance. We would like to include Keycloak in the list of UMA implementations after reviewing what we have in order to conform with latest version of the spec. Is there a TCK or some other process we need to follow to achieve this ? >> >>> On Wed, Jun 7, 2017 at 10:27 PM, Justin Richer <jricher@mit.edu> wrote: >>> There’s nothing in the spec about public clients because it’s all covered in OAuth 2 (RFC6749 specifically). >>> >>> — Justin >>> >>>> On Jun 7, 2017, at 12:57 PM, Pedro Igor Silva <psilva@redhat.com> wrote: >>>> >>>> >>>>> On Wed, Jun 7, 2017 at 12:21 PM, Justin Richer <jricher@mit.edu> wrote: >>>>> That is not correct. You can have a public client in UMA 2.0, and in fact you inherit all of the various OAuth client types and authentication methods since you’re talking directly to the token endpoint to get the RPT instead of a special thing. But remember, you needed to talk to the AS to get an AAT previously anyway, so you’ve already needed to have those bits in place in your client. >>>>> >>>>> Really, do whatever you’d have done previously to get the AAT (which required an OAuth transaction with the token endpoint) and use it with the token endpoint to get the RPT now. So you always needed a client ID before anyway, that’s not new, and now you can use your secret or key or nothing just like you used to, but in a different part of the process. >>>> >>>> Yes, use the AAT with the token endpoint is what I have in mind. If that is fine and still in sync with the spec for me is fine. But, is there anything in spec about public clients ? >>>> >>>>> >>>>> Is it recommended that you use a confidential client where possible? Definitely, as the increased security is well worth the minimal effort that’s usually required. There are a lot of cases where it doesn’t make sense though, like a browser or native app that’s not using dynamic registration. In any event, this is all now directly inherited from OAuth instead of being reinvented from OAuth, as it was in 1.0. >>>> >>>> That is exactly one of the use cases we need to support. >>>> >>>>> >>>>> >>>>> — Justin >>>>> >>>>>> On Jun 7, 2017, at 10:58 AM, Pedro Igor Silva <psilva@redhat.com> wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> It has been a long time since my last message to this group. Since then we have implemented quite a few things in Keycloak [1] in order to support fine-grained permissions and UMA 1.0. >>>>>> >>>>>> We are not full compliant yet and some pieces are still missing in our implementation. But we already have the backbone to start implementing now the rest of the spec. >>>>>> >>>>>> One of my main tasks is now update our implementation to UMA 2.0 and it seems that one of the main changes is related with the removal of AAT in favor of a specific grant type for UMA. >>>>>> >>>>>> In UMA 1.0 clients were not really forced to authenticate using client credentials when interacting with the RPT endpoint (Authorization API), but just use a AAT as a bearer token. Now, with UMA 2.0, it seems that clients really need to be confidential and use its credentials (e.g.: id/secret or jwt) to authenticate with the token endpoint when using UMA Grant. >>>>>> >>>>>> Is that correct ? >>>>>> >>>>>> [1] https://keycloak.gitbooks.io/documentation/authorization_services/index.html >>>>>> >>>>>> Thanks. >>>>>> Pedro Igor >>>>>> _______________________________________________ >>>>>> WG-UMA mailing list >>>>>> WG-UMA@kantarainitiative.org >>>>>> http://kantarainitiative.org/mailman/listinfo/wg-uma >>>>> >>>> >>> >> > > > _______________________________________________ > WG-UMA mailing list > WG-UMA@kantarainitiative.org > http://kantarainitiative.org/mailman/listinfo/wg-uma >
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
This message is only for the use of the intended recipient and may contain information that is CONFIDENTIAL and PROPRIETARY to MorphoTrust USA, LLC. If you are not the intended recipient, please erase all copies of the message and its attachments and notify the sender immediately.
On Thu, Jun 8, 2017 at 9:57 AM, Justin Richer <jricher@mit.edu> wrote:
OpenID Connect is built on OAuth, not UMA. There's no definition for doing OpenID Connect on top of UMA, and I would argue that it doesn't really make sense: OpenID Connect is an identity protocol and the whole point is to delegate access to the current user's identity API, which is what OAuth does. UMA would give you access to some other party's identity API, which doesn't tell you who's logged in right now. While they're often used together, they solve very different use cases. Think of it like having a hammer, a saw, and a screwdriver in the toolbox. They're all there for different reasons but you can use them all to build your cabinet or whatever.
Hopefully this helps untangle some things.
That is what we do. And our efforts are now in providing to our users the different areas supported by both specs :) Yes, you helped a lot to clarify some bits. Thanks again for the discussion.
-- Justin
On 6/8/2017 7:29 AM, Pedro Igor Silva wrote:
OK. Thanks, Justin.
OAuth2 spec does cover public clients, which are usually related with usage of a implicit grant. But in UMA 2.0 it seems we have now a specific grant type, which flow and examples are really specific to confidential clients. And more important, UMA grant type does not seem to support redirection which is something essential if you want to support public clients. Based on OAuth2 specs, public clients are able to obtain tokens from the authorization endpoint (not token endpoint) based on their client_id and redirection_uri when using implicit grant.
Like I previously mentioned, to avoid using implicit grant we would just support a bearer token when using UMA grant type (and token endpoint). Some of our use cases are related with public clients authenticating with Keycloak based on OpenID Connect where an ID token and AT is already available to them.
One last question, this one about UMA compliance. We would like to include Keycloak in the list of UMA implementations after reviewing what we have in order to conform with latest version of the spec. Is there a TCK or some other process we need to follow to achieve this ?
On Wed, Jun 7, 2017 at 10:27 PM, Justin Richer <jricher@mit.edu> wrote:
There’s nothing in the spec about public clients because it’s all covered in OAuth 2 (RFC6749 specifically).
— Justin
On Jun 7, 2017, at 12:57 PM, Pedro Igor Silva <psilva@redhat.com> wrote:
On Wed, Jun 7, 2017 at 12:21 PM, Justin Richer <jricher@mit.edu> wrote:
That is not correct. You can have a public client in UMA 2.0, and in fact you inherit all of the various OAuth client types and authentication methods since you’re talking directly to the token endpoint to get the RPT instead of a special thing. But remember, you needed to talk to the AS to get an AAT previously anyway, so you’ve already needed to have those bits in place in your client.
Really, do whatever you’d have done previously to get the AAT (which required an OAuth transaction with the token endpoint) and use it with the token endpoint to get the RPT now. So you always needed a client ID before anyway, that’s not new, and now you can use your secret or key or nothing just like you used to, but in a different part of the process.
Yes, use the AAT with the token endpoint is what I have in mind. If that is fine and still in sync with the spec for me is fine. But, is there anything in spec about public clients ?
Is it recommended that you use a confidential client where possible? Definitely, as the increased security is well worth the minimal effort that’s usually required. There are a lot of cases where it doesn’t make sense though, like a browser or native app that’s not using dynamic registration. In any event, this is all now directly inherited from OAuth instead of being reinvented from OAuth, as it was in 1.0.
That is exactly one of the use cases we need to support.
— Justin
On Jun 7, 2017, at 10:58 AM, Pedro Igor Silva <psilva@redhat.com> wrote:
Hello,
It has been a long time since my last message to this group. Since then we have implemented quite a few things in Keycloak [1] in order to support fine-grained permissions and UMA 1.0.
We are not full compliant yet and some pieces are still missing in our implementation. But we already have the backbone to start implementing now the rest of the spec.
One of my main tasks is now update our implementation to UMA 2.0 and it seems that one of the main changes is related with the removal of AAT in favor of a specific grant type for UMA.
In UMA 1.0 clients were not really forced to authenticate using client credentials when interacting with the RPT endpoint (Authorization API), but just use a AAT as a bearer token. Now, with UMA 2.0, it seems that clients really need to be confidential and use its credentials (e.g.: id/secret or jwt) to authenticate with the token endpoint when using UMA Grant.
Is that correct ?
[1] https://keycloak.gitbooks.io/documentation/authorization _services/index.html
Thanks. Pedro Igor _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
participants (4)
-
Eve Maler -
Justin Richer -
Kelts, David -
Pedro Igor Silva