Dear Cyril, all,
Thank you very much for your support and information. I am waiting for
your configuration file

As far as I understand (correct me if I am wrong), in the upcoming
access control model, the connection between Authorized PDP and IdM (the
Attribute Finder) has been removed. This makes the IdM and PDP somehow
more generic and independent, however it might raise a new issue as I
mention in the following:

As you know, in other domains such as our healthcare domain, one of the
reason that we are interested in XACML access control model because of
the flexible capability to create access policies based on many
attributes. Such policies will use not only XACML standard attributes
(e.g. subject-id, resource-id, time etc.) but also our domain-specific
attributes. For example, we have a policy like this:
"Doctor can access medical records of patients from their medical
center. Other doctors can access patient records in case of emergency".
In such policy, we adopt two user domain-specific attributes: care
provider and emergency status

With new architecture, to be sure such attributes can still be extract
from token (if the IdM support) but how the PEP Proxy decide which
attributes to include in the XACML request (do we need to include all
user attributes in the request ?) and when the request contains such
domain-specific attributes, how the PDP understand such attributes in
order to validate the request without communicate with IdM ?

The same concern to the support of domain specific attributes is to the
only FIWARE IdM KeyRock GEri. Does it support a flexible mechanism to
deal with this (e.g. through API or some configuration) ? As far as I
know, the GCP IdM supports such functionality through API that allowing
user create new attributes.

If the GE owner or someone in the list can support, please help us to
clarify this.
Thank you very much,

Bests,
Tran

_______________________________________________
Fiware-tech-help mailing list
Fiware-tech-help@lists.fi-ware.org
https://lists.fi-ware.org/listinfo/fiware-tech-help

Hello Tran,
Please find an example of configuration attached. This example configures the attribute finder to take the value of the following XACML 2.0 attribute (must be provided by the PEP):
<xacml:SubjectAttributeDesignator AttributeId="urn:thalesgroup:xacml:oauth:token"
DataType="http://www.w3.org/2001/XMLSchema#string" />

Note: you can use whatever ID you want for this attribute, instead of urn:thalesgroup:xacml:oauth:token, no standard for this; as long as the PEP uses the same in the XACML request.

... then uses this value to replace

<https://account.lab.fiware.org/user?access_token=%7btoken%7d>

… then does a HTTP GET with this URL (which happens to be the Fi-LAB instance of the IdM in this case), and evaluates the following JSONPath on the response (expected to be JSON format):
$['roles'][*]['name']
Comment: this is bracket-notation, but you can use dot-notation as well.

… to get the value of the new XACML 2.0 attribute:
<xacml:SubjectAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:2.0:subject:role"
DataType="http://www.w3.org/2001/XMLSchema#string" />

For example, if the reply from the IdM is like:

{
"id": 544,
"actorId": 818,
"nickName": "dangerville",
"displayName": "Dangerville",
"email": "cd@gmail.com",
"app_id": 355,
"app_slug": "myapp3",
"roles": [

,

],
"organizations": [

,

,

]
}

… The resulting value of the attribute ‘urn:oasis:names:tc:xacml:2.0:subject:role’ provided by the attribute finder in my example will be:
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">Manager</AttributeValue>
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">Provider</AttributeValue>

As for your other concern/issue regarding, I will answer in a separate thread to avoid mixing things and it is a broader issue involving the IdM and PEP as well.

Regards,
Cyril

De : Tran Quang Thanh thanh.quang.tran@fokus.fraunhofer.de
Envoyé : jeudi 12 février 2015 14:42
À : DANGERVILLE Cyril
Cc : fiware-tech-help@lists.fi-ware.org
Objet : Re: [Fiware-tech-help] Authorize PDP GE

Dear Cyril, all,
Thank you very much for your support and information. I am waiting for your configuration file

As far as I understand (correct me if I am wrong), in the upcoming access control model, the connection between Authorized PDP and IdM (the Attribute Finder) has been removed. This makes the IdM and PDP somehow more generic and independent, however it might raise a new issue as I mention in the following:

As you know, in other domains such as our healthcare domain, one of the reason that we are interested in XACML access control model because of the flexible capability to create access policies based on many attributes. Such policies will use not only XACML standard attributes (e.g. subject-id, resource-id, time etc.) but also our domain-specific attributes. For example, we have a policy like this:
"Doctor can access medical records of patients from their medical center. Other doctors can access patient records in case of emergency".
In such policy, we adopt two user domain-specific attributes: care provider and emergency status

With new architecture, to be sure such attributes can still be extract from token (if the IdM support) but how the PEP Proxy decide which attributes to include in the XACML request (do we need to include all user attributes in the request ?) and when the request contains such domain-specific attributes, how the PDP understand such attributes in order to validate the request without communicate with IdM ?

The same concern to the support of domain specific attributes is to the only FIWARE IdM KeyRock GEri. Does it support a flexible mechanism to deal with this (e.g. through API or some configuration) ? As far as I know, the GCP IdM supports such functionality through API that allowing user create new attributes.

If the GE owner or someone in the list can support, please help us to clarify this.
Thank you very much,

Bests,
Tran

On 11.02.2015 17:48, DANGERVILLE Cyril wrote:

the PEP

Hello again,
I forgot to say that this is just an example for getting the user roles. But you can get anything else from the IdM’s response if you change the JSONPath accordingly. To get multiple user attributes with different JSONPaths, you can have multiple “providedAttribute” elements as well.

Regards,
Cyril

De : DANGERVILLE Cyril
Envoyé : vendredi 13 février 2015 18:06
À : Tran Quang Thanh
Cc : fiware-tech-help@lists.fi-ware.org
Objet : RE: [Fiware-tech-help] Authorize PDP GE

Hello Tran,
Please find an example of configuration attached. This example configures the attribute finder to take the value of the following XACML 2.0 attribute (must be provided by the PEP):
<xacml:SubjectAttributeDesignator AttributeId="urn:thalesgroup:xacml:oauth:token"
DataType="http://www.w3.org/2001/XMLSchema#string" />

Note: you can use whatever ID you want for this attribute, instead of urn:thalesgroup:xacml:oauth:token, no standard for this; as long as the PEP uses the same in the XACML request.

... then uses this value to replace

<https://account.lab.fiware.org/user?access_token=%7btoken%7d>

… then does a HTTP GET with this URL (which happens to be the Fi-LAB instance of the IdM in this case), and evaluates the following JSONPath on the response (expected to be JSON format):
$['roles'][*]['name']
Comment: this is bracket-notation, but you can use dot-notation as well.

… to get the value of the new XACML 2.0 attribute:
<xacml:SubjectAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:2.0:subject:role"
DataType="http://www.w3.org/2001/XMLSchema#string" />

For example, if the reply from the IdM is like:

{
"id": 544,
"actorId": 818,
"nickName": "dangerville",
"displayName": "Dangerville",
"email": "cd@gmail.com<cd@gmail.com>",
"app_id": 355,
"app_slug": "myapp3",
"roles": [

,

],
"organizations": [

,

,

]
}

… The resulting value of the attribute ‘urn:oasis:names:tc:xacml:2.0:subject:role’ provided by the attribute finder in my example will be:
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">Manager</AttributeValue>
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">Provider</AttributeValue>

As for your other concern/issue regarding, I will answer in a separate thread to avoid mixing things and it is a broader issue involving the IdM and PEP as well.

Regards,
Cyril

De : Tran Quang Thanh thanh.quang.tran@fokus.fraunhofer.de
Envoyé : jeudi 12 février 2015 14:42
À : DANGERVILLE Cyril
Cc : fiware-tech-help@lists.fi-ware.org<fiware-tech-help@lists.fi-ware.org>
Objet : Re: [Fiware-tech-help] Authorize PDP GE

Dear Cyril, all,
Thank you very much for your support and information. I am waiting for your configuration file

As far as I understand (correct me if I am wrong), in the upcoming access control model, the connection between Authorized PDP and IdM (the Attribute Finder) has been removed. This makes the IdM and PDP somehow more generic and independent, however it might raise a new issue as I mention in the following:

As you know, in other domains such as our healthcare domain, one of the reason that we are interested in XACML access control model because of the flexible capability to create access policies based on many attributes. Such policies will use not only XACML standard attributes (e.g. subject-id, resource-id, time etc.) but also our domain-specific attributes. For example, we have a policy like this:
"Doctor can access medical records of patients from their medical center. Other doctors can access patient records in case of emergency".
In such policy, we adopt two user domain-specific attributes: care provider and emergency status

With new architecture, to be sure such attributes can still be extract from token (if the IdM support) but how the PEP Proxy decide which attributes to include in the XACML request (do we need to include all user attributes in the request ?) and when the request contains such domain-specific attributes, how the PDP understand such attributes in order to validate the request without communicate with IdM ?

The same concern to the support of domain specific attributes is to the only FIWARE IdM KeyRock GEri. Does it support a flexible mechanism to deal with this (e.g. through API or some configuration) ? As far as I know, the GCP IdM supports such functionality through API that allowing user create new attributes.

If the GE owner or someone in the list can support, please help us to clarify this.
Thank you very much,

Bests,
Tran

On 11.02.2015 17:48, DANGERVILLE Cyril wrote:

the PEP

Hello Tran,
I included the IdM (and PEP Proxy) GE Owner – Alvaro – in the discussion and changed the subject to make it more explicit. I just want to clarify your use case before giving an answer.

1) Can you give value examples for the attribute “care provider”? Is it the role/type of the person taking care of the patient? Doctor, nurse, intern, etc. In which case, “roles” (supported by the IdM) can be used for that.

2) As far as I understand, the “emergency status” is not a user attribute as it is not user-specific, is it? If it is like a “global” status, in XACML jargon, it is considered a Environment attribute. Maybe if the IdM supports adding custom attributes to applications and your healthcare application is registered in the IdM, you could get the attribute value from the IdM. To be checked with the IdM owner. Otherwise, such attribute is provided by an application/use-case-specific source of attributes, maybe the healthcare application itself.

Regards,
Cyril

De : Tran Quang Thanh thanh.quang.tran@fokus.fraunhofer.de
Envoyé : jeudi 12 février 2015 14:42
À : DANGERVILLE Cyril
Cc : fiware-tech-help@lists.fi-ware.org
Objet : Re: [Fiware-tech-help] Authorize PDP GE

Dear Cyril, all,
Thank you very much for your support and information. I am waiting for your configuration file

As far as I understand (correct me if I am wrong), in the upcoming access control model, the connection between Authorized PDP and IdM (the Attribute Finder) has been removed. This makes the IdM and PDP somehow more generic and independent, however it might raise a new issue as I mention in the following:

As you know, in other domains such as our healthcare domain, one of the reason that we are interested in XACML access control model because of the flexible capability to create access policies based on many attributes. Such policies will use not only XACML standard attributes (e.g. subject-id, resource-id, time etc.) but also our domain-specific attributes. For example, we have a policy like this:
"Doctor can access medical records of patients from their medical center. Other doctors can access patient records in case of emergency".
In such policy, we adopt two user domain-specific attributes: care provider and emergency status

With new architecture, to be sure such attributes can still be extract from token (if the IdM support) but how the PEP Proxy decide which attributes to include in the XACML request (do we need to include all user attributes in the request ?) and when the request contains such domain-specific attributes, how the PDP understand such attributes in order to validate the request without communicate with IdM ?

The same concern to the support of domain specific attributes is to the only FIWARE IdM KeyRock GEri. Does it support a flexible mechanism to deal with this (e.g. through API or some configuration) ? As far as I know, the GCP IdM supports such functionality through API that allowing user create new attributes.

If the GE owner or someone in the list can support, please help us to clarify this.
Thank you very much,

Bests,
Tran

On 11.02.2015 17:48, DANGERVILLE Cyril wrote:

the PEP

Hi Cyril,
Thank you very much for your support.
They are all patient attributes. Care Provider is the organization/department that take care patient. Emergency is also a sensitive patient attribute that we need for patient emergency use case.
I just want to give an example that possible different non-standard attributes are required.
In healthcare domain, they are specifying different types of human resources such as Patient, Practitioner, Related Person (http://www.hl7.org/implement/standards/fhir/resourcelist.html)

Bests,
Tran

Hi Tran,

the addition of metadata for users is not possible in the current implementation of Keyrock. And today we have not immediate plans to add something similar. However, as the new release is based on Openstack Keystone, if you are going to deploy your own instance of the component it is so easy to add a new field in the Users API in order to enable this type of parameters. We can give you some pointers in order to achieve that.

I hope this helps,
BR
–
Álvaro

_______________________________________________
Fiware-tech-help mailing list
Fiware-tech-help@lists.fi-ware.org
https://lists.fi-ware.org/listinfo/fiware-tech-help

Dear Cyril, Alonso,
Thank you very much for your information.
If I got correctly, upcoming (modified) OpenStack Keystone will provide
such functionality and replace KeyRock IdM at FIWARE Lab.
Will it be another FIWARE IdM GEri ?

Also please give some hints about my first consideration in the last email:

With new architecture, to be sure such attributes can still be extract
from token (if the IdM support) but how the PEP Proxy decide which
attributes to include in the XACML request (do we need to include all
user attributes in the request ?) and when the request contains such
domain-specific attributes, how the PDP understand such attributes in
order to validate the request without communicate with IdM ?

Bests,
Tran

_______________________________________________
Fiware-tech-help mailing list
Fiware-tech-help@lists.fi-ware.org
https://lists.fi-ware.org/listinfo/fiware-tech-help

Hi Tran,

no, the new release doesn’t include that functionality. What I mean is that if you are going to use your own instance (not the official one deployed in FILAB), it is so easy for you to implement that functionality.

Anyway we will keep you informed if there are future plans to work on that direction.

BR
–
Álvaro

_______________________________________________
Fiware-tech-help mailing list
Fiware-tech-help@lists.fi-ware.org
https://lists.fi-ware.org/listinfo/fiware-tech-help

1) By "implement that functionality", you mean "modify/extend the code of KeyRock", don't you?

2) Regarding the second point, do you already know how the mapping from IdM to XACML attributes (in the XACML request) will be configured in the next release of the PEP proxy?

Thank you.

Regards,
Cyril

De : Álvaro Alonso aalonsog@dit.upm.es
Envoyé : mardi 17 février 2015 14:33
À : Tran Quang Thanh
Cc : DANGERVILLE Cyril; fiware-tech-help@lists.fi-ware.org
Objet : Re: [Fiware-tech-help] IdM GE - Adding new attributes (e.g. application-specific)

Hi Tran,

no, the new release doesn't include that functionality. What I mean is that if you are going to use your own instance (not the official one deployed in FILAB), it is so easy for you to implement that functionality.

Anyway we will keep you informed if there are future plans to work on that direction.

BR
–
Álvaro

El 17 Feb 2015, a las 13:53, Tran Quang Thanh <thanh.quang.tran@fokus.fraunhofer.de<thanh.quang.tran@fokus.fraunhofer.de>> escribió:

Dear Cyril, Alonso,
Thank you very much for your information.
If I got correctly, upcoming (modified) OpenStack Keystone will provide such functionality and replace KeyRock IdM at FIWARE Lab.
Will it be another FIWARE IdM GEri ?

Also please give some hints about my first consideration in the last email:

With new architecture, to be sure such attributes can still be extract
from token (if the IdM support) but how the PEP Proxy decide which
attributes to include in the XACML request (do we need to include all
user attributes in the request ?) and when the request contains such
domain-specific attributes, how the PDP understand such attributes in
order to validate the request without communicate with IdM ?

Bests,
Tran

On 16.02.2015 15:48, Álvaro Alonso wrote:

With new architecture, to be sure such attributes can still be extract
from token (if the IdM support) but how the PEP Proxy decide which
attributes to include in the XACML request (do we need to include all
user attributes in the request ?) and when the request contains such
domain-specific attributes, how the PDP understand such attributes in
order to validate the request without communicate with IdM ?

Hi, answers inline

Yes.

It will be done in the same way as it is right now. We will include HTTP Verb and Path.

Best
Álvaro

_______________________________________________
Fiware-tech-help mailing list
Fiware-tech-help@lists.fi-ware.org
https://lists.fi-ware.org/listinfo/fiware-tech-help