FIX Use trustee instead of trustor to validate trust token

[dmoranj]

Fixes #250

[AlvaroVega]

It seems to me that not only change trustor by trustee user is enough to fix the bug, since extract roles now does not extract nothing, since trust behavior is not like assignment role behavior

time=2015-06-24T10:56:37.263Z | lvl=DEBUG | corr=2a2b2abc-82c8-4615-8cec-1eed99cac18e | trans=2a2b2abc-82c8-4615-8cec-1eed99cac18e | op=/v1/contextEntities?details=on&limit=15&offset=0 | msg=Extracting roles for token: {"url":"http://localhost:5000/v3/role_assignments","method":"GET","qs":{"user.id":"66d8ab78b5754a78a96cc08ce35df809","effective":true},"headers":{"X-Auth-Token":"74ad28e1cd6b4ed5b57bb87258fa2cfd"}}
time=2015-06-24T10:56:37.284Z | lvl=DEBUG | corr=2a2b2abc-82c8-4615-8cec-1eed99cac18e | trans=2a2b2abc-82c8-4615-8cec-1eed99cac18e | op=/v1/contextEntities?details=on&limit=15&offset=0 | msg=Keystone response retrieving roles:

 "{\"role_assignments\": [], \"links\": {\"self\": \"http://localhost:5000/v3/role_assignments?user.id=66d8ab78b5754a78a96cc08ce35df809&effective=true\", \"previous\": null, \"next\": null}}"
time=2015-06-24T10:56:37.284Z | lvl=DEBUG | corr=2a2b2abc-82c8-4615-8cec-1eed99cac18e | trans=2a2b2abc-82c8-4615-8cec-1eed99cac18e | op=/v1/contextEntities?details=on&limit=15&offset=0 | msg=Roles response from Keystone: 
"{\"role_assignments\": [], \"links\": {\"self\": \"http://localhost:5000/v3/role_assignments?user.id=66d8ab78b5754a78a96cc08ce35df809&effective=true\", \"previous\": null, \"next\": null}}"


time=2015-06-24T10:56:37.285Z | lvl=DEBUG | corr=2a2b2abc-82c8-4615-8cec-1eed99cac18e | trans=2a2b2abc-82c8-4615-8cec-1eed99cac18e | op=/v1/contextEntities?details=on&limit=15&offset=0 | msg=Getting roles from response for service [1ec9ddc2fed54509be7ba60e4312cbb2] and subservice [87b6772af18c4947a102784372a8037b]
time=2015-06-24T10:56:37.285Z | lvl=DEBUG | corr=2a2b2abc-82c8-4615-8cec-1eed99cac18e | trans=2a2b2abc-82c8-4615-8cec-1eed99cac18e | op=/v1/contextEntities?details=on&limit=15&offset=0 | msg=Extracted roles: 
[]

time=2015-06-24T10:56:37.285Z | lvl=DEBUG | corr=2a2b2abc-82c8-4615-8cec-1eed99cac18e | trans=2a2b2abc-82c8-4615-8cec-1eed99cac18e | op=/v1/contextEntities?details=on&limit=15&offset=0 | msg=Roles not found for subservice /Basuras
time=2015-06-24T10:56:37.287Z | lvl=DEBUG | corr=2a2b2abc-82c8-4615-8cec-1eed99cac18e | trans=2a2b2abc-82c8-4615-8cec-1eed99cac18e | op=/v1/contextEntities?details=on&limit=15&offset=0 | msg=response-time: 133 statusCode: 401

[AlvaroVega]

the role to be checked is already into trust, you may be it's already extracted

In this case

{"token":{"OS-TRUST:trust":{"impersonation":false,"trustee_user":{"id":"66d8ab78b5754a78a96cc08ce35df809"},"id":"7f65b4d03b3a4f2985247ed5172c4cb0","trustor_user":{"id":"30234dbf712644838bbd7202ad54405a"}},"methods":["password"],"roles":[{"id":"3c7e51da93dc484596c7f396f4a2d315","name":"1ec9ddc2fed54509be7ba60e4312cbb2#SubServiceAdmin"}],"expires_at":"2015-06-24T11:17:42.499796Z","project":{"domain":{"id":"1ec9ddc2fed54509be7ba60e4312cbb2","name":"smartcity"},"id":"87b6772af18c4947a102784372a8037b","name":"/Basuras"}

role is 3c7e51da93dc484596c7f396f4a2d315

[dmoranj]

The problem is not whether I need it or not but whether the current extraction mechanism will work when applied to trust tokens. If it works like that, we can use it as it is and change it in the future if we have a good reason to do it. If we do not, better to use the same mechanism for both systems.

[AlvaroVega]

IMHO current role extraction mechanism could not be applied to trust tokens.

[dmoranj]

Fixed in e34257f

[AlvaroVega]

It seems that works fine, allowing when is possible and denning when not. But if I wait 1 minute an retry the same op the result is different:

This is OK

curl -X GET  "http://127.0.0.1:1026/v1/contextEntities?details=on&limit=15&offset=0" -i -H "Accept: application/json"   -H "Fiware-Service: smartcity"   -H "Fiware-ServicePath: /electricidad" -H "X-Auth-Token: 11b02d151d254778bc619937c737ee02"
HTTP/1.1 401 Unauthorized
X-Powered-By: Express
Unica-Correlator: e978d77c-9f5c-457d-9f5b-ad3f0e8d9001
Content-Type: application/json; charset=utf-8
Content-Length: 124
ETag: "-1316527160"
Date: Fri, 03 Jul 2015 13:18:54 GMT
Connection: keep-alive

{
  "name": "ROLES_NOT_FOUND",
  "message": "No roles were found for the user token in the give subservice: /electricidad"
}

This is OK

[15:11][avega@rotary:~/tid/fiware/iotp-orchestrator/src/tests/api]
(task/log_format) curl -X GET  "http://127.0.0.1:1026/v1/contextEntities?details=on&limit=15&offset=0" -i -H "Accept: application/json"   -H "Fiware-Service: smartcity"   -H "Fiware-ServicePath: /basuras" -H "X-Auth-Token: 11b02d151d254778bc619937c737ee02"
HTTP/1.1 200 OK
X-Powered-By: Express
Unica-Correlator: 7a1ead33-cb18-4183-a70f-eebb1f020353
connection: close
content-length: 94
content-type: application/json
date: Fri, 03 Jul 2015 13:11:27 GMT

{
  "errorCode" : {
    "code" : "404",
    "reasonPhrase" : "No context element found"
  }
}

This is NO OK.

[15:11][avega@rotary:~/tid/fiware/iotp-orchestrator/src/tests/api]
(task/log_format) curl -X GET  "http://127.0.0.1:1026/v1/contextEntities?details=on&limit=15&offset=0" -i -H "Accept: application/json"   -H "Fiware-Service: smartcity"   -H "Fiware-ServicePath: /basuras" -H "X-Auth-Token: 11b02d151d254778bc619937c737ee02"
HTTP/1.1 401 Unauthorized
X-Powered-By: Express
Unica-Correlator: ac5a32d7-58da-4759-b26f-1f8dd6d16d84
Content-Type: application/json; charset=utf-8
Content-Length: 119
ETag: "-915272462"
Date: Fri, 03 Jul 2015 13:12:42 GMT
Connection: keep-alive

{
  "name": "ROLES_NOT_FOUND",
  "message": "No roles were found for the user token in the give subservice: /basuras"
}

Maybe a cache issue?

[dmoranj]

Sure, it seems to be. I'll check it and fix it monday morning.
El 03/07/2015 15:17, "Alvaro Vega" [email protected] escribió:

It seems that works fine, allowing when is possible and denning when not.
But if I wait 1 minute an retry the same op the result is different:

[15:11]avega@rotary:~/tid/fiware/iotp-orchestrator/src/tests/api curl -X GET "http://127.0.0.1:1026/v1/contextEntities?details=on&limit=15&offset=0" -i -H "Accept: application/json" -H "Fiware-Service: smartcity" -H "Fiware-ServicePath: /basuras" -H "X-Auth-Token: 11b02d151d254778bc619937c737ee02"
HTTP/1.1 200 OK
X-Powered-By: Express
Unica-Correlator: 7a1ead33-cb18-4183-a70f-eebb1f020353
connection: close
content-length: 94
content-type: application/json
date: Fri, 03 Jul 2015 13:11:27 GMT

{
"errorCode" : {
"code" : "404",
"reasonPhrase" : "No context element found"
}
}
[15:11]avega@rotary:~/tid/fiware/iotp-orchestrator/src/tests/api curl -X GET "http://127.0.0.1:1026/v1/contextEntities?details=on&limit=15&offset=0" -i -H "Accept: application/json" -H "Fiware-Service: smartcity" -H "Fiware-ServicePath: /basuras" -H "X-Auth-Token: 11b02d151d254778bc619937c737ee02"
HTTP/1.1 401 Unauthorized
X-Powered-By: Express
Unica-Correlator: ac5a32d7-58da-4759-b26f-1f8dd6d16d84
Content-Type: application/json; charset=utf-8
Content-Length: 119
ETag: "-915272462"
Date: Fri, 03 Jul 2015 13:12:42 GMT
Connection: keep-alive

{
"name": "ROLES_NOT_FOUND",
"message": "No roles were found for the user token in the give subservice: /basuras"
}

Maybe a cache issue?

—
Reply to this email directly or view it on GitHub
#251 (comment)
.

[fgalan]

Be careful... this PR probably has been auto-closed when develop was removed, but it may have valuable commits. The solution is to merge develop into bug/trustTokenUsingTrustor and re-launch the PR againts master (a link to the old PR is usually a good idea, to review the comments there).