We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
According with this line https://github.com/telefonicaid/fiware-pep-steelskin/blob/master/lib/services/keystoneAuth.js#L233
pep is using trustor_user instead of trustee_user to validate an user when a trust token is provided.
According with Keystone Trust extension doc: http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3-os-trust-ext.html rustor_user_id (string)
Represents the user who created the trust, and who’s authorization is being delegated.
trustee_user_id (string)
Represents the user who is capable of consuming the trust.
Pep log:
time=2015-06-24T10:22:07.623Z | lvl=DEBUG | corr=72dab139-e973-4305-b827-fc4c6bd68b9e | trans=72dab139-e973-4305-b827-fc4c6bd68b9e | op=/v1/contextEntities?details=on&limit=15&offset=0 | msg=Retrieving user from keystone: {"url":"http://localhost:5000/v3/auth/tokens","method":"GET","json":{},"headers":{"X-Auth-Token":"9ed86564e45a432b970989d2cfa98d2d","X-Subject-Token":"9c92bfd42b0141caa84dc7b52a06eb22"}} time=2015-06-24T10:22:07.639Z | lvl=DEBUG | corr=72dab139-e973-4305-b827-fc4c6bd68b9e | trans=72dab139-e973-4305-b827-fc4c6bd68b9e | op=/v1/contextEntities?details=on&limit=15&offset=0 | msg=Keystone response retrieving user: time=2015-06-24T10:22:07.639Z | lvl=DEBUG | corr=72dab139-e973-4305-b827-fc4c6bd68b9e | trans=72dab139-e973-4305-b827-fc4c6bd68b9e | op=/v1/contextEntities?details=on&limit=15&offset=0 | msg=Keystone response retrieving user: {"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"},"catalog":[],"extras":{},"user":{"domain":{"id":"default","name":"Default"},"id":"66d8ab78b5754a78a96cc08ce35df809","name":"iotagent"},"audit_ids":["rXSL0gCZQmCXoOSfPWOwPA"],"issued_at":"2015-06-24T10:17:42.499823Z"}}
trustee is 66d8ab78b5754a78a96cc08ce35df809 trustor is 30234dbf712644838bbd7202ad54405a but
time=2015-06-24T10:22:07.653Z | lvl=DEBUG | corr=72dab139-e973-4305-b827-fc4c6bd68b9e | trans=72dab139-e973-4305-b827-fc4c6bd68b9e | 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":"30234dbf712644838bbd7202ad54405a","effective":true},"headers":{"X-Auth-Token":"9ed86564e45a432b970989d2cfa98d2d"}}
used user to extract roles is 30234dbf712644838bbd7202ad54405a -> trustor
The text was updated successfully, but these errors were encountered:
Fixed by PR #251 ?
Sorry, something went wrong.
Looking PR #251 with care, it seems it wasn't actually meged, but auto-closed...
reopen
No branches or pull requests
According with this line
https://github.com/telefonicaid/fiware-pep-steelskin/blob/master/lib/services/keystoneAuth.js#L233
pep is using trustor_user instead of trustee_user to validate an user when a trust token is provided.
According with Keystone Trust extension doc:
http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3-os-trust-ext.html
rustor_user_id (string)
Represents the user who created the trust, and who’s authorization is being delegated.
trustee_user_id (string)
Represents the user who is capable of consuming the trust.
Pep log:
trustee is 66d8ab78b5754a78a96cc08ce35df809
trustor is 30234dbf712644838bbd7202ad54405a
but
used user to extract roles is 30234dbf712644838bbd7202ad54405a -> trustor
The text was updated successfully, but these errors were encountered: