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 ________________________________________ From: DANGERVILLE Cyril [cyril.dangerville at thalesgroup.com] Sent: Friday, February 13, 2015 7:12 PM To: Tran, Thanh Quang Cc: fiware-tech-help at lists.fi-ware.org; Álvaro Alonso Subject: [Fiware-tech-help] IdM GE - Adding new attributes (e.g. application-specific) 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 [mailto:thanh.quang.tran at fokus.fraunhofer.de] Envoyé : jeudi 12 février 2015 14:42 À : DANGERVILLE Cyril Cc : fiware-tech-help at 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
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy