On Tue, Feb 14, 2017 at 6:57 AM, Ori Doolman <Ori.Doolman(a)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@redhat.com]
*Sent:* יום ב 13 פברואר 2017 14:09
*To:* Ori Doolman <Ori.Doolman(a)Amdocs.com>
*Cc:* keycloak-user(a)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(a)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(a)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