[Fiware-tech-help] Authorize PDP GE

[DANGERVILLE Cyril]

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 at 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 at gmail.com<mailto:cd at gmail.com>",
    "app_id": 355,
    "app_slug": "myapp3",
    "roles": [{
        "id": 106,
        "name": "Provider"
    },{
        "id": 107,
        "name": "Manager"
    }],
    "organizations": [{
        "id": 110,
        "actorId": 820,
        "displayName": "Acme",
        "roles": []
    }, {
        "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 [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<mailto: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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/fiware-tech-help/attachments/20150213/2894df6e/attachment.html>