[keycloak-user] Additional attributes for an authorization request

Pedro Igor Silva psilva at redhat.com
Tue Feb 14 05:54:14 EST 2017


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.equ
> als($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
>


More information about the keycloak-user mailing list