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

[javier cerviño]

Hi Cyril,

I agree with you that some of these attributes can be included into the
JSON Web Token.

The main problem here is that in Keystone all tokens are related to only
one tenant (organization). The user can be registered in more than one
tenant (in the IdM), but he has to choose one tenant to work. And the token
is related to that tenant.

AFAIK, the best solution to this problem would be the use of OAuth scopes.
These scopes are sent during OAuth authentication, but, basing on GCP API
documentation (from DT) the scope has to be an AppID (page 97 of such
document). Does anybody know if we can use that OAuth scope to provide the
tenant id instead of the AppID? Doing so the solution seems fully
compatible with Keystone and OpenStack.

Cheers,
Javier.


On 22 May 2013 16:03, DANGERVILLE Cyril
<cyril.dangerville at thalesgroup.com>wrote:

> 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 L ), 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/20130528/bae0a26f/attachment.html>