Two thoughts for UMA enhancments
UMA-tarians, Can we discuss two ideas for enhancments: 1) UMA sans permission ticket Let's say the UMA Client knows the scopes required to call a certain API. For example, Google documents this: http://gluu.co/google-scopes In this case, perhaps the client can proactively request an RPT providing the scopes. And this RPT might be acceptable a certain RS for certain resource sets. We might have already discussed this, but wouldn't this make UMA more compatable with existing API access management infrastructures? 2) UMA without the AAT Inspired by Justin. I think the AAT adds value in many cases where the AS wants to make policies based on client claims (client id, domain specific catagory, etc). So I'm not saying eliminate the AAT. However, if the policy for access is based on network address only, or perhaps some other fraud detection technique that doesn't involve client identification, I could see a case where the AAT is not needed. So maybe the AAT could be optional? - Mike ------------------------------------- Michael Schwartz Gluu Founder / CEO mike@gluu.org
Hi Mike-- We do have an open issue for the latter, and I think one of our open issues (maybe even the same one) might have a suggested flow that encompasses the former. I know Justin is keen to explore his proposed flow along AAT-less lines, and you and JamesP were going back and forth on a somewhat related topic recently as well. If we can get the Business/Legal work on a firm footing by the end of the year, and establish the status of our budget proposals (note that if we get the budget, these will need requirements work and oversight on our part), then we can start to entertain "next-gen" Technical efforts at the right point in 2016. Sounds like "kick off roadmap and charter refresh discussions" should be on the agenda I'm working on right now... *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Wed, Dec 9, 2015 at 12:36 PM, Mike Schwartz <mike@gluu.org> wrote:
UMA-tarians,
Can we discuss two ideas for enhancments:
1) UMA sans permission ticket
Let's say the UMA Client knows the scopes required to call a certain API. For example, Google documents this: http://gluu.co/google-scopes
In this case, perhaps the client can proactively request an RPT providing the scopes. And this RPT might be acceptable a certain RS for certain resource sets.
We might have already discussed this, but wouldn't this make UMA more compatable with existing API access management infrastructures?
2) UMA without the AAT
Inspired by Justin. I think the AAT adds value in many cases where the AS wants to make policies based on client claims (client id, domain specific catagory, etc). So I'm not saying eliminate the AAT. However, if the policy for access is based on network address only, or perhaps some other fraud detection technique that doesn't involve client identification, I could see a case where the AAT is not needed. So maybe the AAT could be optional?
- Mike
------------------------------------- Michael Schwartz Gluu Founder / CEO mike@gluu.org _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
----- Original Message -----
From: "Mike Schwartz" <mike@gluu.org> To: wg-uma@kantarainitiative.org Sent: Wednesday, December 9, 2015 6:36:32 PM Subject: [WG-UMA] Two thoughts for UMA enhancments
UMA-tarians,
Can we discuss two ideas for enhancments:
1) UMA sans permission ticket
Let's say the UMA Client knows the scopes required to call a certain API. For example, Google documents this: http://gluu.co/google-scopes
In this case, perhaps the client can proactively request an RPT providing the scopes. And this RPT might be acceptable a certain RS for certain resource sets.
We might have already discussed this, but wouldn't this make UMA more compatable with existing API access management infrastructures?
2) UMA without the AAT
Inspired by Justin. I think the AAT adds value in many cases where the AS wants to make policies based on client claims (client id, domain specific catagory, etc). So I'm not saying eliminate the AAT. However, if the policy for access is based on network address only, or perhaps some other fraud detection technique that doesn't involve client identification, I could see a case where the AAT is not needed. So maybe the AAT could be optional?
- Mike
What about the case below ? I think it was lost because I was not able to send messages to this list ... "I think that when you are in NPE scenario, the permission ticket does not make much sense. This is pretty much related with my second round of questions. Please correct me if I'm wrong. It seems that the permission ticket is mostly intended to perform a transactional authorization flow, where a RqP will ask permissions to access some one resources and the RO will be able to receive some kind of notification and actually approve this permission any time in the future. Or even to support multiple ASs within the same RS, where the user can choose which AS should be used to obtain permissions for his resources. Here I can see a lot of value, like for cloud and IoT authz ... However, considering NPE use cases, specially when the RO is the RS, a 1:1 relationship between RS and AS and there is no need for a transactional authorization flow given that RS is protecting its own resources, it might be unnecessary to use a permission ticket in this case. But just: 1) Client tries to access protected resource on behalf of an user (no RPT was sent) 2) RS obtain a RPT for the resource (or with additional resources and scopes) from AS 3) RS validates the response from AS, validates the RPT, enforce authorization and returns the RPT to the client (considering that RPT has the right permissions)" Any thoughts ?
------------------------------------- Michael Schwartz Gluu Founder / CEO mike@gluu.org _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
Pedro, It doesn't make sense to me that the RS would obtain the RPT... Personally, I like the design of the permission ticket, because the UMA Client does not need to know the scopes. Forcing the UMA Client to know the scopes creates a tight bundling with the security infrastructure, and may expose too much information to the UMA Client. I equate this to hard coding LDAP schema in your application. It puts the infrastructure team in a bad situation if the schema changes, because you need to re-QA the app. However, some people think that just because Google does something, it must be right, or it must scale. So my interest in supporting this feature has more to do with aligning with an existing (bad) pattern. - Mike On 2015-12-09 19:37, Pedro Igor Silva wrote:
----- Original Message -----
From: "Mike Schwartz" <mike@gluu.org> To: wg-uma@kantarainitiative.org Sent: Wednesday, December 9, 2015 6:36:32 PM Subject: [WG-UMA] Two thoughts for UMA enhancments
UMA-tarians,
Can we discuss two ideas for enhancments:
1) UMA sans permission ticket
Let's say the UMA Client knows the scopes required to call a certain API. For example, Google documents this: http://gluu.co/google-scopes
In this case, perhaps the client can proactively request an RPT providing the scopes. And this RPT might be acceptable a certain RS for certain resource sets.
We might have already discussed this, but wouldn't this make UMA more compatable with existing API access management infrastructures?
2) UMA without the AAT
Inspired by Justin. I think the AAT adds value in many cases where the AS wants to make policies based on client claims (client id, domain specific catagory, etc). So I'm not saying eliminate the AAT. However, if the policy for access is based on network address only, or perhaps some other fraud detection technique that doesn't involve client identification, I could see a case where the AAT is not needed. So maybe the AAT could be optional?
- Mike
What about the case below ? I think it was lost because I was not able to send messages to this list ...
"I think that when you are in NPE scenario, the permission ticket does not make much sense. This is pretty much related with my second round of questions.
Please correct me if I'm wrong. It seems that the permission ticket is mostly intended to perform a transactional authorization flow, where a RqP will ask permissions to access some one resources and the RO will be able to receive some kind of notification and actually approve this permission any time in the future. Or even to support multiple ASs within the same RS, where the user can choose which AS should be used to obtain permissions for his resources. Here I can see a lot of value, like for cloud and IoT authz ...
However, considering NPE use cases, specially when the RO is the RS, a 1:1 relationship between RS and AS and there is no need for a transactional authorization flow given that RS is protecting its own resources, it might be unnecessary to use a permission ticket in this case. But just:
1) Client tries to access protected resource on behalf of an user (no RPT was sent) 2) RS obtain a RPT for the resource (or with additional resources and scopes) from AS 3) RS validates the response from AS, validates the RPT, enforce authorization and returns the RPT to the client (considering that RPT has the right permissions)"
Any thoughts ?
------------------------------------- Michael Schwartz Gluu Founder / CEO mike@gluu.org _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
-- ------------------------------------- Michael Schwartz Gluu Founder / CEO mike@gluu.org
Just to clarify, it's not just Google, although they are the largest example. But if we can perhaps achieve some backwards compatability, we might be able to lead to a better design.
Thanks for the reply, Mike. Personally, I also like the design of the permission ticket. Like I mentioned, it has a lot of value in certain circumstances. I also liked your proposal, it already simplifies the flow in some situations. And agree about what you said about clients and "scopes creates a tight bundling with the security infrastructure". Just to clarify, my point is basically based on use cases where a distributed application provides both a client (eg.: HTML5 + AJAX) and a RESTFul API. Where each of them is a specific deployment. In this case, once the client is issued with a OAuth2 Access Token (probably with a uma_authorization scope) it can try to access a resource on the RS, which in turn will ask the AS for a RPT based on the resource and its scopes (or even a wider range of scopes and resources). Here the AS will just evaluate the policies associated with the resources and scopes being asked and return back a RPT representing the permissions. For last, the RS check the RPT for any permission granted to the original resource and return back the RPT to the client. The client doesn't know about scopes or resources ids and don't need to access any other endpoint to obtain a RPT (making it more simple). Another scenario that I'm evaluating is to let the client obtain a RPT with all the permissions for a given user (entitlements). Currently, I'm using a standard UMA-flow (using permission tickets) to obtain this RPT. So the client only needs to obtain the RPT once, during the first interaction of the user. This is useful for permissions based on policies that don't require obligations but just evaluation based on the identity of the user or even contextual information. Regards. Pedro Igor ----- Original Message ----- From: "Mike Schwartz" <mike@gluu.org> To: "Pedro Igor Silva" <psilva@redhat.com> Cc: wg-uma@kantarainitiative.org Sent: Thursday, December 10, 2015 12:23:49 AM Subject: Re: [WG-UMA] Two thoughts for UMA enhancments Pedro, It doesn't make sense to me that the RS would obtain the RPT... Personally, I like the design of the permission ticket, because the UMA Client does not need to know the scopes. Forcing the UMA Client to know the scopes creates a tight bundling with the security infrastructure, and may expose too much information to the UMA Client. I equate this to hard coding LDAP schema in your application. It puts the infrastructure team in a bad situation if the schema changes, because you need to re-QA the app. However, some people think that just because Google does something, it must be right, or it must scale. So my interest in supporting this feature has more to do with aligning with an existing (bad) pattern. - Mike On 2015-12-09 19:37, Pedro Igor Silva wrote:
----- Original Message -----
From: "Mike Schwartz" <mike@gluu.org> To: wg-uma@kantarainitiative.org Sent: Wednesday, December 9, 2015 6:36:32 PM Subject: [WG-UMA] Two thoughts for UMA enhancments
UMA-tarians,
Can we discuss two ideas for enhancments:
1) UMA sans permission ticket
Let's say the UMA Client knows the scopes required to call a certain API. For example, Google documents this: http://gluu.co/google-scopes
In this case, perhaps the client can proactively request an RPT providing the scopes. And this RPT might be acceptable a certain RS for certain resource sets.
We might have already discussed this, but wouldn't this make UMA more compatable with existing API access management infrastructures?
2) UMA without the AAT
Inspired by Justin. I think the AAT adds value in many cases where the AS wants to make policies based on client claims (client id, domain specific catagory, etc). So I'm not saying eliminate the AAT. However, if the policy for access is based on network address only, or perhaps some other fraud detection technique that doesn't involve client identification, I could see a case where the AAT is not needed. So maybe the AAT could be optional?
- Mike
What about the case below ? I think it was lost because I was not able to send messages to this list ...
"I think that when you are in NPE scenario, the permission ticket does not make much sense. This is pretty much related with my second round of questions.
Please correct me if I'm wrong. It seems that the permission ticket is mostly intended to perform a transactional authorization flow, where a RqP will ask permissions to access some one resources and the RO will be able to receive some kind of notification and actually approve this permission any time in the future. Or even to support multiple ASs within the same RS, where the user can choose which AS should be used to obtain permissions for his resources. Here I can see a lot of value, like for cloud and IoT authz ...
However, considering NPE use cases, specially when the RO is the RS, a 1:1 relationship between RS and AS and there is no need for a transactional authorization flow given that RS is protecting its own resources, it might be unnecessary to use a permission ticket in this case. But just:
1) Client tries to access protected resource on behalf of an user (no RPT was sent) 2) RS obtain a RPT for the resource (or with additional resources and scopes) from AS 3) RS validates the response from AS, validates the RPT, enforce authorization and returns the RPT to the client (considering that RPT has the right permissions)"
Any thoughts ?
------------------------------------- Michael Schwartz Gluu Founder / CEO mike@gluu.org _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
-- ------------------------------------- Michael Schwartz Gluu Founder / CEO mike@gluu.org
Hi Mike, Don't forget the as_uri that accompanies the ticket that the RS returns to the UMA Client, in the protocol-step that you're trying to optimize. Maybe the better question is that if you assume you know which scopes to request, and the AS to make that request, why use UMA and not just plain OAuth? Mark On 10/12/15 03:23, Mike Schwartz wrote:
Pedro,
It doesn't make sense to me that the RS would obtain the RPT...
Personally, I like the design of the permission ticket, because the UMA Client does not need to know the scopes. Forcing the UMA Client to know the scopes creates a tight bundling with the security infrastructure, and may expose too much information to the UMA Client. I equate this to hard coding LDAP schema in your application. It puts the infrastructure team in a bad situation if the schema changes, because you need to re-QA the app.
However, some people think that just because Google does something, it must be right, or it must scale. So my interest in supporting this feature has more to do with aligning with an existing (bad) pattern.
- Mike
On 2015-12-09 19:37, Pedro Igor Silva wrote:
----- Original Message -----
From: "Mike Schwartz" <mike@gluu.org> To: wg-uma@kantarainitiative.org Sent: Wednesday, December 9, 2015 6:36:32 PM Subject: [WG-UMA] Two thoughts for UMA enhancments
UMA-tarians,
Can we discuss two ideas for enhancments:
1) UMA sans permission ticket
Let's say the UMA Client knows the scopes required to call a certain API. For example, Google documents this: http://gluu.co/google-scopes
In this case, perhaps the client can proactively request an RPT providing the scopes. And this RPT might be acceptable a certain RS for certain resource sets.
We might have already discussed this, but wouldn't this make UMA more compatable with existing API access management infrastructures?
2) UMA without the AAT
Inspired by Justin. I think the AAT adds value in many cases where the AS wants to make policies based on client claims (client id, domain specific catagory, etc). So I'm not saying eliminate the AAT. However, if the policy for access is based on network address only, or perhaps some other fraud detection technique that doesn't involve client identification, I could see a case where the AAT is not needed. So maybe the AAT could be optional?
- Mike
What about the case below ? I think it was lost because I was not able to send messages to this list ...
"I think that when you are in NPE scenario, the permission ticket does not make much sense. This is pretty much related with my second round of questions.
Please correct me if I'm wrong. It seems that the permission ticket is mostly intended to perform a transactional authorization flow, where a RqP will ask permissions to access some one resources and the RO will be able to receive some kind of notification and actually approve this permission any time in the future. Or even to support multiple ASs within the same RS, where the user can choose which AS should be used to obtain permissions for his resources. Here I can see a lot of value, like for cloud and IoT authz ...
However, considering NPE use cases, specially when the RO is the RS, a 1:1 relationship between RS and AS and there is no need for a transactional authorization flow given that RS is protecting its own resources, it might be unnecessary to use a permission ticket in this case. But just:
1) Client tries to access protected resource on behalf of an user (no RPT was sent) 2) RS obtain a RPT for the resource (or with additional resources and scopes) from AS 3) RS validates the response from AS, validates the RPT, enforce authorization and returns the RPT to the client (considering that RPT has the right permissions)"
Any thoughts ?
------------------------------------- Michael Schwartz Gluu Founder / CEO mike@gluu.org _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
IMO, OAuth2 does not provide a good support for fine-grained authorization like UMA does. Section "3.5.4 Authorization Server Response to Client on Authorization Failure" is an example of that. ----- Original Message ----- From: "Mark Dobrinic" <mdobrinic@cozmanova.com> To: "Mike Schwartz" <mike@gluu.org>, "Pedro Igor Silva" <psilva@redhat.com> Cc: wg-uma@kantarainitiative.org Sent: Thursday, December 10, 2015 10:57:26 AM Subject: Re: [WG-UMA] Two thoughts for UMA enhancments Hi Mike, Don't forget the as_uri that accompanies the ticket that the RS returns to the UMA Client, in the protocol-step that you're trying to optimize. Maybe the better question is that if you assume you know which scopes to request, and the AS to make that request, why use UMA and not just plain OAuth? Mark On 10/12/15 03:23, Mike Schwartz wrote:
Pedro,
It doesn't make sense to me that the RS would obtain the RPT...
Personally, I like the design of the permission ticket, because the UMA Client does not need to know the scopes. Forcing the UMA Client to know the scopes creates a tight bundling with the security infrastructure, and may expose too much information to the UMA Client. I equate this to hard coding LDAP schema in your application. It puts the infrastructure team in a bad situation if the schema changes, because you need to re-QA the app.
However, some people think that just because Google does something, it must be right, or it must scale. So my interest in supporting this feature has more to do with aligning with an existing (bad) pattern.
- Mike
On 2015-12-09 19:37, Pedro Igor Silva wrote:
----- Original Message -----
From: "Mike Schwartz" <mike@gluu.org> To: wg-uma@kantarainitiative.org Sent: Wednesday, December 9, 2015 6:36:32 PM Subject: [WG-UMA] Two thoughts for UMA enhancments
UMA-tarians,
Can we discuss two ideas for enhancments:
1) UMA sans permission ticket
Let's say the UMA Client knows the scopes required to call a certain API. For example, Google documents this: http://gluu.co/google-scopes
In this case, perhaps the client can proactively request an RPT providing the scopes. And this RPT might be acceptable a certain RS for certain resource sets.
We might have already discussed this, but wouldn't this make UMA more compatable with existing API access management infrastructures?
2) UMA without the AAT
Inspired by Justin. I think the AAT adds value in many cases where the AS wants to make policies based on client claims (client id, domain specific catagory, etc). So I'm not saying eliminate the AAT. However, if the policy for access is based on network address only, or perhaps some other fraud detection technique that doesn't involve client identification, I could see a case where the AAT is not needed. So maybe the AAT could be optional?
- Mike
What about the case below ? I think it was lost because I was not able to send messages to this list ...
"I think that when you are in NPE scenario, the permission ticket does not make much sense. This is pretty much related with my second round of questions.
Please correct me if I'm wrong. It seems that the permission ticket is mostly intended to perform a transactional authorization flow, where a RqP will ask permissions to access some one resources and the RO will be able to receive some kind of notification and actually approve this permission any time in the future. Or even to support multiple ASs within the same RS, where the user can choose which AS should be used to obtain permissions for his resources. Here I can see a lot of value, like for cloud and IoT authz ...
However, considering NPE use cases, specially when the RO is the RS, a 1:1 relationship between RS and AS and there is no need for a transactional authorization flow given that RS is protecting its own resources, it might be unnecessary to use a permission ticket in this case. But just:
1) Client tries to access protected resource on behalf of an user (no RPT was sent) 2) RS obtain a RPT for the resource (or with additional resources and scopes) from AS 3) RS validates the response from AS, validates the RPT, enforce authorization and returns the RPT to the client (considering that RPT has the right permissions)"
Any thoughts ?
------------------------------------- Michael Schwartz Gluu Founder / CEO mike@gluu.org _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
I've actually filed an issue and am working on the ramifications of allowing the client to specify scopes in addition to the ticket. UMA paints a picture where the client doesn't know anything about the API that it's trying to access, but in the real world the client often has some idea through out of band discovery or configuration. If the client can tell the AS "these are the scopes I'm after" in addition to the ticket saying "these are the scopes recommended for that request" then the AS can make a more informed decision of which scopes to attach to the RPT. -- Justin On 12/10/2015 7:57 AM, Mark Dobrinic wrote:
Hi Mike,
Don't forget the as_uri that accompanies the ticket that the RS returns to the UMA Client, in the protocol-step that you're trying to optimize.
Maybe the better question is that if you assume you know which scopes to request, and the AS to make that request, why use UMA and not just plain OAuth?
Mark
On 10/12/15 03:23, Mike Schwartz wrote:
Pedro,
It doesn't make sense to me that the RS would obtain the RPT...
Personally, I like the design of the permission ticket, because the UMA Client does not need to know the scopes. Forcing the UMA Client to know the scopes creates a tight bundling with the security infrastructure, and may expose too much information to the UMA Client. I equate this to hard coding LDAP schema in your application. It puts the infrastructure team in a bad situation if the schema changes, because you need to re-QA the app.
However, some people think that just because Google does something, it must be right, or it must scale. So my interest in supporting this feature has more to do with aligning with an existing (bad) pattern.
- Mike
On 2015-12-09 19:37, Pedro Igor Silva wrote:
----- Original Message -----
From: "Mike Schwartz" <mike@gluu.org> To: wg-uma@kantarainitiative.org Sent: Wednesday, December 9, 2015 6:36:32 PM Subject: [WG-UMA] Two thoughts for UMA enhancments
UMA-tarians,
Can we discuss two ideas for enhancments:
1) UMA sans permission ticket
Let's say the UMA Client knows the scopes required to call a certain API. For example, Google documents this: http://gluu.co/google-scopes
In this case, perhaps the client can proactively request an RPT providing the scopes. And this RPT might be acceptable a certain RS for certain resource sets.
We might have already discussed this, but wouldn't this make UMA more compatable with existing API access management infrastructures?
2) UMA without the AAT
Inspired by Justin. I think the AAT adds value in many cases where the AS wants to make policies based on client claims (client id, domain specific catagory, etc). So I'm not saying eliminate the AAT. However, if the policy for access is based on network address only, or perhaps some other fraud detection technique that doesn't involve client identification, I could see a case where the AAT is not needed. So maybe the AAT could be optional?
- Mike What about the case below ? I think it was lost because I was not able to send messages to this list ...
"I think that when you are in NPE scenario, the permission ticket does not make much sense. This is pretty much related with my second round of questions.
Please correct me if I'm wrong. It seems that the permission ticket is mostly intended to perform a transactional authorization flow, where a RqP will ask permissions to access some one resources and the RO will be able to receive some kind of notification and actually approve this permission any time in the future. Or even to support multiple ASs within the same RS, where the user can choose which AS should be used to obtain permissions for his resources. Here I can see a lot of value, like for cloud and IoT authz ...
However, considering NPE use cases, specially when the RO is the RS, a 1:1 relationship between RS and AS and there is no need for a transactional authorization flow given that RS is protecting its own resources, it might be unnecessary to use a permission ticket in this case. But just:
1) Client tries to access protected resource on behalf of an user (no RPT was sent) 2) RS obtain a RPT for the resource (or with additional resources and scopes) from AS 3) RS validates the response from AS, validates the RPT, enforce authorization and returns the RPT to the client (considering that RPT has the right permissions)"
Any thoughts ?
------------------------------------- Michael Schwartz Gluu Founder / CEO mike@gluu.org _______________________________________________ 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
I agree with Justin. In a person-centered real world, like in IoT or healthcare, the UMA Client knows what it needs and what's available from the UMA RS based on out-of-band means OR standards. The person-centered AS, on the other hand may be generic and hardly care. Adrian On Thursday, December 10, 2015, Justin Richer <jricher@mit.edu> wrote:
I've actually filed an issue and am working on the ramifications of allowing the client to specify scopes in addition to the ticket. UMA paints a picture where the client doesn't know anything about the API that it's trying to access, but in the real world the client often has some idea through out of band discovery or configuration. If the client can tell the AS "these are the scopes I'm after" in addition to the ticket saying "these are the scopes recommended for that request" then the AS can make a more informed decision of which scopes to attach to the RPT.
-- Justin
On 12/10/2015 7:57 AM, Mark Dobrinic wrote:
Hi Mike,
Don't forget the as_uri that accompanies the ticket that the RS returns to the UMA Client, in the protocol-step that you're trying to optimize.
Maybe the better question is that if you assume you know which scopes to request, and the AS to make that request, why use UMA and not just plain OAuth?
Mark
On 10/12/15 03:23, Mike Schwartz wrote:
Pedro,
It doesn't make sense to me that the RS would obtain the RPT...
Personally, I like the design of the permission ticket, because the UMA Client does not need to know the scopes. Forcing the UMA Client to know the scopes creates a tight bundling with the security infrastructure, and may expose too much information to the UMA Client. I equate this to hard coding LDAP schema in your application. It puts the infrastructure team in a bad situation if the schema changes, because you need to re-QA the app.
However, some people think that just because Google does something, it must be right, or it must scale. So my interest in supporting this feature has more to do with aligning with an existing (bad) pattern.
- Mike
On 2015-12-09 19:37, Pedro Igor Silva wrote:
----- Original Message -----
From: "Mike Schwartz" <mike@gluu.org> To: wg-uma@kantarainitiative.org Sent: Wednesday, December 9, 2015 6:36:32 PM Subject: [WG-UMA] Two thoughts for UMA enhancments
UMA-tarians,
Can we discuss two ideas for enhancments:
1) UMA sans permission ticket
Let's say the UMA Client knows the scopes required to call a certain API. For example, Google documents this: http://gluu.co/google-scopes
In this case, perhaps the client can proactively request an RPT providing the scopes. And this RPT might be acceptable a certain RS for certain resource sets.
We might have already discussed this, but wouldn't this make UMA more compatable with existing API access management infrastructures?
2) UMA without the AAT
Inspired by Justin. I think the AAT adds value in many cases where the AS wants to make policies based on client claims (client id, domain specific catagory, etc). So I'm not saying eliminate the AAT. However, if the policy for access is based on network address only, or perhaps some other fraud detection technique that doesn't involve client identification, I could see a case where the AAT is not needed. So maybe the AAT could be optional?
- Mike
What about the case below ? I think it was lost because I was not able to send messages to this list ...
"I think that when you are in NPE scenario, the permission ticket does not make much sense. This is pretty much related with my second round of questions.
Please correct me if I'm wrong. It seems that the permission ticket is mostly intended to perform a transactional authorization flow, where a RqP will ask permissions to access some one resources and the RO will be able to receive some kind of notification and actually approve this permission any time in the future. Or even to support multiple ASs within the same RS, where the user can choose which AS should be used to obtain permissions for his resources. Here I can see a lot of value, like for cloud and IoT authz ...
However, considering NPE use cases, specially when the RO is the RS, a 1:1 relationship between RS and AS and there is no need for a transactional authorization flow given that RS is protecting its own resources, it might be unnecessary to use a permission ticket in this case. But just:
1) Client tries to access protected resource on behalf of an user (no RPT was sent) 2) RS obtain a RPT for the resource (or with additional resources and scopes) from AS 3) RS validates the response from AS, validates the RPT, enforce authorization and returns the RPT to the client (considering that RPT has the right permissions)"
Any thoughts ?
------------------------------------- Michael Schwartz Gluu Founder / CEO mike@gluu.org _______________________________________________ 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
-- Adrian Gropper MD PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/
Mark, I still think UMA adds a lot of value over OAuth2 alone! Also, my hope is that we can enable a migration plan to a better architecture. - Mike On 2015-12-10 06:57, Mark Dobrinic wrote:
Hi Mike,
Don't forget the as_uri that accompanies the ticket that the RS returns to the UMA Client, in the protocol-step that you're trying to optimize.
Maybe the better question is that if you assume you know which scopes to request, and the AS to make that request, why use UMA and not just plain OAuth?
Mark
On 10/12/15 03:23, Mike Schwartz wrote:
Pedro,
It doesn't make sense to me that the RS would obtain the RPT...
Personally, I like the design of the permission ticket, because the UMA Client does not need to know the scopes. Forcing the UMA Client to know the scopes creates a tight bundling with the security infrastructure, and may expose too much information to the UMA Client. I equate this to hard coding LDAP schema in your application. It puts the infrastructure team in a bad situation if the schema changes, because you need to re-QA the app.
However, some people think that just because Google does something, it must be right, or it must scale. So my interest in supporting this feature has more to do with aligning with an existing (bad) pattern.
- Mike
On 2015-12-09 19:37, Pedro Igor Silva wrote:
----- Original Message -----
From: "Mike Schwartz" <mike@gluu.org> To: wg-uma@kantarainitiative.org Sent: Wednesday, December 9, 2015 6:36:32 PM Subject: [WG-UMA] Two thoughts for UMA enhancments
UMA-tarians,
Can we discuss two ideas for enhancments:
1) UMA sans permission ticket
Let's say the UMA Client knows the scopes required to call a certain API. For example, Google documents this: http://gluu.co/google-scopes
In this case, perhaps the client can proactively request an RPT providing the scopes. And this RPT might be acceptable a certain RS for certain resource sets.
We might have already discussed this, but wouldn't this make UMA more compatable with existing API access management infrastructures?
2) UMA without the AAT
Inspired by Justin. I think the AAT adds value in many cases where the AS wants to make policies based on client claims (client id, domain specific catagory, etc). So I'm not saying eliminate the AAT. However, if the policy for access is based on network address only, or perhaps some other fraud detection technique that doesn't involve client identification, I could see a case where the AAT is not needed. So maybe the AAT could be optional?
- Mike
What about the case below ? I think it was lost because I was not able to send messages to this list ...
"I think that when you are in NPE scenario, the permission ticket does not make much sense. This is pretty much related with my second round of questions.
Please correct me if I'm wrong. It seems that the permission ticket is mostly intended to perform a transactional authorization flow, where a RqP will ask permissions to access some one resources and the RO will be able to receive some kind of notification and actually approve this permission any time in the future. Or even to support multiple ASs within the same RS, where the user can choose which AS should be used to obtain permissions for his resources. Here I can see a lot of value, like for cloud and IoT authz ...
However, considering NPE use cases, specially when the RO is the RS, a 1:1 relationship between RS and AS and there is no need for a transactional authorization flow given that RS is protecting its own resources, it might be unnecessary to use a permission ticket in this case. But just:
1) Client tries to access protected resource on behalf of an user (no RPT was sent) 2) RS obtain a RPT for the resource (or with additional resources and scopes) from AS 3) RS validates the response from AS, validates the RPT, enforce authorization and returns the RPT to the client (considering that RPT has the right permissions)"
Any thoughts ?
------------------------------------- Michael Schwartz Gluu Founder / CEO mike@gluu.org _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
-- ------------------------------------- Michael Schwartz Gluu Founder / CEO mike@gluu.org
UMA adds a lot of value over OAuth because it's easier to adopt to a very broad and deep ecosystem when the RS - RO interaction is separated in time from the RS - C interaction. In healthcare, this is called health information exchange and the separation allows for out-of-band RS - C discovery processes. In IoT this enables delegation where my RSs and Cs are layered like an onion around me (the layers in order: implants, wearables, mobile, router, family, cloud services). My AS is the only thing that ties these together and it needs to be as accepting of the different scopes as possible. Adrian On Thursday, December 10, 2015, Mike Schwartz <mike@gluu.org> wrote:
Mark,
I still think UMA adds a lot of value over OAuth2 alone! Also, my hope is that we can enable a migration plan to a better architecture.
- Mike
On 2015-12-10 06:57, Mark Dobrinic wrote:
Hi Mike,
Don't forget the as_uri that accompanies the ticket that the RS returns to the UMA Client, in the protocol-step that you're trying to optimize.
Maybe the better question is that if you assume you know which scopes to request, and the AS to make that request, why use UMA and not just plain OAuth?
Mark
On 10/12/15 03:23, Mike Schwartz wrote:
Pedro,
It doesn't make sense to me that the RS would obtain the RPT...
Personally, I like the design of the permission ticket, because the UMA Client does not need to know the scopes. Forcing the UMA Client to know the scopes creates a tight bundling with the security infrastructure, and may expose too much information to the UMA Client. I equate this to hard coding LDAP schema in your application. It puts the infrastructure team in a bad situation if the schema changes, because you need to re-QA the app.
However, some people think that just because Google does something, it must be right, or it must scale. So my interest in supporting this feature has more to do with aligning with an existing (bad) pattern.
- Mike
On 2015-12-09 19:37, Pedro Igor Silva wrote:
----- Original Message -----
From: "Mike Schwartz" <mike@gluu.org> To: wg-uma@kantarainitiative.org Sent: Wednesday, December 9, 2015 6:36:32 PM Subject: [WG-UMA] Two thoughts for UMA enhancments
UMA-tarians,
Can we discuss two ideas for enhancments:
1) UMA sans permission ticket
Let's say the UMA Client knows the scopes required to call a certain API. For example, Google documents this: http://gluu.co/google-scopes
In this case, perhaps the client can proactively request an RPT providing the scopes. And this RPT might be acceptable a certain RS for certain resource sets.
We might have already discussed this, but wouldn't this make UMA more compatable with existing API access management infrastructures?
2) UMA without the AAT
Inspired by Justin. I think the AAT adds value in many cases where the AS wants to make policies based on client claims (client id, domain specific catagory, etc). So I'm not saying eliminate the AAT. However, if the policy for access is based on network address only, or perhaps some other fraud detection technique that doesn't involve client identification, I could see a case where the AAT is not needed. So maybe the AAT could be optional?
- Mike
What about the case below ? I think it was lost because I was not able to send messages to this list ...
"I think that when you are in NPE scenario, the permission ticket does not make much sense. This is pretty much related with my second round of questions.
Please correct me if I'm wrong. It seems that the permission ticket is mostly intended to perform a transactional authorization flow, where a RqP will ask permissions to access some one resources and the RO will be able to receive some kind of notification and actually approve this permission any time in the future. Or even to support multiple ASs within the same RS, where the user can choose which AS should be used to obtain permissions for his resources. Here I can see a lot of value, like for cloud and IoT authz ...
However, considering NPE use cases, specially when the RO is the RS, a 1:1 relationship between RS and AS and there is no need for a transactional authorization flow given that RS is protecting its own resources, it might be unnecessary to use a permission ticket in this case. But just:
1) Client tries to access protected resource on behalf of an user (no RPT was sent) 2) RS obtain a RPT for the resource (or with additional resources and scopes) from AS 3) RS validates the response from AS, validates the RPT, enforce authorization and returns the RPT to the client (considering that RPT has the right permissions)"
Any thoughts ?
------------------------------------- Michael Schwartz Gluu Founder / CEO mike@gluu.org _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
--
Michael Schwartz Gluu Founder / CEO mike@gluu.org _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
-- Adrian Gropper MD PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/
Is the second issue Mike raises the one Justin said he filed an issue - *https://github.com/KantaraInitiative/wg-uma/issues/154 <https://github.com/KantaraInitiative/wg-uma/issues/154> *? On Thu, Dec 10, 2015 at 10:41 AM, Adrian Gropper <agropper@healthurl.com> wrote:
UMA adds a lot of value over OAuth because it's easier to adopt to a very broad and deep ecosystem when the RS - RO interaction is separated in time from the RS - C interaction. In healthcare, this is called health information exchange and the separation allows for out-of-band RS - C discovery processes. In IoT this enables delegation where my RSs and Cs are layered like an onion around me (the layers in order: implants, wearables, mobile, router, family, cloud services). My AS is the only thing that ties these together and it needs to be as accepting of the different scopes as possible.
Adrian
On Thursday, December 10, 2015, Mike Schwartz <mike@gluu.org> wrote:
Mark,
I still think UMA adds a lot of value over OAuth2 alone! Also, my hope is that we can enable a migration plan to a better architecture.
- Mike
On 2015-12-10 06:57, Mark Dobrinic wrote:
Hi Mike,
Don't forget the as_uri that accompanies the ticket that the RS returns to the UMA Client, in the protocol-step that you're trying to optimize.
Maybe the better question is that if you assume you know which scopes to request, and the AS to make that request, why use UMA and not just plain OAuth?
Mark
On 10/12/15 03:23, Mike Schwartz wrote:
Pedro,
It doesn't make sense to me that the RS would obtain the RPT...
Personally, I like the design of the permission ticket, because the UMA Client does not need to know the scopes. Forcing the UMA Client to know the scopes creates a tight bundling with the security infrastructure, and may expose too much information to the UMA Client. I equate this to hard coding LDAP schema in your application. It puts the infrastructure team in a bad situation if the schema changes, because you need to re-QA the app.
However, some people think that just because Google does something, it must be right, or it must scale. So my interest in supporting this feature has more to do with aligning with an existing (bad) pattern.
- Mike
On 2015-12-09 19:37, Pedro Igor Silva wrote:
----- Original Message -----
From: "Mike Schwartz" <mike@gluu.org> To: wg-uma@kantarainitiative.org Sent: Wednesday, December 9, 2015 6:36:32 PM Subject: [WG-UMA] Two thoughts for UMA enhancments
UMA-tarians,
Can we discuss two ideas for enhancments:
1) UMA sans permission ticket
Let's say the UMA Client knows the scopes required to call a certain API. For example, Google documents this: http://gluu.co/google-scopes
In this case, perhaps the client can proactively request an RPT providing the scopes. And this RPT might be acceptable a certain RS for certain resource sets.
We might have already discussed this, but wouldn't this make UMA more compatable with existing API access management infrastructures?
2) UMA without the AAT
Inspired by Justin. I think the AAT adds value in many cases where the AS wants to make policies based on client claims (client id, domain specific catagory, etc). So I'm not saying eliminate the AAT. However, if the policy for access is based on network address only, or perhaps some other fraud detection technique that doesn't involve client identification, I could see a case where the AAT is not needed. So maybe the AAT could be optional?
- Mike
What about the case below ? I think it was lost because I was not able to send messages to this list ...
"I think that when you are in NPE scenario, the permission ticket does not make much sense. This is pretty much related with my second round of questions.
Please correct me if I'm wrong. It seems that the permission ticket is mostly intended to perform a transactional authorization flow, where a RqP will ask permissions to access some one resources and the RO will be able to receive some kind of notification and actually approve this permission any time in the future. Or even to support multiple ASs within the same RS, where the user can choose which AS should be used to obtain permissions for his resources. Here I can see a lot of value, like for cloud and IoT authz ...
However, considering NPE use cases, specially when the RO is the RS, a 1:1 relationship between RS and AS and there is no need for a transactional authorization flow given that RS is protecting its own resources, it might be unnecessary to use a permission ticket in this case. But just:
1) Client tries to access protected resource on behalf of an user (no RPT was sent) 2) RS obtain a RPT for the resource (or with additional resources and scopes) from AS 3) RS validates the response from AS, validates the RPT, enforce authorization and returns the RPT to the client (considering that RPT has the right permissions)"
Any thoughts ?
------------------------------------- Michael Schwartz Gluu Founder / CEO mike@gluu.org _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
--
Michael Schwartz Gluu Founder / CEO mike@gluu.org _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
--
Adrian Gropper MD
PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
Yes, and the first point is touched on here: https://github.com/KantaraInitiative/wg-uma/issues/165 <https://github.com/KantaraInitiative/wg-uma/issues/165> — Justin
On Dec 12, 2015, at 8:35 PM, Debbie Bucci <debbucci@gmail.com> wrote:
Is the second issue Mike raises the one Justin said he filed an issue - https://github.com/KantaraInitiative/wg-uma/issues/154 <https://github.com/KantaraInitiative/wg-uma/issues/154> ?
On Thu, Dec 10, 2015 at 10:41 AM, Adrian Gropper <agropper@healthurl.com <mailto:agropper@healthurl.com>> wrote: UMA adds a lot of value over OAuth because it's easier to adopt to a very broad and deep ecosystem when the RS - RO interaction is separated in time from the RS - C interaction. In healthcare, this is called health information exchange and the separation allows for out-of-band RS - C discovery processes. In IoT this enables delegation where my RSs and Cs are layered like an onion around me (the layers in order: implants, wearables, mobile, router, family, cloud services). My AS is the only thing that ties these together and it needs to be as accepting of the different scopes as possible.
Adrian
On Thursday, December 10, 2015, Mike Schwartz <mike@gluu.org <mailto:mike@gluu.org>> wrote: Mark,
I still think UMA adds a lot of value over OAuth2 alone! Also, my hope is that we can enable a migration plan to a better architecture.
- Mike
On 2015-12-10 06:57, Mark Dobrinic wrote: Hi Mike,
Don't forget the as_uri that accompanies the ticket that the RS returns to the UMA Client, in the protocol-step that you're trying to optimize.
Maybe the better question is that if you assume you know which scopes to request, and the AS to make that request, why use UMA and not just plain OAuth?
Mark
On 10/12/15 03:23, Mike Schwartz wrote: Pedro,
It doesn't make sense to me that the RS would obtain the RPT...
Personally, I like the design of the permission ticket, because the UMA Client does not need to know the scopes. Forcing the UMA Client to know the scopes creates a tight bundling with the security infrastructure, and may expose too much information to the UMA Client. I equate this to hard coding LDAP schema in your application. It puts the infrastructure team in a bad situation if the schema changes, because you need to re-QA the app.
However, some people think that just because Google does something, it must be right, or it must scale. So my interest in supporting this feature has more to do with aligning with an existing (bad) pattern.
- Mike
On 2015-12-09 19:37, Pedro Igor Silva wrote: ----- Original Message ----- From: "Mike Schwartz" <mike@gluu.org <>> To: wg-uma@kantarainitiative.org <> Sent: Wednesday, December 9, 2015 6:36:32 PM Subject: [WG-UMA] Two thoughts for UMA enhancments
UMA-tarians,
Can we discuss two ideas for enhancments:
1) UMA sans permission ticket
Let's say the UMA Client knows the scopes required to call a certain API. For example, Google documents this: http://gluu.co/google-scopes <http://gluu.co/google-scopes>
In this case, perhaps the client can proactively request an RPT providing the scopes. And this RPT might be acceptable a certain RS for certain resource sets.
We might have already discussed this, but wouldn't this make UMA more compatable with existing API access management infrastructures?
2) UMA without the AAT
Inspired by Justin. I think the AAT adds value in many cases where the AS wants to make policies based on client claims (client id, domain specific catagory, etc). So I'm not saying eliminate the AAT. However, if the policy for access is based on network address only, or perhaps some other fraud detection technique that doesn't involve client identification, I could see a case where the AAT is not needed. So maybe the AAT could be optional?
- Mike
What about the case below ? I think it was lost because I was not able to send messages to this list ...
"I think that when you are in NPE scenario, the permission ticket does not make much sense. This is pretty much related with my second round of questions.
Please correct me if I'm wrong. It seems that the permission ticket is mostly intended to perform a transactional authorization flow, where a RqP will ask permissions to access some one resources and the RO will be able to receive some kind of notification and actually approve this permission any time in the future. Or even to support multiple ASs within the same RS, where the user can choose which AS should be used to obtain permissions for his resources. Here I can see a lot of value, like for cloud and IoT authz ...
However, considering NPE use cases, specially when the RO is the RS, a 1:1 relationship between RS and AS and there is no need for a transactional authorization flow given that RS is protecting its own resources, it might be unnecessary to use a permission ticket in this case. But just:
1) Client tries to access protected resource on behalf of an user (no RPT was sent) 2) RS obtain a RPT for the resource (or with additional resources and scopes) from AS 3) RS validates the response from AS, validates the RPT, enforce authorization and returns the RPT to the client (considering that RPT has the right permissions)"
Any thoughts ?
------------------------------------- Michael Schwartz Gluu Founder / CEO mike@gluu.org <> _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org <> http://kantarainitiative.org/mailman/listinfo/wg-uma <http://kantarainitiative.org/mailman/listinfo/wg-uma>
-- ------------------------------------- Michael Schwartz Gluu Founder / CEO mike@gluu.org <> _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org <> http://kantarainitiative.org/mailman/listinfo/wg-uma <http://kantarainitiative.org/mailman/listinfo/wg-uma>
--
Adrian Gropper MD
PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/ <http://patientprivacyrights.org/donate-2/>
_______________________________________________ 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 http://kantarainitiative.org/mailman/listinfo/wg-uma
Let's explore the specific use cases that highlight limitations or impedance mismatches of current flows. If I understand correctly, Pedro's and Mike's use cases are very similar. We've generally been calling this an *API security* use case. (BTW, just saying they're "NPE" use cases is ambiguous because there are other flows where a human resource owner shares with an NPE requesting party at some point, but the API security use case does have a non-person entity (organization) as an RO.) API security is like traditional web services security use cases, and it's a situation where a security architect would often reach for vanilla OAuth. Questions for you guys: What's the "coupling quotient" of the real-life use cases being considered? How often are the AS and RS in the same security domain? How often does the client need to get credentials dynamically vs. pre-provisioned? (Note that OAuth ecosystems today are tightly coupled by nature: The AS/RS is in one domain, and clients are statically provisioned with credentials, often to be sure that they can execute terms of service.) How often is the client running autonomously, vs. operated by a human? The API security use case overall would normally already be signed up to a smart client that knows the API, knows the API's scopes, knows the AS location, and wants to get down to making API calls. In a person-to-person delegation use case, Alice is likely to give Bob first-order consideration -- *he'll get what scopes he'll get, and he'll like it!* -- in configuring policy constraints.* But in autonomous-client API security use cases, I suspect AliceCorp needs the client to be more, well, autonomous in wanting to request every scope it can handle, and perhaps in some human-operated client variants (AliceCorp-to-Bob) of the API security use case as well (asking up-front for everything it can handle). So, based on this analysis, some thoughts and key questions. *Thoughts:* As I had noted to Pedro in private email back in October, there is an “extensibility profile <https://docs.kantarainitiative.org/uma/draft-uma-core-v1_0_1.html#alt-prot-profile>” in the UMA Core spec to allow lots of optimizations when the RS and AS are tightly coupled. This would enable more efficient RS-AS communication regarding resource set registration, permission registration, and token introspection — it could all be “implicit” because the same hunk of software is on both sides. However, some tokens would still have to be produced for client consumption because it may still be a third-party hunk of software. *Key questions:* What are the actual use cases on the ground so far? Are they such that the extensibility profile in the spec provides a starting point from which we could work outward? Or do they support a serious requirement for a "client-to-AS-first" flow in the context of a *loosely coupled* RS and AS, vs. the currently native "client-to-RS-first" flow in UMA V1.0.x that drove the design of the existing permission ticket and a sufficiently "dumb" client (no knowledge of AS location and no knowledge of scopes)? Eve *UMA still allows for Alice's policy to constrain clients, of course (because policy doesn't appear on the wire in UMA), and any client involved in an Alice-to-Bob use case that can't handle scope *x* will never attempt an API call using scope *x* anyway... *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Sat, Dec 12, 2015 at 5:45 PM, Justin Richer <jricher@mit.edu> wrote:
Yes, and the first point is touched on here:
https://github.com/KantaraInitiative/wg-uma/issues/165
— Justin
On Dec 12, 2015, at 8:35 PM, Debbie Bucci <debbucci@gmail.com> wrote:
Is the second issue Mike raises the one Justin said he filed an issue - *https://github.com/KantaraInitiative/wg-uma/issues/154 <https://github.com/KantaraInitiative/wg-uma/issues/154> *?
On Thu, Dec 10, 2015 at 10:41 AM, Adrian Gropper <agropper@healthurl.com> wrote:
UMA adds a lot of value over OAuth because it's easier to adopt to a very broad and deep ecosystem when the RS - RO interaction is separated in time from the RS - C interaction. In healthcare, this is called health information exchange and the separation allows for out-of-band RS - C discovery processes. In IoT this enables delegation where my RSs and Cs are layered like an onion around me (the layers in order: implants, wearables, mobile, router, family, cloud services). My AS is the only thing that ties these together and it needs to be as accepting of the different scopes as possible.
Adrian
On Thursday, December 10, 2015, Mike Schwartz <mike@gluu.org> wrote:
Mark,
I still think UMA adds a lot of value over OAuth2 alone! Also, my hope is that we can enable a migration plan to a better architecture.
- Mike
On 2015-12-10 06:57, Mark Dobrinic wrote:
Hi Mike,
Don't forget the as_uri that accompanies the ticket that the RS returns to the UMA Client, in the protocol-step that you're trying to optimize.
Maybe the better question is that if you assume you know which scopes to request, and the AS to make that request, why use UMA and not just plain OAuth?
Mark
On 10/12/15 03:23, Mike Schwartz wrote:
Pedro,
It doesn't make sense to me that the RS would obtain the RPT...
Personally, I like the design of the permission ticket, because the UMA Client does not need to know the scopes. Forcing the UMA Client to know the scopes creates a tight bundling with the security infrastructure, and may expose too much information to the UMA Client. I equate this to hard coding LDAP schema in your application. It puts the infrastructure team in a bad situation if the schema changes, because you need to re-QA the app.
However, some people think that just because Google does something, it must be right, or it must scale. So my interest in supporting this feature has more to do with aligning with an existing (bad) pattern.
- Mike
On 2015-12-09 19:37, Pedro Igor Silva wrote:
----- Original Message -----
> From: "Mike Schwartz" <mike@gluu.org> > To: wg-uma@kantarainitiative.org > Sent: Wednesday, December 9, 2015 6:36:32 PM > Subject: [WG-UMA] Two thoughts for UMA enhancments > > > UMA-tarians, > > Can we discuss two ideas for enhancments: > > 1) UMA sans permission ticket > > Let's say the UMA Client knows the scopes required to call a certain > API. For example, Google documents this: > http://gluu.co/google-scopes > > In this case, perhaps the client can proactively request an RPT > providing the scopes. And this RPT might be acceptable a certain RS > for > certain resource sets. > > We might have already discussed this, but wouldn't this make UMA more > compatable with existing API access management infrastructures? > > 2) UMA without the AAT > > Inspired by Justin. I think the AAT adds value in many cases where > the > AS wants to make policies based on client claims (client id, domain > specific catagory, etc). So I'm not saying eliminate the AAT. > However, > if the policy for access is based on network address only, or perhaps > some other fraud detection technique that doesn't involve client > identification, I could see a case where the AAT is not needed. So > maybe > the AAT could be optional? > > - Mike >
What about the case below ? I think it was lost because I was not able to send messages to this list ...
"I think that when you are in NPE scenario, the permission ticket does not make much sense. This is pretty much related with my second round of questions.
Please correct me if I'm wrong. It seems that the permission ticket is mostly intended to perform a transactional authorization flow, where a RqP will ask permissions to access some one resources and the RO will be able to receive some kind of notification and actually approve this permission any time in the future. Or even to support multiple ASs within the same RS, where the user can choose which AS should be used to obtain permissions for his resources. Here I can see a lot of value, like for cloud and IoT authz ...
However, considering NPE use cases, specially when the RO is the RS, a 1:1 relationship between RS and AS and there is no need for a transactional authorization flow given that RS is protecting its own resources, it might be unnecessary to use a permission ticket in this case. But just:
1) Client tries to access protected resource on behalf of an user (no RPT was sent) 2) RS obtain a RPT for the resource (or with additional resources and scopes) from AS 3) RS validates the response from AS, validates the RPT, enforce authorization and returns the RPT to the client (considering that RPT has the right permissions)"
Any thoughts ?
>
Eve, Thanks for thinking this through, great work as usual...
Questions for you guys: What's the "coupling quotient" of the real-life use cases being considered? How often are the AS and RS in the same security domain?
For Gluu use cases, the AS and RS are usually in the same security domain.
How often does the client need to get credentials dynamically vs. pre-provisioned?
We push clients to use OIDC dynamic client registration. But sometimes they are using a form which calls the dynamic clent registration API.
How often is the client running autonomously, vs. operated by a human?
50/50. For example, in one of our current projects the mobile app talks to an initial set of API's, which themselves calls shared API's.
What are the actual use cases on the ground so far?
As I mentioned above, the main use case we are trying to solve is mobile app calling API's which call API's.
Are they such that the extensibility profile in the spec provides a starting point from which we could work outward?
Not sure.
Or do they support a serious requirement for a "client-to-AS-first" flow in the context of a _loosely coupled_ RS and AS, vs. the currently native "client-to-RS-first" flow in UMA V1.0.x that drove the design of the existing permission ticket and a sufficiently "dumb" client (no knowledge of AS location and no knowledge of scopes)?
As mentioned before, I like the permission ticket design, and I think its better than the "client-to-AS-first" pattern for a number of reasons. However... I think that in the interest of aligning with existing practices, it would be advantageous for us to undertake this work. - Mike
Thanks, Mike! Rolling up the information coming from your direction, it sounds like the server side tends to be one-domain, and the clients tend to be more loosely coupled, possibly third-party. And the client-to-RS-first flow is relatively comfortable in your specific case (even if, in fact, you could leverage the AS-RS extensibility profile to avoid permission tickets and other server-side-internal artifacts in most or all cases). Nonetheless, you see value in offering an "OAuth-style" flow for OAuth-style use cases. Pedro, are you willing to treat my note as a questionnaire too? :-) *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Mon, Dec 14, 2015 at 10:19 AM, Mike Schwartz <mike@gluu.org> wrote:
Eve,
Thanks for thinking this through, great work as usual...
Questions for you guys: What's the "coupling quotient" of the real-life
use cases being considered? How often are the AS and RS in the same security domain?
For Gluu use cases, the AS and RS are usually in the same security domain.
How often does the client need to get credentials
dynamically vs. pre-provisioned?
We push clients to use OIDC dynamic client registration. But sometimes they are using a form which calls the dynamic clent registration API.
How often is the client running autonomously, vs. operated by a human?
50/50. For example, in one of our current projects the mobile app talks to an initial set of API's, which themselves calls shared API's.
What are the actual use cases on the ground so far?
As I mentioned above, the main use case we are trying to solve is mobile app calling API's which call API's.
Are they such that the extensibility profile in the spec provides a
starting point from which we could work outward?
Not sure.
Or do they support a serious
requirement for a "client-to-AS-first" flow in the context of a _loosely coupled_ RS and AS, vs. the currently native "client-to-RS-first" flow in UMA V1.0.x that drove the design of the existing permission ticket and a sufficiently "dumb" client (no knowledge of AS location and no knowledge of scopes)?
As mentioned before, I like the permission ticket design, and I think its better than the "client-to-AS-first" pattern for a number of reasons. However... I think that in the interest of aligning with existing practices, it would be advantageous for us to undertake this work.
- Mike
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
Hi Even, Thanks for looking this and sorry for the late reply :). Answers inline. ----- Original Message -----
From: "Eve Maler" <eve@xmlgrrl.com> To: "Justin Richer" <jricher@mit.edu> Cc: "Michael Schwartz" <mike@gluu.org>, "wg-uma@kantarainitiative.org UMA" <wg-uma@kantarainitiative.org> Sent: Monday, December 14, 2015 4:04:13 PM Subject: Re: [WG-UMA] Two thoughts for UMA enhancments
Let's explore the specific use cases that highlight limitations or impedance mismatches of current flows.
If I understand correctly, Pedro's and Mike's use cases are very similar. We've generally been calling this an API security use case. (BTW, just saying they're "NPE" use cases is ambiguous because there are other flows where a human resource owner shares with an NPE requesting party at some point, but the API security use case does have a non-person entity (organization) as an RO.)
Ok, for now on I'll refer to these use cases as API security as well. And yes, I think Mike and I are trying to address similar problems.
API security is like traditional web services security use cases, and it's a situation where a security architect would often reach for vanilla OAuth.
Agree. But we need to also consider that what you did with UMA allow us to leverage OAuth2 authorization capabilities to a new level, being more suitable in cases where you want fine-grained authorization and give to ROs more control over their resources. It should be possible to use vanilla OAuth2 and still support fine-grained authz and a plenty of UMA-like features (like the permission ticket to handle Person-To-Person authz, obligations, claims gathering, etc), but you will end up reinventing the wheel and be stuck in a proprietary solution.
Questions for you guys: What's the "coupling quotient" of the real-life use cases being considered? How often are the AS and RS in the same security domain?
I would say that AS and RS in same security domain are pretty common. Specially if you consider some enterprise use cases where you have a single AS serving different applications, where each RS may also have its own and single client. For instance, a vanilla (HTML5 + AngularJS) + RESTFul design. Here we don't have third-party clients consuming RS's API. In these cases, the client does not need to know the scopes, but just the API. Is up to the RS to discover the scopes and enforce policies based on the relaying party or/and the client accessing the API. For instance: 1) Client (on behalf of an user) tries to access a resource 2) RS knows both ID and scope(s) related with the request and asks the AS for a RPT with the required permissions. 3) AS evaluates the policies based on the authorization request from the RS and issues a RPT. 4) RS enforces the authorization decision from AS and gives back the RPT to the client. See, the client is pretty much dumb. It does not know about resource ids or scopes. Just like what the permission ticket does. We are just making client's more simple to implement and avoid additional requests (one to send the ticket to AS and another that sends the RPT back to the RS). It is worthy to mention that UMA already supports the flow above. I can just handle the permission ticket flow within the RS and return back the RPT to the client (or any other result from the AS). But, am I violating any rule by doing this ? The same thing applies if I want to obtain a RPT with everything an user/client is entitled to do (entitlements) once. I can just configure the RS to build a permission ticket asking for every single resource/scopes during a first interaction.
How often does the client need to get credentials dynamically vs. pre-provisioned? (Note that OAuth ecosystems today are tightly coupled by nature: The AS/RS is in one domain, and clients are statically provisioned with credentials, often to be sure that they can execute terms of service.) How often is the client running autonomously, vs. operated by a human?
Right now, I'm more focused with pre-provisioned clients. Although they can also register themselves using OpenID Connect Dynamic Client Registration. I'm also focused on clients operated by a human. Although I think we can handle autonomous clients using offline tokens to evaluate authorization policies on the AS and enforce them on the RS.
The API security use case overall would normally already be signed up to a smart client that knows the API, knows the API's scopes, knows the AS location, and wants to get down to making API calls. In a person-to-person delegation use case, Alice is likely to give Bob first-order consideration -- he'll get what scopes he'll get, and he'll like it! -- in configuring policy constraints.* But in autonomous-client API security use cases, I suspect AliceCorp needs the client to be more, well, autonomous in wanting to request every scope it can handle, and perhaps in some human-operated client variants (AliceCorp-to-Bob) of the API security use case as well (asking up-front for everything it can handle).
So, based on this analysis, some thoughts and key questions.
Thoughts: As I had noted to Pedro in private email back in October, there is an “ extensibility profile ” in the UMA Core spec to allow lots of optimizations when the RS and AS are tightly coupled. This would enable more efficient RS-AS communication regarding resource set registration, permission registration, and token introspection — it could all be “implicit” because the same hunk of software is on both sides. However, some tokens would still have to be produced for client consumption because it may still be a third-party hunk of software.
+1. I just want to make sure I'm not violating the rules.
Key questions: What are the actual use cases on the ground so far? Are they such that the extensibility profile in the spec provides a starting point from which we could work outward? Or do they support a serious requirement for a "client-to-AS-first" flow in the context of a loosely coupled RS and AS, vs. the currently native "client-to-RS-first" flow in UMA V1.0.x that drove the design of the existing permission ticket and a sufficiently "dumb" client (no knowledge of AS location and no knowledge of scopes)?
My use cases are all based on the currently native "client-to-RS-first". I think "client-to-AS-first" will kill the benefits brought by UMA, specially from a client perspective. Btw, I like the permission ticket (and the whole idea behind it) and, like I mentioned before, it has a lot of value. Specially for person-to-person delegation use cases. I think my question for all that should be: Am I violating UMA's rules if I change the flow under certain circumstances ? Or am I forced to always use a permission ticket as defined by the specs ? Thanks again for your time !
Eve
*UMA still allows for Alice's policy to constrain clients, of course (because policy doesn't appear on the wire in UMA), and any client involved in an Alice-to-Bob use case that can't handle scope x will never attempt an API call using scope x anyway...
Eve Maler Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
On Sat, Dec 12, 2015 at 5:45 PM, Justin Richer < jricher@mit.edu > wrote:
Yes, and the first point is touched on here:
https://github.com/KantaraInitiative/wg-uma/issues/165
— Justin
On Dec 12, 2015, at 8:35 PM, Debbie Bucci < debbucci@gmail.com > wrote:
Is the second issue Mike raises the one Justin said he filed an issue - https://github.com/KantaraInitiative/wg-uma/issues/154 ?
On Thu, Dec 10, 2015 at 10:41 AM, Adrian Gropper < agropper@healthurl.com > wrote:
UMA adds a lot of value over OAuth because it's easier to adopt to a very broad and deep ecosystem when the RS - RO interaction is separated in time from the RS - C interaction. In healthcare, this is called health information exchange and the separation allows for out-of-band RS - C discovery processes. In IoT this enables delegation where my RSs and Cs are layered like an onion around me (the layers in order: implants, wearables, mobile, router, family, cloud services). My AS is the only thing that ties these together and it needs to be as accepting of the different scopes as possible.
Adrian
On Thursday, December 10, 2015, Mike Schwartz < mike@gluu.org > wrote:
Mark,
I still think UMA adds a lot of value over OAuth2 alone! Also, my hope is that we can enable a migration plan to a better architecture.
- Mike
On 2015-12-10 06:57, Mark Dobrinic wrote:
Hi Mike,
Don't forget the as_uri that accompanies the ticket that the RS returns to the UMA Client, in the protocol-step that you're trying to optimize.
Maybe the better question is that if you assume you know which scopes to request, and the AS to make that request, why use UMA and not just plain OAuth?
Mark
On 10/12/15 03:23, Mike Schwartz wrote:
Pedro,
It doesn't make sense to me that the RS would obtain the RPT...
Personally, I like the design of the permission ticket, because the UMA Client does not need to know the scopes. Forcing the UMA Client to know the scopes creates a tight bundling with the security infrastructure, and may expose too much information to the UMA Client. I equate this to hard coding LDAP schema in your application. It puts the infrastructure team in a bad situation if the schema changes, because you need to re-QA the app.
However, some people think that just because Google does something, it must be right, or it must scale. So my interest in supporting this feature has more to do with aligning with an existing (bad) pattern.
- Mike
On 2015-12-09 19:37, Pedro Igor Silva wrote:
----- Original Message -----
From: "Mike Schwartz" < mike@gluu.org > To: wg-uma@kantarainitiative.org Sent: Wednesday, December 9, 2015 6:36:32 PM Subject: [WG-UMA] Two thoughts for UMA enhancments
UMA-tarians,
Can we discuss two ideas for enhancments:
1) UMA sans permission ticket
Let's say the UMA Client knows the scopes required to call a certain API. For example, Google documents this: http://gluu.co/google-scopes
In this case, perhaps the client can proactively request an RPT providing the scopes. And this RPT might be acceptable a certain RS for certain resource sets.
We might have already discussed this, but wouldn't this make UMA more compatable with existing API access management infrastructures?
2) UMA without the AAT
Inspired by Justin. I think the AAT adds value in many cases where the AS wants to make policies based on client claims (client id, domain specific catagory, etc). So I'm not saying eliminate the AAT. However, if the policy for access is based on network address only, or perhaps some other fraud detection technique that doesn't involve client identification, I could see a case where the AAT is not needed. So maybe the AAT could be optional?
- Mike
What about the case below ? I think it was lost because I was not able to send messages to this list ...
"I think that when you are in NPE scenario, the permission ticket does not make much sense. This is pretty much related with my second round of questions.
Please correct me if I'm wrong. It seems that the permission ticket is mostly intended to perform a transactional authorization flow, where a RqP will ask permissions to access some one resources and the RO will be able to receive some kind of notification and actually approve this permission any time in the future. Or even to support multiple ASs within the same RS, where the user can choose which AS should be used to obtain permissions for his resources. Here I can see a lot of value, like for cloud and IoT authz ...
However, considering NPE use cases, specially when the RO is the RS, a 1:1 relationship between RS and AS and there is no need for a transactional authorization flow given that RS is protecting its own resources, it might be unnecessary to use a permission ticket in this case. But just:
1) Client tries to access protected resource on behalf of an user (no RPT was sent) 2) RS obtain a RPT for the resource (or with additional resources and scopes) from AS 3) RS validates the response from AS, validates the RPT, enforce authorization and returns the RPT to the client (considering that RPT has the right permissions)"
Any thoughts ?
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
Ohh, not "Even". Sorry Eve ! ----- Original Message ----- From: "Pedro Igor Silva" <psilva@redhat.com> To: "Eve Maler" <eve@xmlgrrl.com> Cc: "Michael Schwartz" <mike@gluu.org>, "wg-uma@kantarainitiative.org UMA" <wg-uma@kantarainitiative.org> Sent: Thursday, December 17, 2015 4:50:53 AM Subject: Re: [WG-UMA] Two thoughts for UMA enhancments Hi Even, Thanks for looking this and sorry for the late reply :). Answers inline. ----- Original Message -----
From: "Eve Maler" <eve@xmlgrrl.com> To: "Justin Richer" <jricher@mit.edu> Cc: "Michael Schwartz" <mike@gluu.org>, "wg-uma@kantarainitiative.org UMA" <wg-uma@kantarainitiative.org> Sent: Monday, December 14, 2015 4:04:13 PM Subject: Re: [WG-UMA] Two thoughts for UMA enhancments
Let's explore the specific use cases that highlight limitations or impedance mismatches of current flows.
If I understand correctly, Pedro's and Mike's use cases are very similar. We've generally been calling this an API security use case. (BTW, just saying they're "NPE" use cases is ambiguous because there are other flows where a human resource owner shares with an NPE requesting party at some point, but the API security use case does have a non-person entity (organization) as an RO.)
Ok, for now on I'll refer to these use cases as API security as well. And yes, I think Mike and I are trying to address similar problems.
API security is like traditional web services security use cases, and it's a situation where a security architect would often reach for vanilla OAuth.
Agree. But we need to also consider that what you did with UMA allow us to leverage OAuth2 authorization capabilities to a new level, being more suitable in cases where you want fine-grained authorization and give to ROs more control over their resources. It should be possible to use vanilla OAuth2 and still support fine-grained authz and a plenty of UMA-like features (like the permission ticket to handle Person-To-Person authz, obligations, claims gathering, etc), but you will end up reinventing the wheel and be stuck in a proprietary solution.
Questions for you guys: What's the "coupling quotient" of the real-life use cases being considered? How often are the AS and RS in the same security domain?
I would say that AS and RS in same security domain are pretty common. Specially if you consider some enterprise use cases where you have a single AS serving different applications, where each RS may also have its own and single client. For instance, a vanilla (HTML5 + AngularJS) + RESTFul design. Here we don't have third-party clients consuming RS's API. In these cases, the client does not need to know the scopes, but just the API. Is up to the RS to discover the scopes and enforce policies based on the relaying party or/and the client accessing the API. For instance: 1) Client (on behalf of an user) tries to access a resource 2) RS knows both ID and scope(s) related with the request and asks the AS for a RPT with the required permissions. 3) AS evaluates the policies based on the authorization request from the RS and issues a RPT. 4) RS enforces the authorization decision from AS and gives back the RPT to the client. See, the client is pretty much dumb. It does not know about resource ids or scopes. Just like what the permission ticket does. We are just making client's more simple to implement and avoid additional requests (one to send the ticket to AS and another that sends the RPT back to the RS). It is worthy to mention that UMA already supports the flow above. I can just handle the permission ticket flow within the RS and return back the RPT to the client (or any other result from the AS). But, am I violating any rule by doing this ? The same thing applies if I want to obtain a RPT with everything an user/client is entitled to do (entitlements) once. I can just configure the RS to build a permission ticket asking for every single resource/scopes during a first interaction.
How often does the client need to get credentials dynamically vs. pre-provisioned? (Note that OAuth ecosystems today are tightly coupled by nature: The AS/RS is in one domain, and clients are statically provisioned with credentials, often to be sure that they can execute terms of service.) How often is the client running autonomously, vs. operated by a human?
Right now, I'm more focused with pre-provisioned clients. Although they can also register themselves using OpenID Connect Dynamic Client Registration. I'm also focused on clients operated by a human. Although I think we can handle autonomous clients using offline tokens to evaluate authorization policies on the AS and enforce them on the RS.
The API security use case overall would normally already be signed up to a smart client that knows the API, knows the API's scopes, knows the AS location, and wants to get down to making API calls. In a person-to-person delegation use case, Alice is likely to give Bob first-order consideration -- he'll get what scopes he'll get, and he'll like it! -- in configuring policy constraints.* But in autonomous-client API security use cases, I suspect AliceCorp needs the client to be more, well, autonomous in wanting to request every scope it can handle, and perhaps in some human-operated client variants (AliceCorp-to-Bob) of the API security use case as well (asking up-front for everything it can handle).
So, based on this analysis, some thoughts and key questions.
Thoughts: As I had noted to Pedro in private email back in October, there is an “ extensibility profile ” in the UMA Core spec to allow lots of optimizations when the RS and AS are tightly coupled. This would enable more efficient RS-AS communication regarding resource set registration, permission registration, and token introspection — it could all be “implicit” because the same hunk of software is on both sides. However, some tokens would still have to be produced for client consumption because it may still be a third-party hunk of software.
+1. I just want to make sure I'm not violating the rules.
Key questions: What are the actual use cases on the ground so far? Are they such that the extensibility profile in the spec provides a starting point from which we could work outward? Or do they support a serious requirement for a "client-to-AS-first" flow in the context of a loosely coupled RS and AS, vs. the currently native "client-to-RS-first" flow in UMA V1.0.x that drove the design of the existing permission ticket and a sufficiently "dumb" client (no knowledge of AS location and no knowledge of scopes)?
My use cases are all based on the currently native "client-to-RS-first". I think "client-to-AS-first" will kill the benefits brought by UMA, specially from a client perspective. Btw, I like the permission ticket (and the whole idea behind it) and, like I mentioned before, it has a lot of value. Specially for person-to-person delegation use cases. I think my question for all that should be: Am I violating UMA's rules if I change the flow under certain circumstances ? Or am I forced to always use a permission ticket as defined by the specs ? Thanks again for your time !
Eve
*UMA still allows for Alice's policy to constrain clients, of course (because policy doesn't appear on the wire in UMA), and any client involved in an Alice-to-Bob use case that can't handle scope x will never attempt an API call using scope x anyway...
Eve Maler Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
On Sat, Dec 12, 2015 at 5:45 PM, Justin Richer < jricher@mit.edu > wrote:
Yes, and the first point is touched on here:
https://github.com/KantaraInitiative/wg-uma/issues/165
— Justin
On Dec 12, 2015, at 8:35 PM, Debbie Bucci < debbucci@gmail.com > wrote:
Is the second issue Mike raises the one Justin said he filed an issue - https://github.com/KantaraInitiative/wg-uma/issues/154 ?
On Thu, Dec 10, 2015 at 10:41 AM, Adrian Gropper < agropper@healthurl.com > wrote:
UMA adds a lot of value over OAuth because it's easier to adopt to a very broad and deep ecosystem when the RS - RO interaction is separated in time from the RS - C interaction. In healthcare, this is called health information exchange and the separation allows for out-of-band RS - C discovery processes. In IoT this enables delegation where my RSs and Cs are layered like an onion around me (the layers in order: implants, wearables, mobile, router, family, cloud services). My AS is the only thing that ties these together and it needs to be as accepting of the different scopes as possible.
Adrian
On Thursday, December 10, 2015, Mike Schwartz < mike@gluu.org > wrote:
Mark,
I still think UMA adds a lot of value over OAuth2 alone! Also, my hope is that we can enable a migration plan to a better architecture.
- Mike
On 2015-12-10 06:57, Mark Dobrinic wrote:
Hi Mike,
Don't forget the as_uri that accompanies the ticket that the RS returns to the UMA Client, in the protocol-step that you're trying to optimize.
Maybe the better question is that if you assume you know which scopes to request, and the AS to make that request, why use UMA and not just plain OAuth?
Mark
On 10/12/15 03:23, Mike Schwartz wrote:
Pedro,
It doesn't make sense to me that the RS would obtain the RPT...
Personally, I like the design of the permission ticket, because the UMA Client does not need to know the scopes. Forcing the UMA Client to know the scopes creates a tight bundling with the security infrastructure, and may expose too much information to the UMA Client. I equate this to hard coding LDAP schema in your application. It puts the infrastructure team in a bad situation if the schema changes, because you need to re-QA the app.
However, some people think that just because Google does something, it must be right, or it must scale. So my interest in supporting this feature has more to do with aligning with an existing (bad) pattern.
- Mike
On 2015-12-09 19:37, Pedro Igor Silva wrote:
----- Original Message -----
From: "Mike Schwartz" < mike@gluu.org > To: wg-uma@kantarainitiative.org Sent: Wednesday, December 9, 2015 6:36:32 PM Subject: [WG-UMA] Two thoughts for UMA enhancments
UMA-tarians,
Can we discuss two ideas for enhancments:
1) UMA sans permission ticket
Let's say the UMA Client knows the scopes required to call a certain API. For example, Google documents this: http://gluu.co/google-scopes
In this case, perhaps the client can proactively request an RPT providing the scopes. And this RPT might be acceptable a certain RS for certain resource sets.
We might have already discussed this, but wouldn't this make UMA more compatable with existing API access management infrastructures?
2) UMA without the AAT
Inspired by Justin. I think the AAT adds value in many cases where the AS wants to make policies based on client claims (client id, domain specific catagory, etc). So I'm not saying eliminate the AAT. However, if the policy for access is based on network address only, or perhaps some other fraud detection technique that doesn't involve client identification, I could see a case where the AAT is not needed. So maybe the AAT could be optional?
- Mike
What about the case below ? I think it was lost because I was not able to send messages to this list ...
"I think that when you are in NPE scenario, the permission ticket does not make much sense. This is pretty much related with my second round of questions.
Please correct me if I'm wrong. It seems that the permission ticket is mostly intended to perform a transactional authorization flow, where a RqP will ask permissions to access some one resources and the RO will be able to receive some kind of notification and actually approve this permission any time in the future. Or even to support multiple ASs within the same RS, where the user can choose which AS should be used to obtain permissions for his resources. Here I can see a lot of value, like for cloud and IoT authz ...
However, considering NPE use cases, specially when the RO is the RS, a 1:1 relationship between RS and AS and there is no need for a transactional authorization flow given that RS is protecting its own resources, it might be unnecessary to use a permission ticket in this case. But just:
1) Client tries to access protected resource on behalf of an user (no RPT was sent) 2) RS obtain a RPT for the resource (or with additional resources and scopes) from AS 3) RS validates the response from AS, validates the RPT, enforce authorization and returns the RPT to the client (considering that RPT has the right permissions)"
Any thoughts ?
_______________________________________________ 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
Thanks for the reply! No worries at all on timing, as everyone's a volunteer here (and it took me long enough to reply anyway). (And I get "Even" a lot. :-) Below... *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Wed, Dec 16, 2015 at 10:50 PM, Pedro Igor Silva <psilva@redhat.com> wrote:
Hi Even,
Thanks for looking this and sorry for the late reply :). Answers inline.
----- Original Message -----
From: "Eve Maler" <eve@xmlgrrl.com> To: "Justin Richer" <jricher@mit.edu> Cc: "Michael Schwartz" <mike@gluu.org>, "wg-uma@kantarainitiative.org UMA" <wg-uma@kantarainitiative.org> Sent: Monday, December 14, 2015 4:04:13 PM Subject: Re: [WG-UMA] Two thoughts for UMA enhancments
Let's explore the specific use cases that highlight limitations or impedance mismatches of current flows.
If I understand correctly, Pedro's and Mike's use cases are very similar. We've generally been calling this an API security use case. (BTW, just saying they're "NPE" use cases is ambiguous because there are other flows where a human resource owner shares with an NPE requesting party at some point, but the API security use case does have a non-person entity (organization) as an RO.)
Ok, for now on I'll refer to these use cases as API security as well. And yes, I think Mike and I are trying to address similar problems.
In Thursday's call/notes, I tried some terminology to bifurcate two sub-use cases: plain "API security" where the AS and RS reside in the same domain, and "federated authorization" where it can be useful to decouple the AS and RS. I'm seeing the latter in a bunch of cases, e.g. when it comes to RS's that are partners (SaaS or otherwise) vs. internal -- analogously to "federated authentication".
API security is like traditional web services security use cases, and
it's a
situation where a security architect would often reach for vanilla OAuth.
Agree. But we need to also consider that what you did with UMA allow us to leverage OAuth2 authorization capabilities to a new level, being more suitable in cases where you want fine-grained authorization and give to ROs more control over their resources.
Yep. A person as unambiguous RO is a new step.
It should be possible to use vanilla OAuth2 and still support fine-grained authz and a plenty of UMA-like features (like the permission ticket to handle Person-To-Person authz, obligations, claims gathering, etc), but you will end up reinventing the wheel and be stuck in a proprietary solution.
Indeed, the UMA flows so far have a single (relatively simple) pattern with complex effect. This is where I was sort of going with the ideas that Alice has direct say over Bob's access, and that we have to satisfy a requirement for AS-RS loose coupling; these are the big reasons that the a permission ticket flow popped out of the design process. OAuth, having only one "user" and colocated AS and RS, didn't have (or even think of?) that.
Questions for you guys: What's the "coupling quotient" of the real-life
use
cases being considered? How often are the AS and RS in the same security domain?
I would say that AS and RS in same security domain are pretty common. Specially if you consider some enterprise use cases where you have a single AS serving different applications, where each RS may also have its own and single client. For instance, a vanilla (HTML5 + AngularJS) + RESTFul design. Here we don't have third-party clients consuming RS's API.
Meaning that RS=client (a la Google Apps, where the only app that operates on a GDoc file is the GDoc app)? I'm guessing not, if you'd prefer for the client to be as "dumb" as possible. (But note that there's an extensibility profile <https://docs.kantarainitiative.org/uma/draft-uma-core-v1_0_1.html#alt-resource-profile> for RS = client too.)
In these cases, the client does not need to know the scopes, but just the API. Is up to the RS to discover the scopes and enforce policies based on the relaying party or/and the client accessing the API. For instance:
1) Client (on behalf of an user) tries to access a resource 2) RS knows both ID and scope(s) related with the request and asks the AS for a RPT with the required permissions. 3) AS evaluates the policies based on the authorization request from the RS and issues a RPT. 4) RS enforces the authorization decision from AS and gives back the RPT to the client.
See, the client is pretty much dumb. It does not know about resource ids or scopes. Just like what the permission ticket does. We are just making client's more simple to implement and avoid additional requests (one to send the ticket to AS and another that sends the RPT back to the RS).
Right, this sounds like straight UMA, with a client that can remain dumb wrt scopes but of course needs to know the API. Of course, the RS has the capacity to own/invent/control the scopes, not "just" discover them, because the scopes are essentially a part of the API's design. It is worthy to mention that UMA already supports the flow above. I can
just handle the permission ticket flow within the RS and return back the RPT to the client (or any other result from the AS). But, am I violating any rule by doing this ?
The flow looks sort of similar to today's UMA, but it's not totally accurate for off-the-shelf UMA. If you're suggesting changes in order to remove the permission ticket, making the RS do all that work to get the RPT on behalf of the client (step 2), ending with it giving the resulting RPT to the client along with giving access (step 4), then I have some questions... To be super-clear, here's an annotated version of your flow with the delta from UMA V1.0.1: 1) Client (on behalf of an user) tries to access a resource (that's the same as now -- Core Sec 3.1.1 <https://docs.kantarainitiative.org/uma/draft-uma-core-v1_0_1.html#without-rpt> ) 2) RS knows both ID and scope(s) related with the request and asks the AS for a RPT with the required permissions. (today, Core Sec 3.2 <https://docs.kantarainitiative.org/uma/draft-uma-core-v1_0_1.html#register-permission>, the RS would register a requested permission: a resource set by ID, with as many scopes as desired; we've also floated an extension spec that allows the RS to register multiple resource sets, each with as many scopes as desired) 3) AS evaluates the policies based on the authorization request from the RS and issues a RPT. (today that only happens after the RS gives the permission ticket to the client (Core Sec 3.3.1 <https://docs.kantarainitiative.org/uma/draft-uma-core-v1_0_1.html#permission-success-to-client>) and when the client -- not the RS -- shows up at the RPT endpoint with the permission ticket (Core Sec 3.5.1 <https://docs.kantarainitiative.org/uma/draft-uma-core-v1_0_1.html#rfc.section.3.5.1> )) 4) RS enforces the authorization decision from AS and gives back the RPT to the client. (today that only happens when the client retries access with the RPT -- Core Sec 3.1.2 <https://docs.kantarainitiative.org/uma/draft-uma-core-v1_0_1.html#with-rpt> ) Why bother giving the RPT to the client if the RS could just give access directly? The whole thing would then look really close to an XACML flow, including the PEP/RS (vs. the client, what XACML would call the "application") making the request of the PDP/AS. Another similarity would be AS-RS tight coupling. In these circumstances, it also seems like scopes would be "internal" to the AS-RS, and you could move to getting a simple Permit/Deny answer from the AS instead of the permissions data structure, which could make the RS even simpler than it is now. If there's no RPT, though, then it wouldn't be around to collect/cache a bunch of decisions for later use by the client, but maybe that makes sense to me since the client would never go straight to the AS itself. However, then you could stop using UMA and start using XACML. :-) In cases where the entities do need loose coupling or other UMA/OAuth benefits (scale, dynamic client registration, lighter weight, RESTful, RS wanting to use its right to perform extra authorization against the client and requesting party...), can we assume that this flow wouldn't apply? Is the value of removing the ticket (and possibly change these other things for full optimization) for this glued-together API security flow valuable enough to pursue in UMA vs. sticking with the usual flow? How much optimization can really be achieved, vs. getting other marginal benefits out of using the flow that's already there (if you already are getting benefit out of "dumb" clients, scopes, etc.)?
The same thing applies if I want to obtain a RPT with everything an user/client is entitled to do (entitlements) once. I can just configure the RS to build a permission ticket asking for every single resource/scopes during a first interaction.
This is a relatively common thing to do in other use cases outside of API security as well.
How often does the client need to get credentials dynamically vs. pre-provisioned? (Note that OAuth ecosystems today are tightly coupled by nature: The AS/RS is in one domain, and clients are statically provisioned with credentials, often to be sure that they can execute terms of service.) How often is the client running autonomously, vs. operated by a human?
Right now, I'm more focused with pre-provisioned clients. Although they can also register themselves using OpenID Connect Dynamic Client Registration.
I'm also focused on clients operated by a human. Although I think we can handle autonomous clients using offline tokens to evaluate authorization policies on the AS and enforce them on the RS.
The API security use case overall would normally already be signed up to
smart client that knows the API, knows the API's scopes, knows the AS location, and wants to get down to making API calls. In a
delegation use case, Alice is likely to give Bob first-order consideration -- he'll get what scopes he'll get, and he'll like it! -- in configuring policy constraints.* But in autonomous-client API security use cases, I suspect AliceCorp needs the client to be more, well, autonomous in wanting to request every scope it can handle, and perhaps in some human-operated client variants (AliceCorp-to-Bob) of the API security use case as well (asking up-front for everything it can handle).
So, based on this analysis, some thoughts and key questions.
Thoughts: As I had noted to Pedro in private email back in October,
a person-to-person there is
an “ extensibility profile ” in the UMA Core spec to allow lots of optimizations when the RS and AS are tightly coupled. This would enable more efficient RS-AS communication regarding resource set registration, permission registration, and token introspection — it could all be “implicit” because the same hunk of software is on both sides. However, some tokens would still have to be produced for client consumption because it may still be a third-party hunk of software.
+1. I just want to make sure I'm not violating the rules.
Key questions: What are the actual use cases on the ground so far? Are
they
such that the extensibility profile in the spec provides a starting point from which we could work outward? Or do they support a serious requirement for a "client-to-AS-first" flow in the context of a loosely coupled RS and AS, vs. the currently native "client-to-RS-first" flow in UMA V1.0.x that drove the design of the existing permission ticket and a sufficiently "dumb" client (no knowledge of AS location and no knowledge of scopes)?
My use cases are all based on the currently native "client-to-RS-first". I think "client-to-AS-first" will kill the benefits brought by UMA, specially from a client perspective.
Btw, I like the permission ticket (and the whole idea behind it) and, like I mentioned before, it has a lot of value. Specially for person-to-person delegation use cases.
I think my question for all that should be: Am I violating UMA's rules if I change the flow under certain circumstances ? Or am I forced to always use a permission ticket as defined by the specs ?
Thanks for weighing in! I would love to get your thoughts on my questions above. To summarize my observations, your proposed flow would be more direct, but also doesn't "go all the way" in optimizing the direction you're heading. In your current thinking about your use case, is it more important to optimize fully (get more "XACML-ish"), or optimize a little (roughly your current midway point), or use UMA's other benefits fully (keep something like the current ticket flow)?
----- Original Message -----
From: "Eve Maler" <eve@xmlgrrl.com> To: "Pedro Igor Silva" <psilva@redhat.com> Cc: "Justin Richer" <jricher@mit.edu>, "Michael Schwartz" <mike@gluu.org>, "wg-uma@kantarainitiative.org UMA" <wg-uma@kantarainitiative.org> Sent: Sunday, December 20, 2015 11:55:32 PM Subject: Re: [WG-UMA] Two thoughts for UMA enhancments
Thanks for the reply! No worries at all on timing, as everyone's a volunteer here (and it took me long enough to reply anyway). (And I get "Even" a lot. :-)
Below...
*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
On Wed, Dec 16, 2015 at 10:50 PM, Pedro Igor Silva <psilva@redhat.com> wrote:
Hi Even,
Thanks for looking this and sorry for the late reply :). Answers inline.
----- Original Message -----
From: "Eve Maler" <eve@xmlgrrl.com> To: "Justin Richer" <jricher@mit.edu> Cc: "Michael Schwartz" <mike@gluu.org>, "wg-uma@kantarainitiative.org UMA" <wg-uma@kantarainitiative.org> Sent: Monday, December 14, 2015 4:04:13 PM Subject: Re: [WG-UMA] Two thoughts for UMA enhancments
Let's explore the specific use cases that highlight limitations or impedance mismatches of current flows.
If I understand correctly, Pedro's and Mike's use cases are very similar. We've generally been calling this an API security use case. (BTW, just saying they're "NPE" use cases is ambiguous because there are other flows where a human resource owner shares with an NPE requesting party at some point, but the API security use case does have a non-person entity (organization) as an RO.)
Ok, for now on I'll refer to these use cases as API security as well. And yes, I think Mike and I are trying to address similar problems.
In Thursday's call/notes, I tried some terminology to bifurcate two sub-use cases: plain "API security" where the AS and RS reside in the same domain, and "federated authorization" where it can be useful to decouple the AS and RS. I'm seeing the latter in a bunch of cases, e.g. when it comes to RS's that are partners (SaaS or otherwise) vs. internal -- analogously to "federated authentication".
API security is like traditional web services security use cases, and
it's a
situation where a security architect would often reach for vanilla OAuth.
Agree. But we need to also consider that what you did with UMA allow us to leverage OAuth2 authorization capabilities to a new level, being more suitable in cases where you want fine-grained authorization and give to ROs more control over their resources.
Yep. A person as unambiguous RO is a new step.
It should be possible to use vanilla OAuth2 and still support fine-grained authz and a plenty of UMA-like features (like the permission ticket to handle Person-To-Person authz, obligations, claims gathering, etc), but you will end up reinventing the wheel and be stuck in a proprietary solution.
Indeed, the UMA flows so far have a single (relatively simple) pattern with complex effect. This is where I was sort of going with the ideas that Alice has direct say over Bob's access, and that we have to satisfy a requirement for AS-RS loose coupling; these are the big reasons that the a permission ticket flow popped out of the design process. OAuth, having only one "user" and colocated AS and RS, didn't have (or even think of?) that.
Questions for you guys: What's the "coupling quotient" of the real-life
use
cases being considered? How often are the AS and RS in the same security domain?
I would say that AS and RS in same security domain are pretty common. Specially if you consider some enterprise use cases where you have a single AS serving different applications, where each RS may also have its own and single client. For instance, a vanilla (HTML5 + AngularJS) + RESTFul design. Here we don't have third-party clients consuming RS's API.
Meaning that RS=client (a la Google Apps, where the only app that operates on a GDoc file is the GDoc app)? I'm guessing not, if you'd prefer for the client to be as "dumb" as possible. (But note that there's an extensibility profile <https://docs.kantarainitiative.org/uma/draft-uma-core-v1_0_1.html#alt-resource-profile> for RS = client too.)
In these cases, the client does not need to know the scopes, but just the API. Is up to the RS to discover the scopes and enforce policies based on the relaying party or/and the client accessing the API. For instance:
1) Client (on behalf of an user) tries to access a resource 2) RS knows both ID and scope(s) related with the request and asks the AS for a RPT with the required permissions. 3) AS evaluates the policies based on the authorization request from the RS and issues a RPT. 4) RS enforces the authorization decision from AS and gives back the RPT to the client.
See, the client is pretty much dumb. It does not know about resource ids or scopes. Just like what the permission ticket does. We are just making client's more simple to implement and avoid additional requests (one to send the ticket to AS and another that sends the RPT back to the RS).
Right, this sounds like straight UMA, with a client that can remain dumb wrt scopes but of course needs to know the API. Of course, the RS has the capacity to own/invent/control the scopes, not "just" discover them, because the scopes are essentially a part of the API's design.
Right.
It is worthy to mention that UMA already supports the flow above. I can
just handle the permission ticket flow within the RS and return back the RPT to the client (or any other result from the AS). But, am I violating any rule by doing this ?
The flow looks sort of similar to today's UMA, but it's not totally accurate for off-the-shelf UMA. If you're suggesting changes in order to remove the permission ticket, making the RS do all that work to get the RPT on behalf of the client (step 2), ending with it giving the resulting RPT to the client along with giving access (step 4), then I have some questions...
To be super-clear, here's an annotated version of your flow with the delta from UMA V1.0.1:
1) Client (on behalf of an user) tries to access a resource (that's the same as now -- Core Sec 3.1.1 <https://docs.kantarainitiative.org/uma/draft-uma-core-v1_0_1.html#without-rpt> ) 2) RS knows both ID and scope(s) related with the request and asks the AS for a RPT with the required permissions. (today, Core Sec 3.2 <https://docs.kantarainitiative.org/uma/draft-uma-core-v1_0_1.html#register-permission>, the RS would register a requested permission: a resource set by ID, with as many scopes as desired; we've also floated an extension spec that allows the RS to register multiple resource sets, each with as many scopes as desired) 3) AS evaluates the policies based on the authorization request from the RS and issues a RPT. (today that only happens after the RS gives the permission ticket to the client (Core Sec 3.3.1 <https://docs.kantarainitiative.org/uma/draft-uma-core-v1_0_1.html#permission-success-to-client>) and when the client -- not the RS -- shows up at the RPT endpoint with the permission ticket (Core Sec 3.5.1 <https://docs.kantarainitiative.org/uma/draft-uma-core-v1_0_1.html#rfc.section.3.5.1> )) 4) RS enforces the authorization decision from AS and gives back the RPT to the client. (today that only happens when the client retries access with the RPT -- Core Sec 3.1.2 <https://docs.kantarainitiative.org/uma/draft-uma-core-v1_0_1.html#with-rpt> )
Why bother giving the RPT to the client if the RS could just give access directly?
Because I would prefer to not keep state on the server regarding authz decisions, so I could use the RPT to enforce authz on every request. That said, the RS is still UMA-friendly (supporting a RPT and enforcing authz based on it).
The whole thing would then look really close to an XACML flow, including the PEP/RS (vs. the client, what XACML would call the "application") making the request of the PDP/AS. Another similarity would be AS-RS tight coupling. In these circumstances, it also seems like scopes would be "internal" to the AS-RS, and you could move to getting a simple Permit/Deny answer from the AS instead of the permissions data structure, which could make the RS even simpler than it is now.
More simple, but the permissions data structure from UMA is much better (and rich) and should provide a more stateless model than a bunch of Permit/Deny from AS.
If there's no RPT, though, then it wouldn't be around to collect/cache a bunch of decisions for later use by the client, but maybe that makes sense to me since the client would never go straight to the AS itself. However, then you could stop using UMA and start using XACML. :-)
I do want RPT :) I'm just hacking the RS a bit in order to avoid the permission ticket dance on the client. Considering that there is a single AS and the client should be dumb. And we do want to support XACML too, but for writing policies ...
In cases where the entities do need loose coupling or other UMA/OAuth benefits (scale, dynamic client registration, lighter weight, RESTful, RS wanting to use its right to perform extra authorization against the client and requesting party...), can we assume that this flow wouldn't apply?
Partially. For instance, the flow that I mentioned do creates a tight coupling between AS and RS, impacts Person-to-Person authz, etc. But you still scale, RS can still perform extra authz against client and RqP (considering that I'm not killing RPT), etc.
Is the value of removing the ticket (and possibly change these other things for full optimization) for this glued-together API security flow valuable enough to pursue in UMA vs. sticking with the usual flow? How much optimization can really be achieved, vs. getting other marginal benefits out of using the flow that's already there (if you already are getting benefit out of "dumb" clients, scopes, etc.)?
I don't know. I'm pretty sure we can stick with the usual flow, no problem at all. I'll forget about that "optimization" for a bit and focus on the usual flow.
The same thing applies if I want to obtain a RPT with everything an user/client is entitled to do (entitlements) once. I can just configure the RS to build a permission ticket asking for every single resource/scopes during a first interaction.
This is a relatively common thing to do in other use cases outside of API security as well.
How often does the client need to get credentials dynamically vs. pre-provisioned? (Note that OAuth ecosystems today are tightly coupled by nature: The AS/RS is in one domain, and clients are statically provisioned with credentials, often to be sure that they can execute terms of service.) How often is the client running autonomously, vs. operated by a human?
Right now, I'm more focused with pre-provisioned clients. Although they can also register themselves using OpenID Connect Dynamic Client Registration.
I'm also focused on clients operated by a human. Although I think we can handle autonomous clients using offline tokens to evaluate authorization policies on the AS and enforce them on the RS.
The API security use case overall would normally already be signed up to
smart client that knows the API, knows the API's scopes, knows the AS location, and wants to get down to making API calls. In a
delegation use case, Alice is likely to give Bob first-order consideration -- he'll get what scopes he'll get, and he'll like it! -- in configuring policy constraints.* But in autonomous-client API security use cases, I suspect AliceCorp needs the client to be more, well, autonomous in wanting to request every scope it can handle, and perhaps in some human-operated client variants (AliceCorp-to-Bob) of the API security use case as well (asking up-front for everything it can handle).
So, based on this analysis, some thoughts and key questions.
Thoughts: As I had noted to Pedro in private email back in October,
a person-to-person there is
an “ extensibility profile ” in the UMA Core spec to allow lots of optimizations when the RS and AS are tightly coupled. This would enable more efficient RS-AS communication regarding resource set registration, permission registration, and token introspection — it could all be “implicit” because the same hunk of software is on both sides. However, some tokens would still have to be produced for client consumption because it may still be a third-party hunk of software.
+1. I just want to make sure I'm not violating the rules.
Key questions: What are the actual use cases on the ground so far? Are
they
such that the extensibility profile in the spec provides a starting point from which we could work outward? Or do they support a serious requirement for a "client-to-AS-first" flow in the context of a loosely coupled RS and AS, vs. the currently native "client-to-RS-first" flow in UMA V1.0.x that drove the design of the existing permission ticket and a sufficiently "dumb" client (no knowledge of AS location and no knowledge of scopes)?
My use cases are all based on the currently native "client-to-RS-first". I think "client-to-AS-first" will kill the benefits brought by UMA, specially from a client perspective.
Btw, I like the permission ticket (and the whole idea behind it) and, like I mentioned before, it has a lot of value. Specially for person-to-person delegation use cases.
I think my question for all that should be: Am I violating UMA's rules if I change the flow under certain circumstances ? Or am I forced to always use a permission ticket as defined by the specs ?
Thanks for weighing in! I would love to get your thoughts on my questions above. To summarize my observations, your proposed flow would be more direct, but also doesn't "go all the way" in optimizing the direction you're heading. In your current thinking about your use case, is it more important to optimize fully (get more "XACML-ish"), or optimize a little (roughly your current midway point), or use UMA's other benefits fully (keep something like the current ticket flow)?
Ok. Like I said, I'll focus on the usual flow for now. Thanks for all the feedback, which helped me to get a much clear picture of UMA and some of the design decisions.
participants (7)
-
Adrian Gropper -
Debbie Bucci -
Eve Maler -
Justin Richer -
Mark Dobrinic -
Mike Schwartz -
Pedro Igor Silva