[keycloak-user] Additional attributes for an authorization request
Pedro Igor Silva
psilva at redhat.com
Tue Feb 14 11:43:14 EST 2017
On Tue, Feb 14, 2017 at 10:10 AM, Ori Doolman <Ori.Doolman at amdocs.com>
wrote:
> Hi Pedro,
>
>
>
> This is great, and will work for all album APIs of the format /album/{id}.
>
> I wonder if the $permission.resource takes its value from the
> policy-enforcer path or from the URL of the API call at runtime? I suppose
> the latter and I suppose it is always the *full* URL path from the http
> request.
>
Yes, from the latter.
>
>
> In our resource server I have also APIs with additional path level similar
> to:
>
>
>
> /album/{albumId}/picture/{picId}
>
>
>
> For this API, I still want to check that user is allowed to access the
> album.
>
> How would such an API be forced to match same policy of the album?
>
>
>
> Should I configure the following path in policy-enforcer:
>
> "path" : "/album/{id}/*”
>
>
>
> and have a more sophisticated policy rule based on the runtime value
> $permission.resource which now becomes “/album/17/picture/12” (for
> example) and truncate the string to “/album/17” and perform the condition
> on it as the album resource?
>
>
>
> Or is there a better method?
>
I think you don't actually need that wildcard at the end, so this should
work:
"path" : "/album/{id}”
When checking paths with a pattern, the enforcer queries the server for a
resource with the runtime path. For instance, if your pattern is
/album/{id} and client is trying to access /album/1/picture/2, the enforcer
will query the server for a resource with an URI that matches
/album/1/picture/2.
In case of that PhotoZ App (which is using UMA protocol), the enforcer is
going to return to the client a permission ticket for the resource
previously resolved. Then when the client finally send an authorization
request to KC, KC is going to evaluate all permissions for the resource.
Giving you as a result a final token with past permissions plus new ones
(if granted). This is how UMA flow works, basically ....
However, I know our enforcer is very limited in respect to patterns within
patterns. That is something we need to improve ....
>
>
> Thanks,
>
> Ori.
>
>
>
>
>
>
>
>
>
> *From:* Pedro Igor Silva [mailto:psilva at redhat.com]
> *Sent:* יום ג 14 פברואר 2017 12:54
>
> *To:* Ori Doolman <Ori.Doolman at Amdocs.com>
> *Cc:* keycloak-user at lists.jboss.org
> *Subject:* Re: [keycloak-user] Additional attributes for an authorization
> request
>
>
>
> On Tue, Feb 14, 2017 at 6:57 AM, Ori Doolman <Ori.Doolman at amdocs.com>
> wrote:
>
> Hi Pedro,
>
>
>
> Thank you for the answer.
>
> There is still one thing I fail to understand around point (3) where you
> wrote: “to resolve a specific resource instance”.
>
>
>
>
>
> In the photoz application code, when an album is created, an associated
> resource is created that is owned by the user that created the album
>
>
>
> ResourceRepresentation albumResource = new
> ResourceRepresentation(album.getName(), scopes, "/album/" +
> album.getId(), "http://photoz.com/album");
>
>
>
> It matches on the PEP policy-enforcer configuration:
>
>
>
> {
>
> "name" : "Album Resource",
>
> "path" : "/album/{id}",
>
> "methods" : [
>
> {
>
> "method": "DELETE",
>
> "scopes" : ["urn:photoz.com:scopes:album:delete"]
>
> },
>
> {
>
> "method": "GET",
>
> "scopes" : ["urn:photoz.com:scopes:album:view"]
>
> }
>
> ]
>
> },
>
>
>
> Which matches the PDP typed resource configuration:
>
>
>
> {
>
> "name": "Album Resource",
>
> "uri": "/album/*",
>
> "type": "http://photoz.com/album",
>
> "scopes": [
>
> {
>
> "name": "urn:photoz.com:scopes:album:view"
>
> },
>
> {
>
> "name": "urn:photoz.com:scopes:album:delete"
>
> },
>
> {
>
> "name": "urn:photoz.com:scopes:album:create"
>
> }
>
> ]
>
> },
>
>
>
> Which ends up with the rule:
>
>
>
> rule "Authorize Resource Owner"
>
> dialect "mvel"
>
> when
>
> $evaluation : Evaluation(
>
> $identity: context.identity,
>
> $permission: permission,
>
> $permission.resource != null && $permission.resource.owner.
> equals($identity.id)
>
> )
>
> then
>
> $evaluation.grant();
>
> end
>
>
>
>
>
>
>
> So the "magic" lies with the typed resource uri "/album/*".
> This is what making it to match also the path in the policy enforcer (and
> the actual url in runtime of the rest API).
>
>
>
> Exactly. One of the main points here is that you can map any path in your
> application to a resource, so you don't necessarily need to set URIs to
> your resources as long as you provide a configuration like above.
>
>
>
>
> The demo creates many album resources, one for each new album created.
> But when it is evaluating the policy, how does $permission.resource references
> to the proper album resource each time and not just to the typed “Album
> Resource” resource?
> This is the part I failed to understand.
> Does the $permission.resource value at runtime actually becomes
> "/album/17" (for example)?
>
>
>
> Yes.
>
>
>
>
>
>
>
> Regards,
>
> Ori.
>
>
>
>
>
>
>
>
>
> *From:* Pedro Igor Silva [mailto:psilva at redhat.com]
> *Sent:* יום ב 13 פברואר 2017 14:09
> *To:* Ori Doolman <Ori.Doolman at Amdocs.com>
> *Cc:* keycloak-user at lists.jboss.org
> *Subject:* Re: [keycloak-user] Additional attributes for an authorization
> request
>
>
>
> On Thu, Feb 9, 2017 at 2:11 PM, Ori Doolman <Ori.Doolman at amdocs.com>
> wrote:
>
> Hi Pedro Igor,
> You wrote:
> You can't pass additional attributes along with an authorization request.
> However, that is something we want to support on future versions.
>
> I have some questions about that:
>
> 1. Which future version will support that? Any plan for it at the
> moment?
>
>
>
> Sorry, but can't give you any dates. There are quite a few things in authz
> services roadmap, but right now we have some time and resource constraints
> that are blocking us to follow a plan/roadmap.
>
>
>
>
> 2. Until it is supported, what would be the best practice
> recommendation to authorize resources such as account numbers?
>
> For example: The REST API (resource) I want to protect in the resource
> server is /api/getAccountDetails/{accountNum}. How should I configure
> the policy/permissions/resources/scopes in the PDP and how should I
> utilize the PEP (I'm using Java adapter for JBOSS Fuse)?
>
>
>
> It seems this one is already supported. I would suggest you to take a look
> at the PhotoZ example about how to protect individual resources. There you
> will find:
>
>
>
> 1) How to create resources from your resource server using the Protection
> API using the Java AuthZ Client API.
>
> 2) How "typed" resources work, where you define permissions to a generic
> resources and these permissions are also applied to resources with the same
> type.
>
> 3) How to configure "policy-enforcer" to handle paths with a pattern in
> order to resolve a specific resource instance (e.g.: the account details in
> your example). Something like that:
>
>
>
> {
>
> "name" : "Album Resource",
>
> "path" : "/album/{id}",
>
> "methods" : [
>
> {
>
> "method": "DELETE",
>
> "scopes" : ["urn:photoz.com:scopes:album:delete"]
>
> },
>
> {
>
> "method": "GET",
>
> "scopes" : ["urn:photoz.com:scopes:album:view"]
>
> }
>
> ]
>
> }
>
>
>
>
>
> Thank you,
> Ori.
>
>
>
> This message and the information contained herein is proprietary and
> confidential and subject to the Amdocs policy statement,
>
> you may review at http://www.amdocs.com/email_disclaimer.asp
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>
> This message and the information contained herein is proprietary and
> confidential and subject to the Amdocs policy statement,
>
> you may review at http://www.amdocs.com/email_disclaimer.asp
>
>
> This message and the information contained herein is proprietary and
> confidential and subject to the Amdocs policy statement,
> you may review at http://www.amdocs.com/email_disclaimer.asp
>
More information about the keycloak-user
mailing list