5:35 p.m.
On Fri, May 5, 2017 at 11:18 AM, Scott Elliott <scottpelliott(a)gmail.com>
wrote:
On Fri, May 5, 2017 at 7:51 AM Pedro Igor Silva <psilva(a)redhat.com> wrote:
> On Thu, Apr 20, 2017 at 3:38 PM, Scott Elliott <scottpelliott(a)gmail.com>
> wrote:
>
>> Using the photoz application as an example, what is the expected
>> performance if there are a very large (say, 5M) number of albums? What
>> about if there are multiple resources per album? You quickly get a very
>> large number of resources. The OIDC adapters cache some number of these,
>> so
>> what effect will that have on the resource server?
>>
>
> Right now we cache things based on a very simple LRU cache with some
> expiration of entries. Number of cached entries is fixed though. Something
> we can expose via configuration.
>
"Right now" being 3.1.0.CR1? What about in 2.5.5.Final?
Yes, right now 3.1.0.CR1. The cache is only available on 3.1.0.CR1+.
>
>
>>
>> Ideally there would be a way to authorize any resource associated with an
>> album, so if /album/vacation were authorized by /album/{id},
>> /album/vacation/photo/1 was also authorized, i.e., the URI that selects
>> the
>> resource to be authorized would always be /album/vacation.
>>
>
> All depends on how fined grained you want your config. For instance, if
> you define a path "/album/{id}/*", the same resource (and associated
> permissions) will also be related with resources like "/album/vacation"
and
> "/album/vacation/photo/1". However, if you have a resource on the server
> with a path "/album/vacation/photo/1", the enforcer is going to use this
> resource to check whether the user has access or not.
>
>
This gets us back to my original question about passing other info to the
authorization request. Right now we'd have too many resources that would
need to be registered and maintained. I did a hack as a test to add the
actual URL to the permission request, and set it in the ticket in the
permission response, so that it is passed to the authorization request, and
can be accessed as part of the evaluation context. It does what we need,
but I do not know if it violates any standard.
I don't think it violates UMA as the ticket can hold whatever we want. But
what I think we should do is provide to you and your resource server some
way to populate the ticket (or an entitlement request) with additional
info. I'm still not sure how to provide a callback for this, still trying
to figure out. It would require something on the adapter side that you
could register a callback to be invoked prior to building the
ticket/authorization request.
Scott