5:11 p.m.
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?
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)?
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
1:08 p.m.
New subject: 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
9:57 a.m.
New subject: Additional attributes for an authorization request
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).
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)?
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@amdocs.com<mailto:Ori.Doolman@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@lists.jboss.org<mailto:keycloak-user@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
11:54 a.m.
New subject: Additional attributes for an authorization request
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
1:10 p.m.
New subject: Additional attributes for an authorization request
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.
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?
Thanks,
Ori.
From: Pedro Igor Silva [mailto:psilva@redhat.com]
Sent: יום ג 14 פברואר 2017 12:54
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 Tue, Feb 14, 2017 at 6:57 AM, Ori Doolman
<Ori.Doolman@amdocs.com<mailto:Ori.Doolman@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<http://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<mailto:psilva@redhat.com>]
Sent: יום ב 13 פברואר 2017 14:09
To: Ori Doolman <Ori.Doolman@Amdocs.com<mailto:Ori.Doolman@Amdocs.com>>
Cc: keycloak-user@lists.jboss.org<mailto:keycloak-user@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@amdocs.com<mailto:Ori.Doolman@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@lists.jboss.org<mailto:keycloak-user@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
5:43 p.m.
New subject: Additional attributes for an authorization request
On Tue, Feb 14, 2017 at 10:10 AM, Ori Doolman <Ori.Doolman(a)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@redhat.com]
*Sent:* יום ג 14 פברואר 2017 12:54
*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 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.
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@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
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
12:55 p.m.
New subject: Additional attributes for an authorization request
Pedro,
Thank you for all the helpful information.
We’ll try that.
Ori.
From: Pedro Igor Silva [mailto:psilva@redhat.com]
Sent: יום ג 14 פברואר 2017 18:43
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 Tue, Feb 14, 2017 at 10:10 AM, Ori Doolman
<Ori.Doolman@amdocs.com<mailto:Ori.Doolman@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@redhat.com<mailto:psilva@redhat.com>]
Sent: יום ג 14 פברואר 2017 12:54
To: Ori Doolman <Ori.Doolman@Amdocs.com<mailto:Ori.Doolman@Amdocs.com>>
Cc: keycloak-user@lists.jboss.org<mailto:keycloak-user@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@amdocs.com<mailto:Ori.Doolman@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<http://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<mailto:psilva@redhat.com>]
Sent: יום ב 13 פברואר 2017 14:09
To: Ori Doolman <Ori.Doolman@Amdocs.com<mailto:Ori.Doolman@Amdocs.com>>
Cc: keycloak-user@lists.jboss.org<mailto:keycloak-user@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@amdocs.com<mailto:Ori.Doolman@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@lists.jboss.org<mailto:keycloak-user@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
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
12:15 p.m.
New subject: Additional attributes for an authorization request
Hi,
Another requirement I have in my application is that a single authenticated user is
allowed to access many albums (hierarchy of albums, actually) and one album can be
accessed by multiple users. Many-to-many relationship.
Now I have a problem because I cannot use the same policy and also I cannot have a custom
attribute per user with the list of allowed albums (list can become very long).
What should be the approach in that case ?
The policy I want to have is that all the albums a user can access belong to the same
hierarchy (root ID is the same). Maybe this can be used to simplify the solution.
Thanks,
Ori.
-----Original Message-----
From: keycloak-user-bounces(a)lists.jboss.org [mailto:keycloak-user-bounces@lists.jboss.org]
On Behalf Of Ori Doolman
Sent: יום ד 15 פברואר 2017 13:56
To: Pedro Igor Silva <psilva(a)redhat.com>
Cc: keycloak-user(a)lists.jboss.org
Subject: Re: [keycloak-user] Additional attributes for an authorization request
Pedro,
Thank you for all the helpful information.
We’ll try that.
Ori.
From: Pedro Igor Silva [mailto:psilva@redhat.com]
Sent: יום ג 14 פברואר 2017 18:43
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 Tue, Feb 14, 2017 at 10:10 AM, Ori Doolman
<Ori.Doolman@amdocs.com<mailto:Ori.Doolman@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@redhat.com<mailto:psilva@redhat.com>]
Sent: יום ג 14 פברואר 2017 12:54
To: Ori Doolman <Ori.Doolman@Amdocs.com<mailto:Ori.Doolman@Amdocs.com>>
Cc: keycloak-user@lists.jboss.org<mailto:keycloak-user@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@amdocs.com<mailto:Ori.Doolman@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<http://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<mailto:psilva@redhat.com>]
Sent: יום ב 13 פברואר 2017 14:09
To: Ori Doolman <Ori.Doolman@Amdocs.com<mailto:Ori.Doolman@Amdocs.com>>
Cc: keycloak-user@lists.jboss.org<mailto:keycloak-user@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@amdocs.com<mailto:Ori.Doolman@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@lists.jboss.org<mailto:keycloak-user@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
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
4:18 p.m.
New subject: Additional attributes for an authorization request
Hi Ori,
Maybe you can use the type or uri attribute for this purpose with a JS
policy ? If you define a value from where you can determine the hierarchy
using one of this fields, it could work ...
Like we discussed, best thing is either support custom atttributes along
authz request or support custom attributes for resources. I have included
that in the roadmap, plan is to start pushing more things to AuthZ in KC
3.0.
On Tue, Feb 21, 2017 at 8:15 AM, Ori Doolman <Ori.Doolman(a)amdocs.com> wrote:
Hi,
Another requirement I have in my application is that a single
authenticated user is allowed to access many albums (hierarchy of albums,
actually) and one album can be accessed by multiple users. Many-to-many
relationship.
Now I have a problem because I cannot use the same policy and also I
cannot have a custom attribute per user with the list of allowed albums
(list can become very long).
What should be the approach in that case ?
The policy I want to have is that all the albums a user can access belong
to the same hierarchy (root ID is the same). Maybe this can be used to
simplify the solution.
Thanks,
Ori.
-----Original Message-----
From: keycloak-user-bounces(a)lists.jboss.org [mailto:keycloak-user-bounces@
lists.jboss.org] On Behalf Of Ori Doolman
Sent: יום ד 15 פברואר 2017 13:56
To: Pedro Igor Silva <psilva(a)redhat.com>
Cc: keycloak-user(a)lists.jboss.org
Subject: Re: [keycloak-user] Additional attributes for an authorization
request
Pedro,
Thank you for all the helpful information.
We’ll try that.
Ori.
From: Pedro Igor Silva [mailto:psilva@redhat.com]
Sent: יום ג 14 פברואר 2017 18:43
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 Tue, Feb 14, 2017 at 10:10 AM, Ori Doolman <Ori.Doolman(a)amdocs.com<
mailto:Ori.Doolman@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@redhat.com<mailto:psilva@redhat.com
>]
Sent: יום ג 14 פברואר 2017 12:54
To: Ori Doolman <Ori.Doolman@Amdocs.com<mailto:Ori.Doolman@Amdocs.com>>
Cc: keycloak-user@lists.jboss.org<mailto:keycloak-user@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(a)amdocs.com<
mailto:Ori.Doolman@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<http://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<mailto:psilva@redhat.com
>]
Sent: יום ב 13 פברואר 2017 14:09
To: Ori Doolman <Ori.Doolman@Amdocs.com<mailto:Ori.Doolman@Amdocs.com>>
Cc: keycloak-user@lists.jboss.org<mailto:keycloak-user@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<
mailto:Ori.Doolman@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@lists.jboss.org<mailto:keycloak-user@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
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
2885
days inactive
2910
days old
8 comments
2 participants
participants (2)
-
Ori Doolman -
Pedro Igor Silva