Details
-
Type:
extRequest
-
Status: Closed
-
Priority:
Major
-
Resolution: Done
-
Fix Version/s: Sprint 4.2.3, 2021
-
Component/s: FIWARE-TECH-HELP
-
Labels:None
-
HD-Chapter:Security
-
HD-Enabler:AuthZForce
Description
Hello Tran,
I am currently checking that the attribute finder module works with the latest version of KeyRock running at:
https://account.lab.fiware.org/home
I'll send an example of configuration to you by Friday EOB.
Be aware that this attribute finder works with the last R3 release of the GEi (v3.3.3 released 2014-03-31 to be accurate) deployed currently on the global instance (az.testbed.fi-ware.eu). But we do not plan to make it compatible with the new release 4.1 and later anymore. I am saying that in case you want to migrate to the new version. Indeed, starting with release 4.1, the preferred alternative is to rely on the PEP to get the user attributes from the Identity Manager (e.g. KeyRock), based on the token, and provide these attributes to the Authorization PDP (in XACML request) instead of the raw OAuth token. This is why the PEP Proxy reference implementation (Wilma, by UPM) will provide this feature in next release 4.2:
http://catalogue.fi-ware.org/enablers/pep-proxy-wilma
Maybe you are already using such proxy for authentication.
Regards,
Cyril
> ----Message d'origine----
> De : DANGERVILLE Cyril
> Envoyé : jeudi 5 février 2015 18:36
> À : Tran Quang Thanh
> Objet : RE: Authorize PDP GE
>
> Dear Tran,
> The FIWARE coordination team now requires that all requests for
> technical support on GEs be submitted to the fiware-tech-help mailing
> list. Can you re-submit your request to this address?
> fiware-tech-help@lists.fi-ware.org
>
> Thank you,
> Cyril
>
> –
> Cyril DANGERVILLE, Thales Services
> FIWARE Phase II / WP1.7 Security (WPA), T1.7.2 Identity & Access
> Management (Contributor), Authorization PDP (ex-Access Control) GE
> Owner
>
> > ----Message d'origine----
> > De : Tran Quang Thanh thanh.quang.tran@fokus.fraunhofer.de
> > Envoyé : mercredi 4 février 2015 14:02 À : DANGERVILLE Cyril Objet :
> > Authorize PDP GE
> >
> > Dear Cyril Dangerville,
> > My name is Tran Quang Thanh from TU-Berlin, Germany. I am now working
> > in FI-PPP FI-STAR project.
> > As far as I know, your attribute finder module can integrate with
> > other IdM GE such as GCP.
> > At this point in time, is it possible to use the open source KeyRock
> > IdM GE ? and if yes could you please send us your current
> > configuration with KeyRock.
> > 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
Issue Links
- is duplicated by
-
HELP-2095
FIWARE.Request.Tech.Security.AuthorizationPDP.KeyRockIdMAttributeFinder
-
- Closed
-
Activity
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
{token} in the URL:https://account.lab.fiware.org/user?access_token={token}
<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": [
,
{ "id": 107, "name": "Manager" }],
"organizations": [
,
{ "id": 708, "actorId": 5347, "displayName": "MyOrg0", "roles": [] },
{ "id": 1238, "actorId": 9360, "displayName": "Org1", "roles": [] }]
}
… 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
{token} in the URL:https://account.lab.fiware.org/user?access_token={token}
<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": [
,
{ "id": 107, "name": "Manager" }],
"organizations": [
,
{ "id": 708, "actorId": 5347, "displayName": "MyOrg0", "roles": [] },
{ "id": 1238, "actorId": 9360, "displayName": "Org1", "roles": [] }]
}
… 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
Hello Alvaro,
I am forwarding you a question from Tran (in CC):
Is it possible to define new attributes for a user in the IdM, e.g. application-specific?
I don't think it is in the IdM GE specification, but maybe this is possible with KeyRock?
Thanks for your help on this.
Regards,
Cyril
_______________________________________________
Fiware-tech-help mailing list
Fiware-tech-help@lists.fi-ware.org
https://lists.fi-ware.org/listinfo/fiware-tech-help
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
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