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