[Fiware-api-cross] Attributes and response needed by the Proxy

[DANGERVILLE Cyril]

Hello,
This seems OK to me from the PDP side. With the following clarifications for each attribute, and answer to your question:

1.       *OAuth token expiration date*. Retrieved from the standard "exp" claim of the JSON Web token (JWT) that is used as the OAuth token, and that your proxy is required to send to the PDP: http://self-issued.info/docs/draft-ietf-oauth-json-web-token.html#expDef

Please note that the date format for that "exp" (=IntDate= number of seconds from 1970-01-01T0:0:0Z UTC until the specified UTC date/time) is different from the date format in the Keystone "token" element you gave as an example. Therefore, *some conversion is required*. I would rather NOT do such custom conversion in the PDP, to keep the GE as generic as possible.

2.       *OAuth token ID*. Retrieved from the standard "jti" claim of the OAuth token (JWT): http://self-issued.info/docs/draft-ietf-oauth-json-web-token.html#jtiDef.

3.       *User id*: User's GCPID, as registered in the GCP (IdM GE), retrieved from the OAuth token (JWT) claim "http://gcp.telekom.de/axschema/gcpid".

4.       *User name*: you can define this attribute in the GCP or you can use a default one defined for all GCP users, such as the email, it's up to you. Then it can be retrieved by the PDP from the Oauth token (JWT).

5.       *User organization/tenant*: I see in your Keystone example that you have a *tenantName and tenantId. Do you need both actually?* In any case, you have to define a custom attribute in the IdM GE for each, and for the attribute value, you can reuse the ${MANDANT_ID} (resp. ${MANDANT_NAME}) natively defined in the GCP for tenantId (resp. tenantName).  The PDP will get it from the Oauth token. I have not tried ${MANDANT_NAME} in my tests and I am unable to test at the moment (the GCP site is on maintenance :( ), so I cannot guarantee this work. You may ask the IdM GE owner (Wolfgang). The alternative is always to set the literal value yourself.

6.       *User role*: you can define this attribute in the GCP. In this case, as I recall from a previous conf call, you expressed the possibility that this attribute may be changed (multiple times?) during the lifetime of the OAuth token. Therefore, getting it from the OAuth token is not enough. So, for that attribute, the PDP will request the GCP API to get the new value, for each of your proxy's XACML request where the matched policy requires that attribute.

You can't fail to notice that for all attributes, except the user role, you can get them in your proxy from the Oauth token, instead of having the PDP return it, just a suggestion.

In the PDP XACML response, attributes will be returned in <AttributeAssignment>s of <Obligation>s (see XACML 2.0 spec).
Example :

<?xml version="1.0" encoding="UTF-8"?>
<Response xmlns="urn:oasis:names:tc:xacml:2.0:context:schema:os" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:oasis:names:tc:xacml:2.0:context:schema:os access_control-xacml-2.0-context-schema-os.xsd">
    <Result>
        <Decision>Permit</Decision>
        <Status>
            <StatusCode Value="urn:oasis:names:tc:xacml:1.0:status:ok"/>
        </Status>
        <Obligations xmlns="urn:oasis:names:tc:xacml:2.0:policy:schema:os">
            <Obligation ObligationId="urn:thalesgroup:xacml:obligation:forward" FulfillOn="Permit">
                <AttributeAssignment
                    AttributeId="urn:oasis:names:tc:xacml:2.0:subject:role"
                    DataType="http://www.w3.org/2001/XMLSchema#string">Member</AttributeAssignment>
                <AttributeAssignment AttributeId="some:other:attribute"
                    DataType="http://www.w3.org/2001/XMLSchema#string">somevalue</AttributeAssignment>
            </Obligation>
        </Obligations>
    </Result>
</Response>


Regards,
CD

De : fiware-api-cross-bounces at lists.fi-ware.eu [mailto:fiware-api-cross-bounces at lists.fi-ware.eu] De la part de javier cerviño
Envoyé : mardi 21 mai 2013 18:50
À : Fiware-api-cross at lists.fi-ware.eu
Objet : [Fiware-api-cross] Attributes and response needed by the Proxy

Dear all,

For the development of the proxy we need a set of attributes that have to be returned by the PDP in the request for token validation. These attributes should be stored by the IdM and be returned by the PDP, and they will be forwarded to the GEs.
Here I send you an example of response from the Proxy to the GEs with these attributes:



{

    "access":{

        "token":{

            "expires":"2012-02-05T00:00:00",

            "id":"887665443383838",

            "tenant":{

                "id":"1",

                "name":"customer-x"

            }

        },

        "user":{

            "name":"joeuser",

            "tenantName":"customer-x",

            "id":"1",

            "roles":[

                {

                    "serviceId":"1",

                    "id":"3",

                    "name":"Member"

                }

            ],

            "tenantId":"1"

        }

    }

}

Of course, this information should be provided also by the PDP but in a format compatible with the PDP API. These attributes include information about the auth token (expiration date, id, and organization to which it is related), the user (name and id), the organization (tenant) in which the user is authenticated, and the roles the user plays within the organization. At UPM we believe that user, organization and roles can be attributes that may be previously stored in the IdM, and that they can be returned during the auth token request between the Proxy and the PDP.

The question is whether you also believe these attributes can be defined at the IdM and be returned by the PDP and why. I would also like to see an example of PDP response where we could see these attributes.

Thanks!

Best regards,
Javier Cerviño.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/fiware-api-cross/attachments/20130522/5662a6b1/attachment.html>