)]}'
{"specs/keystone/ocata/standalone-trusts.rst":[{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"4165e0443ba624a5908a1e2e6482de05131b98b1","unresolved":false,"context_lines":[{"line_number":37,"context_line":"  user account to use as a trustee user."},{"line_number":38,"context_line":""},{"line_number":39,"context_line":"* In a scenario where trust credentials need to be passed into an instance, the"},{"line_number":40,"context_line":"  services creating trusts for this purpose need to create a dedicated trustee"},{"line_number":41,"context_line":"  user, which requires passing three separate pieces of data (user name,"},{"line_number":42,"context_line":"  password and trust ID) to the entity using them, where one (an API key) would"},{"line_number":43,"context_line":"  suffice with standalone trusts in place. Once the trust is no longer needed,"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7a77a97e_737b8528","line":40,"updated":"2016-11-18 02:35:32.000000000","message":"If a service needs to create a trusts, or a standalone trust, doesn\u0027t it need the user\u0027s credentials regardless? Or are we expecting the user to create the standalone trust beforehand and pass the API key to the service?","commit_id":"a71901899d32377f46297d5816f1e335343032b6"},{"author":{"_account_id":12542,"name":"Johannes Grassler","email":"jgr-launchpad@btw23.de","username":"jgrassler"},"change_message_id":"b41d4a3a294507aca0cab22942a23477aa98d3e2","unresolved":false,"context_lines":[{"line_number":37,"context_line":"  user account to use as a trustee user."},{"line_number":38,"context_line":""},{"line_number":39,"context_line":"* In a scenario where trust credentials need to be passed into an instance, the"},{"line_number":40,"context_line":"  services creating trusts for this purpose need to create a dedicated trustee"},{"line_number":41,"context_line":"  user, which requires passing three separate pieces of data (user name,"},{"line_number":42,"context_line":"  password and trust ID) to the entity using them, where one (an API key) would"},{"line_number":43,"context_line":"  suffice with standalone trusts in place. Once the trust is no longer needed,"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7a77a97e_6b9e1eba","line":40,"in_reply_to":"7a77a97e_737b8528","updated":"2016-11-18 12:30:52.000000000","message":"The trustor user\u0027s credentials are always needed, yes. What this spec proposes to do away with is the trustee user.\n\nTrust creation will use the same credentials it is currently using: the service has access to the trustor user\u0027s authenticated keystone session and uses that to create a trust (that is the current practice everywhere trusts are created). The difference introduced by standalone trusts is that the trust is not delegated to the service user or a dedicated trustee user but stands on its own and can be consumed solely through its API key.","commit_id":"a71901899d32377f46297d5816f1e335343032b6"},{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"4165e0443ba624a5908a1e2e6482de05131b98b1","unresolved":false,"context_lines":[{"line_number":90,"context_line":"---------------------"},{"line_number":91,"context_line":""},{"line_number":92,"context_line":"python-keystoneclient and python-openstackclient will need to allow trust"},{"line_number":93,"context_line":"creation without specifying trustee user."},{"line_number":94,"context_line":""},{"line_number":95,"context_line":"Performance Impact"},{"line_number":96,"context_line":"------------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7a77a97e_b38b5d67","line":93,"updated":"2016-11-18 02:35:32.000000000","message":"This sounds like an additional work item.","commit_id":"a71901899d32377f46297d5816f1e335343032b6"},{"author":{"_account_id":12542,"name":"Johannes Grassler","email":"jgr-launchpad@btw23.de","username":"jgrassler"},"change_message_id":"b41d4a3a294507aca0cab22942a23477aa98d3e2","unresolved":false,"context_lines":[{"line_number":90,"context_line":"---------------------"},{"line_number":91,"context_line":""},{"line_number":92,"context_line":"python-keystoneclient and python-openstackclient will need to allow trust"},{"line_number":93,"context_line":"creation without specifying trustee user."},{"line_number":94,"context_line":""},{"line_number":95,"context_line":"Performance Impact"},{"line_number":96,"context_line":"------------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7a77a97e_2be7c640","line":93,"in_reply_to":"7a77a97e_b38b5d67","updated":"2016-11-18 12:30:52.000000000","message":"It already is a work item. I just figured it might be appropriate to mention it here as well to clarify that somebody intending to use this feature needs to ensure they have sufficiently recent clients (not an issue for services, usually, but end users may have older clients installed). I clarified that section now.","commit_id":"a71901899d32377f46297d5816f1e335343032b6"},{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"4165e0443ba624a5908a1e2e6482de05131b98b1","unresolved":false,"context_lines":[{"line_number":96,"context_line":"------------------"},{"line_number":97,"context_line":""},{"line_number":98,"context_line":"Keystone needs to be able to look up a trust from the database by API key, so"},{"line_number":99,"context_line":"the column holding a trust\u0027s API key should be a primary key for the table."},{"line_number":100,"context_line":""},{"line_number":101,"context_line":"Other Deployer Impact"},{"line_number":102,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7a77a97e_936ae17f","line":99,"updated":"2016-11-18 02:35:32.000000000","message":"So, will the API key be another attribute of a trust? If so, thinking about the described use case, would that make trustee and api key mutually exclusive?","commit_id":"a71901899d32377f46297d5816f1e335343032b6"},{"author":{"_account_id":12542,"name":"Johannes Grassler","email":"jgr-launchpad@btw23.de","username":"jgrassler"},"change_message_id":"b41d4a3a294507aca0cab22942a23477aa98d3e2","unresolved":false,"context_lines":[{"line_number":96,"context_line":"------------------"},{"line_number":97,"context_line":""},{"line_number":98,"context_line":"Keystone needs to be able to look up a trust from the database by API key, so"},{"line_number":99,"context_line":"the column holding a trust\u0027s API key should be a primary key for the table."},{"line_number":100,"context_line":""},{"line_number":101,"context_line":"Other Deployer Impact"},{"line_number":102,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7a77a97e_ae568403","line":99,"in_reply_to":"7a77a97e_936ae17f","updated":"2016-11-18 12:30:52.000000000","message":"Yes, they are mutually exclusive. That is guaranteed by an implementation detail I hinted at but didn\u0027t spell out explicitely: standalone trusts (and with that API keys) are created when a trust is created without specifying a trustee user. I rectified this omission now. See \"Changes to Trust Creation API\" under \"Proposed Changes\" for details.","commit_id":"a71901899d32377f46297d5816f1e335343032b6"},{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"4165e0443ba624a5908a1e2e6482de05131b98b1","unresolved":false,"context_lines":[{"line_number":101,"context_line":"Other Deployer Impact"},{"line_number":102,"context_line":"---------------------"},{"line_number":103,"context_line":""},{"line_number":104,"context_line":"This feature will be configurable through the setting `trust/standalone_trusts`"},{"line_number":105,"context_line":"which will be `True` by default. The rationale behind this is giving as many"},{"line_number":106,"context_line":"users as possible the option to use lightweight trusts (thus keeping them from"},{"line_number":107,"context_line":"picking the worse option of providing their login credentials to applications"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7a77a97e_130df1e7","line":104,"updated":"2016-11-18 02:35:32.000000000","message":"I assume this would be a configuration option? \n\n  ``keystone.conf [trusts] standalone_trusts \u003d True``","commit_id":"a71901899d32377f46297d5816f1e335343032b6"},{"author":{"_account_id":12542,"name":"Johannes Grassler","email":"jgr-launchpad@btw23.de","username":"jgrassler"},"change_message_id":"b41d4a3a294507aca0cab22942a23477aa98d3e2","unresolved":false,"context_lines":[{"line_number":101,"context_line":"Other Deployer Impact"},{"line_number":102,"context_line":"---------------------"},{"line_number":103,"context_line":""},{"line_number":104,"context_line":"This feature will be configurable through the setting `trust/standalone_trusts`"},{"line_number":105,"context_line":"which will be `True` by default. The rationale behind this is giving as many"},{"line_number":106,"context_line":"users as possible the option to use lightweight trusts (thus keeping them from"},{"line_number":107,"context_line":"picking the worse option of providing their login credentials to applications"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7a77a97e_4b67a2b6","line":104,"in_reply_to":"7a77a97e_130df1e7","updated":"2016-11-18 12:30:52.000000000","message":"Ah, so that\u0027s the proper markup for configuration options. Thanks! Fixed.","commit_id":"a71901899d32377f46297d5816f1e335343032b6"},{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"4165e0443ba624a5908a1e2e6482de05131b98b1","unresolved":false,"context_lines":[{"line_number":106,"context_line":"users as possible the option to use lightweight trusts (thus keeping them from"},{"line_number":107,"context_line":"picking the worse option of providing their login credentials to applications"},{"line_number":108,"context_line":"and automation tools) while still allowing operators to prohibit the use of"},{"line_number":109,"context_line":"API keys."},{"line_number":110,"context_line":""},{"line_number":111,"context_line":"Developer Impact"},{"line_number":112,"context_line":"----------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7a77a97e_f33235a6","line":109,"updated":"2016-11-18 02:35:32.000000000","message":"If something like this was added - would there be any use case to *not* enable it from an operator-perspective?","commit_id":"a71901899d32377f46297d5816f1e335343032b6"},{"author":{"_account_id":12542,"name":"Johannes Grassler","email":"jgr-launchpad@btw23.de","username":"jgrassler"},"change_message_id":"c66ac4c8782ae55580ec2804f7a345bb30c9853f","unresolved":false,"context_lines":[{"line_number":106,"context_line":"users as possible the option to use lightweight trusts (thus keeping them from"},{"line_number":107,"context_line":"picking the worse option of providing their login credentials to applications"},{"line_number":108,"context_line":"and automation tools) while still allowing operators to prohibit the use of"},{"line_number":109,"context_line":"API keys."},{"line_number":110,"context_line":""},{"line_number":111,"context_line":"Developer Impact"},{"line_number":112,"context_line":"----------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7a77a97e_018b541f","line":109,"in_reply_to":"7a77a97e_349c2c69","updated":"2016-11-22 10:55:48.000000000","message":"Yeah...so if we both have that \"a bit off\" gut feeling, it is probably better to have a dedicated API rather than mess around with empty user IDs. Let\u0027s bury that idea and come up with a dedicated API :-)","commit_id":"a71901899d32377f46297d5816f1e335343032b6"},{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"e1fe80a38fe0a57964e1c60f138826d22679978b","unresolved":false,"context_lines":[{"line_number":106,"context_line":"users as possible the option to use lightweight trusts (thus keeping them from"},{"line_number":107,"context_line":"picking the worse option of providing their login credentials to applications"},{"line_number":108,"context_line":"and automation tools) while still allowing operators to prohibit the use of"},{"line_number":109,"context_line":"API keys."},{"line_number":110,"context_line":""},{"line_number":111,"context_line":"Developer Impact"},{"line_number":112,"context_line":"----------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7a77a97e_349c2c69","line":109,"in_reply_to":"7a77a97e_4e2fb087","updated":"2016-11-21 21:30:11.000000000","message":"Hmmm - interesting. As far as an API goes for consuming a stand-alone trust from a third party service, I would opt for a clean and simple API versus setting user id to none and the API key as the password. I think API keys are a pretty well-known concept but passing them around in that way does feel a bit off.","commit_id":"a71901899d32377f46297d5816f1e335343032b6"},{"author":{"_account_id":12542,"name":"Johannes Grassler","email":"jgr-launchpad@btw23.de","username":"jgrassler"},"change_message_id":"b41d4a3a294507aca0cab22942a23477aa98d3e2","unresolved":false,"context_lines":[{"line_number":106,"context_line":"users as possible the option to use lightweight trusts (thus keeping them from"},{"line_number":107,"context_line":"picking the worse option of providing their login credentials to applications"},{"line_number":108,"context_line":"and automation tools) while still allowing operators to prohibit the use of"},{"line_number":109,"context_line":"API keys."},{"line_number":110,"context_line":""},{"line_number":111,"context_line":"Developer Impact"},{"line_number":112,"context_line":"----------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7a77a97e_4e2fb087","line":109,"in_reply_to":"7a77a97e_f33235a6","updated":"2016-11-18 12:30:52.000000000","message":"Yes, there is. Some operators might make a policy decision to prohibit delegation without a trustee user for auditability reasons. After all an operator can chew out both the person who broke something and the person who let them do it if a trustee user is required. With the trustee user out of the equation they can only chew out the latter.\n\nIf OAUTH ends up being used for trust consumption this configuration setting would not be strictly neccessary (rationale: if somebody makes this sort of policy decision they are likely to turn of OAUTH anyway and this disables standalone trusts as a side effect).\n\nI\u0027m not really sure I like using OAUTH for trust consumption that much, though. One of the use cases I see for this is delegating access to third-party (i.e. non-OpenStack) software which may only implement regular password authentication. For this reason I\u0027m still toying with the idea of abusing password authentication for consuming stand alone trusts (i.e. something like an empty user name and the API key being sent as password). I realize this is a bit of a hack though, so feel free to shoot it down right away if it\u0027s a big no-no.","commit_id":"a71901899d32377f46297d5816f1e335343032b6"},{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"fadeaf3c65d7b7eebc00416a37aaa3d052522c0d","unresolved":false,"context_lines":[{"line_number":13,"context_line":"The existing trusts implementation requires a *Trustee user* that a trust is"},{"line_number":14,"context_line":"assigned to. This effectively limits the use of a trust to service users who"},{"line_number":15,"context_line":"have access to both the regular user\u0027s account through the keystone token used"},{"line_number":16,"context_line":"to authenticate against the service and an acocunt they control themselves (a"},{"line_number":17,"context_line":"service account or a dedicated trustee account specifically created for the"},{"line_number":18,"context_line":"purpose). Optionally allowing an API key rather than a trustee user to consume"},{"line_number":19,"context_line":"a trust would enable users to create trusts on their own and generally reduce"}],"source_content_type":"text/x-rst","patch_set":3,"id":"7a77a97e_9498a06c","line":16,"updated":"2016-11-21 21:54:32.000000000","message":"nit: account*","commit_id":"7ad0e1a7ab12ff44b945604e317556169580af4c"},{"author":{"_account_id":12542,"name":"Johannes Grassler","email":"jgr-launchpad@btw23.de","username":"jgrassler"},"change_message_id":"f993f32b617845743091966a1f53adbe86cd35d2","unresolved":false,"context_lines":[{"line_number":13,"context_line":"The existing trusts implementation requires a *Trustee user* that a trust is"},{"line_number":14,"context_line":"assigned to. This effectively limits the use of a trust to service users who"},{"line_number":15,"context_line":"have access to both the regular user\u0027s account through the keystone token used"},{"line_number":16,"context_line":"to authenticate against the service and an acocunt they control themselves (a"},{"line_number":17,"context_line":"service account or a dedicated trustee account specifically created for the"},{"line_number":18,"context_line":"purpose). Optionally allowing an API key rather than a trustee user to consume"},{"line_number":19,"context_line":"a trust would enable users to create trusts on their own and generally reduce"}],"source_content_type":"text/x-rst","patch_set":3,"id":"7a77a97e_990b627d","line":16,"in_reply_to":"7a77a97e_9498a06c","updated":"2016-11-22 10:55:30.000000000","message":"Done","commit_id":"7ad0e1a7ab12ff44b945604e317556169580af4c"},{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"fadeaf3c65d7b7eebc00416a37aaa3d052522c0d","unresolved":false,"context_lines":[{"line_number":34,"context_line":"  while a trust could still be revoked if the breach is discovered, allowing"},{"line_number":35,"context_line":"  for a measure of damage control. Currently a user cannot create such a trust"},{"line_number":36,"context_line":"  because that user would have to create or at least have access to a second"},{"line_number":37,"context_line":"  user account to use as a trustee user."},{"line_number":38,"context_line":""},{"line_number":39,"context_line":"* In a scenario where trust credentials need to be passed into an instance, the"},{"line_number":40,"context_line":"  services creating trusts for this purpose need to create a dedicated trustee"}],"source_content_type":"text/x-rst","patch_set":3,"id":"7a77a97e_54628817","line":37,"updated":"2016-11-21 21:54:32.000000000","message":"Well - a user (who I assume is the trustor in this example) does have the ability to make this work by creating a trust between themselves and a service user (which is the user account your referencing here, right?). In that case, the trustor\u0027s credentials should never be on the third-party system. All the third-party system would need would be the trust_id, the service user id, and the service user password, right?\n\nYou\u0027re saying that you don\u0027t want the hassle of dealing with a service user, you just want to be able to give a *thing* a trust id (or API key) that doesn\u0027t need a service user id or password to be able to get a scoped token.","commit_id":"7ad0e1a7ab12ff44b945604e317556169580af4c"},{"author":{"_account_id":12542,"name":"Johannes Grassler","email":"jgr-launchpad@btw23.de","username":"jgrassler"},"change_message_id":"f993f32b617845743091966a1f53adbe86cd35d2","unresolved":false,"context_lines":[{"line_number":34,"context_line":"  while a trust could still be revoked if the breach is discovered, allowing"},{"line_number":35,"context_line":"  for a measure of damage control. Currently a user cannot create such a trust"},{"line_number":36,"context_line":"  because that user would have to create or at least have access to a second"},{"line_number":37,"context_line":"  user account to use as a trustee user."},{"line_number":38,"context_line":""},{"line_number":39,"context_line":"* In a scenario where trust credentials need to be passed into an instance, the"},{"line_number":40,"context_line":"  services creating trusts for this purpose need to create a dedicated trustee"}],"source_content_type":"text/x-rst","patch_set":3,"id":"7a77a97e_74304b9f","line":37,"in_reply_to":"7a77a97e_54628817","updated":"2016-11-22 10:55:30.000000000","message":"\u003e Well - a user (who I assume is the trustor in this example) does have the\n\u003e ability to make this work by creating a trust between themselves and a\n\u003e service user (which is the user account your referencing here, right?).\n\nNo, \"user account\" is the trustor\u0027s user account. And with a service user in\nthe equation this works as outlined, yes. I\u0027m thinking of scenarios where there\nis no service user to delegate a trust to. Example: an unprivileged user (who\ncannot create a dedicated service account) writes a statistics gathering script\nthat runs on a remote machine and stores their credentials on there. Very ugly,\nbut lots of people are certain to do it anyway. With a standalone trust the\nusers doing this sort of thing can do it with all the restrictions a trust\nimplies.\n\n\u003e In that case, the trustor\u0027s credentials should never be on the third-party\n\u003e system. All the third-party system would need would be the trust_id, the\n\u003e service user id, and the service user password, right?\n\nYes. As long as there _is_ a service user - which an unprivileged user cannot\njust create.\n\n\u003e You\u0027re saying that you don\u0027t want the hassle of dealing with a service user,\n\u003e you just want to be able to give a *thing* a trust id (or API key) that\n\u003e doesn\u0027t need a service user id or password to be able to get a scoped token.\n\nExactly, yes. I\u0027d prefer a dedicated API key rather than the trust ID, because\nthat is a secret such as a password and can be treated as such (i.e. trust IDs\nmight get logged depending on log level to allow for auditability, but API keys\nwould never appear in logs under any circumstances).","commit_id":"7ad0e1a7ab12ff44b945604e317556169580af4c"},{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"fadeaf3c65d7b7eebc00416a37aaa3d052522c0d","unresolved":false,"context_lines":[{"line_number":36,"context_line":"  because that user would have to create or at least have access to a second"},{"line_number":37,"context_line":"  user account to use as a trustee user."},{"line_number":38,"context_line":""},{"line_number":39,"context_line":"* In a scenario where trust credentials need to be passed into an instance, the"},{"line_number":40,"context_line":"  services creating trusts for this purpose need to create a dedicated trustee"},{"line_number":41,"context_line":"  user, which requires passing three separate pieces of data (user name,"},{"line_number":42,"context_line":"  password and trust ID) to the entity using them, where one (an API key) would"}],"source_content_type":"text/x-rst","patch_set":3,"id":"7a77a97e_94118060","line":39,"updated":"2016-11-21 21:54:32.000000000","message":"In this example, who is the owner of the credentials? The trustor? The trustee?","commit_id":"7ad0e1a7ab12ff44b945604e317556169580af4c"},{"author":{"_account_id":12542,"name":"Johannes Grassler","email":"jgr-launchpad@btw23.de","username":"jgrassler"},"change_message_id":"f993f32b617845743091966a1f53adbe86cd35d2","unresolved":false,"context_lines":[{"line_number":36,"context_line":"  because that user would have to create or at least have access to a second"},{"line_number":37,"context_line":"  user account to use as a trustee user."},{"line_number":38,"context_line":""},{"line_number":39,"context_line":"* In a scenario where trust credentials need to be passed into an instance, the"},{"line_number":40,"context_line":"  services creating trusts for this purpose need to create a dedicated trustee"},{"line_number":41,"context_line":"  user, which requires passing three separate pieces of data (user name,"},{"line_number":42,"context_line":"  password and trust ID) to the entity using them, where one (an API key) would"}],"source_content_type":"text/x-rst","patch_set":3,"id":"7a77a97e_b4b823e7","line":39,"in_reply_to":"7a77a97e_94118060","updated":"2016-11-22 10:55:30.000000000","message":"\"credentials\" refers to the credentials required to consume the trusts, so the trustee owns them. I clarified this a little now.","commit_id":"7ad0e1a7ab12ff44b945604e317556169580af4c"},{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"fadeaf3c65d7b7eebc00416a37aaa3d052522c0d","unresolved":false,"context_lines":[{"line_number":48,"context_line":""},{"line_number":49,"context_line":"This change extends the trusts API by allowing trusts to be created without"},{"line_number":50,"context_line":"specifying a trustee. When a user creates such a trust they will receive an API"},{"line_number":51,"context_line":"key (generated by Keystone) that can then be used to acquire tokens scoped to"},{"line_number":52,"context_line":"the trust in question throughout the life time of the trust. The API key is"},{"line_number":53,"context_line":"sufficient to obtain the trust scoped token: the trust ID does not need to be"},{"line_number":54,"context_line":"supplied along with it."}],"source_content_type":"text/x-rst","patch_set":3,"id":"7a77a97e_af2465af","line":51,"updated":"2016-11-21 21:54:32.000000000","message":"nit: keystone* \n\nwe typically use lower case keystone when referencing the project name, and capitalize uses like OpenStack Identity.","commit_id":"7ad0e1a7ab12ff44b945604e317556169580af4c"},{"author":{"_account_id":12542,"name":"Johannes Grassler","email":"jgr-launchpad@btw23.de","username":"jgrassler"},"change_message_id":"f993f32b617845743091966a1f53adbe86cd35d2","unresolved":false,"context_lines":[{"line_number":48,"context_line":""},{"line_number":49,"context_line":"This change extends the trusts API by allowing trusts to be created without"},{"line_number":50,"context_line":"specifying a trustee. When a user creates such a trust they will receive an API"},{"line_number":51,"context_line":"key (generated by Keystone) that can then be used to acquire tokens scoped to"},{"line_number":52,"context_line":"the trust in question throughout the life time of the trust. The API key is"},{"line_number":53,"context_line":"sufficient to obtain the trust scoped token: the trust ID does not need to be"},{"line_number":54,"context_line":"supplied along with it."}],"source_content_type":"text/x-rst","patch_set":3,"id":"7a77a97e_d4cd9f87","line":51,"in_reply_to":"7a77a97e_af2465af","updated":"2016-11-22 10:55:30.000000000","message":"Done","commit_id":"7ad0e1a7ab12ff44b945604e317556169580af4c"},{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"fadeaf3c65d7b7eebc00416a37aaa3d052522c0d","unresolved":false,"context_lines":[{"line_number":51,"context_line":"key (generated by Keystone) that can then be used to acquire tokens scoped to"},{"line_number":52,"context_line":"the trust in question throughout the life time of the trust. The API key is"},{"line_number":53,"context_line":"sufficient to obtain the trust scoped token: the trust ID does not need to be"},{"line_number":54,"context_line":"supplied along with it."},{"line_number":55,"context_line":""},{"line_number":56,"context_line":"This change does explicitely not remove the ability to tie a trust to a trustee"},{"line_number":57,"context_line":"user, for this can be used to provide additional security in cases where such a"}],"source_content_type":"text/x-rst","patch_set":3,"id":"7a77a97e_4fcf51b3","line":54,"updated":"2016-11-21 21:54:32.000000000","message":"This must assume that all tokens obtained using a standalone trust are impersonated tokens of the trustor, right? With this, there shouldn\u0027t really be an option for impersonation, since the decision between trustee and trustor doesn\u0027t really exist.","commit_id":"7ad0e1a7ab12ff44b945604e317556169580af4c"},{"author":{"_account_id":12542,"name":"Johannes Grassler","email":"jgr-launchpad@btw23.de","username":"jgrassler"},"change_message_id":"f993f32b617845743091966a1f53adbe86cd35d2","unresolved":false,"context_lines":[{"line_number":51,"context_line":"key (generated by Keystone) that can then be used to acquire tokens scoped to"},{"line_number":52,"context_line":"the trust in question throughout the life time of the trust. The API key is"},{"line_number":53,"context_line":"sufficient to obtain the trust scoped token: the trust ID does not need to be"},{"line_number":54,"context_line":"supplied along with it."},{"line_number":55,"context_line":""},{"line_number":56,"context_line":"This change does explicitely not remove the ability to tie a trust to a trustee"},{"line_number":57,"context_line":"user, for this can be used to provide additional security in cases where such a"}],"source_content_type":"text/x-rst","patch_set":3,"id":"7a77a97e_fe2ef940","line":54,"in_reply_to":"7a77a97e_4fcf51b3","updated":"2016-11-22 10:55:30.000000000","message":"Yes, indeed. This only works with impersonation. Thanks for pointing out the \"obvious\" thing I forgot to mention :-)","commit_id":"7ad0e1a7ab12ff44b945604e317556169580af4c"},{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"fadeaf3c65d7b7eebc00416a37aaa3d052522c0d","unresolved":false,"context_lines":[{"line_number":73,"context_line":""},{"line_number":74,"context_line":"becomes optional. Omitting it tells Keystone to create a standalone trust. This"},{"line_number":75,"context_line":"will cause Keystone to create and record an API key for the trust. This API key"},{"line_number":76,"context_line":"can later be used to consume the trust."},{"line_number":77,"context_line":""},{"line_number":78,"context_line":"Alternatives"},{"line_number":79,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"7a77a97e_4f73d1b4","line":76,"updated":"2016-11-21 21:54:32.000000000","message":"Does this require a trust-\u003eproject relationship? As a user - is it possible for me to create a standalone trust, not scoped to a project, and give that API key to someone?","commit_id":"7ad0e1a7ab12ff44b945604e317556169580af4c"},{"author":{"_account_id":12542,"name":"Johannes Grassler","email":"jgr-launchpad@btw23.de","username":"jgrassler"},"change_message_id":"f993f32b617845743091966a1f53adbe86cd35d2","unresolved":false,"context_lines":[{"line_number":73,"context_line":""},{"line_number":74,"context_line":"becomes optional. Omitting it tells Keystone to create a standalone trust. This"},{"line_number":75,"context_line":"will cause Keystone to create and record an API key for the trust. This API key"},{"line_number":76,"context_line":"can later be used to consume the trust."},{"line_number":77,"context_line":""},{"line_number":78,"context_line":"Alternatives"},{"line_number":79,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"7a77a97e_9ec8a576","line":76,"in_reply_to":"7a77a97e_4f73d1b4","updated":"2016-11-22 10:55:30.000000000","message":"It continues to require a trust-\u003eproject relationship, yes. I mentioned that explicitly now.","commit_id":"7ad0e1a7ab12ff44b945604e317556169580af4c"},{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"fadeaf3c65d7b7eebc00416a37aaa3d052522c0d","unresolved":false,"context_lines":[{"line_number":83,"context_line":"Security Impact"},{"line_number":84,"context_line":"---------------"},{"line_number":85,"context_line":""},{"line_number":86,"context_line":"Once this feature (along with [0]) widely known and adopted, it will arguably"},{"line_number":87,"context_line":"improve security since users no longer need to use their login credentials to"},{"line_number":88,"context_line":"grant applications or automation tools access to their OpenStack account."},{"line_number":89,"context_line":"Instead they can provide these applications and automation tools with a trust"}],"source_content_type":"text/x-rst","patch_set":3,"id":"7a77a97e_6f788d90","line":86,"updated":"2016-11-21 21:54:32.000000000","message":"nit: are widely known*","commit_id":"7ad0e1a7ab12ff44b945604e317556169580af4c"},{"author":{"_account_id":12542,"name":"Johannes Grassler","email":"jgr-launchpad@btw23.de","username":"jgrassler"},"change_message_id":"f993f32b617845743091966a1f53adbe86cd35d2","unresolved":false,"context_lines":[{"line_number":83,"context_line":"Security Impact"},{"line_number":84,"context_line":"---------------"},{"line_number":85,"context_line":""},{"line_number":86,"context_line":"Once this feature (along with [0]) widely known and adopted, it will arguably"},{"line_number":87,"context_line":"improve security since users no longer need to use their login credentials to"},{"line_number":88,"context_line":"grant applications or automation tools access to their OpenStack account."},{"line_number":89,"context_line":"Instead they can provide these applications and automation tools with a trust"}],"source_content_type":"text/x-rst","patch_set":3,"id":"7a77a97e_3e9cf15c","line":86,"in_reply_to":"7a77a97e_6f788d90","updated":"2016-11-22 10:55:30.000000000","message":"Done","commit_id":"7ad0e1a7ab12ff44b945604e317556169580af4c"},{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"fadeaf3c65d7b7eebc00416a37aaa3d052522c0d","unresolved":false,"context_lines":[{"line_number":87,"context_line":"improve security since users no longer need to use their login credentials to"},{"line_number":88,"context_line":"grant applications or automation tools access to their OpenStack account."},{"line_number":89,"context_line":"Instead they can provide these applications and automation tools with a trust"},{"line_number":90,"context_line":"scoped API key. That being said, there are some security critical parts to"},{"line_number":91,"context_line":"this:"},{"line_number":92,"context_line":""},{"line_number":93,"context_line":"* First and formeost, this change adds a new way of acquiring a token scoped to"}],"source_content_type":"text/x-rst","patch_set":3,"id":"7a77a97e_ef649de6","line":90,"updated":"2016-11-21 21:54:32.000000000","message":"nit: with an API key that can be used to obtain trust scoped tokens.","commit_id":"7ad0e1a7ab12ff44b945604e317556169580af4c"},{"author":{"_account_id":12542,"name":"Johannes Grassler","email":"jgr-launchpad@btw23.de","username":"jgrassler"},"change_message_id":"f993f32b617845743091966a1f53adbe86cd35d2","unresolved":false,"context_lines":[{"line_number":87,"context_line":"improve security since users no longer need to use their login credentials to"},{"line_number":88,"context_line":"grant applications or automation tools access to their OpenStack account."},{"line_number":89,"context_line":"Instead they can provide these applications and automation tools with a trust"},{"line_number":90,"context_line":"scoped API key. That being said, there are some security critical parts to"},{"line_number":91,"context_line":"this:"},{"line_number":92,"context_line":""},{"line_number":93,"context_line":"* First and formeost, this change adds a new way of acquiring a token scoped to"}],"source_content_type":"text/x-rst","patch_set":3,"id":"7a77a97e_5ed1adfa","line":90,"in_reply_to":"7a77a97e_ef649de6","updated":"2016-11-22 10:55:30.000000000","message":"Done","commit_id":"7ad0e1a7ab12ff44b945604e317556169580af4c"},{"author":{"_account_id":18666,"name":"Chris Plock","email":"chrisplo@cisco.com","username":"plockc"},"change_message_id":"ce00d1fb966fd728d55bb724c1477cd4faf60cff","unresolved":false,"context_lines":[{"line_number":165,"context_line":"2. Implement support for creating a standalone trust in python-keystoneclient"},{"line_number":166,"context_line":"   and python-openstackclient."},{"line_number":167,"context_line":""},{"line_number":168,"context_line":"3. Implement an API key authentication method in keystone."},{"line_number":169,"context_line":""},{"line_number":170,"context_line":"Dependencies"},{"line_number":171,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":3,"id":"7a77a97e_a1c2fc82","line":168,"updated":"2016-11-18 21:38:58.000000000","message":"suggestions: API updates for listing trusts based on having a trustee or not, and by api key (since that should be unique), and ability to delete by api key","commit_id":"7ad0e1a7ab12ff44b945604e317556169580af4c"},{"author":{"_account_id":12542,"name":"Johannes Grassler","email":"jgr-launchpad@btw23.de","username":"jgrassler"},"change_message_id":"f993f32b617845743091966a1f53adbe86cd35d2","unresolved":false,"context_lines":[{"line_number":165,"context_line":"2. Implement support for creating a standalone trust in python-keystoneclient"},{"line_number":166,"context_line":"   and python-openstackclient."},{"line_number":167,"context_line":""},{"line_number":168,"context_line":"3. Implement an API key authentication method in keystone."},{"line_number":169,"context_line":""},{"line_number":170,"context_line":"Dependencies"},{"line_number":171,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":3,"id":"7a77a97e_1e62d8d8","line":168,"in_reply_to":"7a77a97e_a1c2fc82","updated":"2016-11-22 10:55:30.000000000","message":"Yeah...probably makes sense to make that a work item of its own. \n\nAlso, thanks for the \"listing trusts based on having a trustee or not\" suggestion! I didn\u0027t think of that.\n\nI\u0027m not entirely comfortable with listing by API key, though. While it needs to be unique, it _is_ a secret after all and I\u0027d prefer restricting its retrieval to an explicit GET on the trust in question or even only pass it to the user upon trust creation.","commit_id":"7ad0e1a7ab12ff44b945604e317556169580af4c"},{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"0f0ad949f7868b62ae1e6fce4c9c51fd82ed1741","unresolved":false,"context_lines":[{"line_number":76,"context_line":"becomes optional. Omitting it tells keystone to create a standalone trust. This"},{"line_number":77,"context_line":"will cause keystone to create and record an API key for the trust. This API key"},{"line_number":78,"context_line":"can later be used to consume the trust. Note that the trust continues to"},{"line_number":79,"context_line":"require a project and roles to be delegated."},{"line_number":80,"context_line":""},{"line_number":81,"context_line":"Alternatives"},{"line_number":82,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"7a77a97e_6a7054dd","line":79,"updated":"2016-11-22 15:10:18.000000000","message":"In the event an API key is compromised, we should detail the process for revocation. I assume we\u0027ll need some sort of `revoke_by_api_key()` available.","commit_id":"b36f065b04cd83059bfefa9cd3c3040d81b37d62"},{"author":{"_account_id":12542,"name":"Johannes Grassler","email":"jgr-launchpad@btw23.de","username":"jgrassler"},"change_message_id":"8665107d61abee03b38da5637215e8dddc646f8d","unresolved":false,"context_lines":[{"line_number":76,"context_line":"becomes optional. Omitting it tells keystone to create a standalone trust. This"},{"line_number":77,"context_line":"will cause keystone to create and record an API key for the trust. This API key"},{"line_number":78,"context_line":"can later be used to consume the trust. Note that the trust continues to"},{"line_number":79,"context_line":"require a project and roles to be delegated."},{"line_number":80,"context_line":""},{"line_number":81,"context_line":"Alternatives"},{"line_number":82,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a74a57a_f8cb971c","line":79,"in_reply_to":"7a77a97e_6a7054dd","updated":"2016-11-23 11:37:43.000000000","message":"Revocation would happen the same way as with a regular trust, by deleting the trust. Hence I don\u0027t see much of a need to change anything for the revocation in case of compromise use case where the trustor user knows the trust ID anyway and can delete the trust by ID.\n\nThat being said there still is a use case for deletion by API key: if the trustee wants to voluntarily relinquish the trust they\u0027ll need to be able to delete it by API key, since they do not need trust ID for consuming the trust and hence may well not have it.","commit_id":"b36f065b04cd83059bfefa9cd3c3040d81b37d62"},{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"0f0ad949f7868b62ae1e6fce4c9c51fd82ed1741","unresolved":false,"context_lines":[{"line_number":101,"context_line":""},{"line_number":102,"context_line":"* The API key itself needs to be generated in a secure manner since it is used"},{"line_number":103,"context_line":"  for both identification and authentication. In the simplest case it would be"},{"line_number":104,"context_line":"  a unique, long random string. The exact manner of creating this string should"},{"line_number":105,"context_line":"  be discussed in the course of spec review."},{"line_number":106,"context_line":""},{"line_number":107,"context_line":"Notifications Impact"}],"source_content_type":"text/x-rst","patch_set":4,"id":"7a77a97e_0c5a9d2a","line":104,"updated":"2016-11-22 15:10:18.000000000","message":"This might be an implementation detail, but would fernet work here (not sure if we\u0027d need another key repository or not)?","commit_id":"b36f065b04cd83059bfefa9cd3c3040d81b37d62"},{"author":{"_account_id":12542,"name":"Johannes Grassler","email":"jgr-launchpad@btw23.de","username":"jgrassler"},"change_message_id":"8665107d61abee03b38da5637215e8dddc646f8d","unresolved":false,"context_lines":[{"line_number":101,"context_line":""},{"line_number":102,"context_line":"* The API key itself needs to be generated in a secure manner since it is used"},{"line_number":103,"context_line":"  for both identification and authentication. In the simplest case it would be"},{"line_number":104,"context_line":"  a unique, long random string. The exact manner of creating this string should"},{"line_number":105,"context_line":"  be discussed in the course of spec review."},{"line_number":106,"context_line":""},{"line_number":107,"context_line":"Notifications Impact"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a74a57a_3db0a1f4","line":104,"in_reply_to":"7a77a97e_0c5a9d2a","updated":"2016-11-23 11:37:43.000000000","message":"I\u0027d rather avoid Fernet - that requires key distribution infrastructure in a multi node setup, regardless of whether there\u0027s a dedicated key repository or the key repository for Fernet tokens is re-used. It would be an option in a hypothetical future where everybody is using Fernet tokens anyway and a key distribution infrastructure can be taken for granted, but that\u0027s not what we can reasonably expect today.","commit_id":"b36f065b04cd83059bfefa9cd3c3040d81b37d62"},{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"0f0ad949f7868b62ae1e6fce4c9c51fd82ed1741","unresolved":false,"context_lines":[{"line_number":125,"context_line":"Performance Impact"},{"line_number":126,"context_line":"------------------"},{"line_number":127,"context_line":""},{"line_number":128,"context_line":"keystone needs to be able to look up a trust from the database by API key, so"},{"line_number":129,"context_line":"the column holding a trust\u0027s API key should be a primary key for the table."},{"line_number":130,"context_line":""},{"line_number":131,"context_line":"Other Deployer Impact"}],"source_content_type":"text/x-rst","patch_set":4,"id":"7a77a97e_2c967994","line":128,"updated":"2016-11-22 15:10:18.000000000","message":"nit: Keystone* only because it\u0027s starting the sentence :) \n\nI probably should have clarified that in my previous comment.","commit_id":"b36f065b04cd83059bfefa9cd3c3040d81b37d62"},{"author":{"_account_id":12542,"name":"Johannes Grassler","email":"jgr-launchpad@btw23.de","username":"jgrassler"},"change_message_id":"8665107d61abee03b38da5637215e8dddc646f8d","unresolved":false,"context_lines":[{"line_number":125,"context_line":"Performance Impact"},{"line_number":126,"context_line":"------------------"},{"line_number":127,"context_line":""},{"line_number":128,"context_line":"keystone needs to be able to look up a trust from the database by API key, so"},{"line_number":129,"context_line":"the column holding a trust\u0027s API key should be a primary key for the table."},{"line_number":130,"context_line":""},{"line_number":131,"context_line":"Other Deployer Impact"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a74a57a_bd73d14c","line":128,"in_reply_to":"7a77a97e_2c967994","updated":"2016-11-23 11:37:43.000000000","message":"It\u0027s alright, I should have payed closer attention to what s/Keystone/keystone/ did in seek-and-destroy mode :-)\n\nFixed.","commit_id":"b36f065b04cd83059bfefa9cd3c3040d81b37d62"},{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"0f0ad949f7868b62ae1e6fce4c9c51fd82ed1741","unresolved":false,"context_lines":[{"line_number":126,"context_line":"------------------"},{"line_number":127,"context_line":""},{"line_number":128,"context_line":"keystone needs to be able to look up a trust from the database by API key, so"},{"line_number":129,"context_line":"the column holding a trust\u0027s API key should be a primary key for the table."},{"line_number":130,"context_line":""},{"line_number":131,"context_line":"Other Deployer Impact"},{"line_number":132,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"7a77a97e_8cb94d18","line":129,"updated":"2016-11-22 15:10:18.000000000","message":"Another implementation concern, but I assume that API keys will be hashed before being persisted?","commit_id":"b36f065b04cd83059bfefa9cd3c3040d81b37d62"},{"author":{"_account_id":12542,"name":"Johannes Grassler","email":"jgr-launchpad@btw23.de","username":"jgrassler"},"change_message_id":"8665107d61abee03b38da5637215e8dddc646f8d","unresolved":false,"context_lines":[{"line_number":126,"context_line":"------------------"},{"line_number":127,"context_line":""},{"line_number":128,"context_line":"keystone needs to be able to look up a trust from the database by API key, so"},{"line_number":129,"context_line":"the column holding a trust\u0027s API key should be a primary key for the table."},{"line_number":130,"context_line":""},{"line_number":131,"context_line":"Other Deployer Impact"},{"line_number":132,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a74a57a_0c0574c1","line":129,"in_reply_to":"7a77a97e_8cb94d18","updated":"2016-11-23 11:37:43.000000000","message":"Good point, I didn\u0027t think of that. I incorporated that into the spec now. I specified an unsalted hash for now, but if you\u0027ve got an idea for a shared salt that\u0027s reliably available on all Keystone servers I\u0027m all ears (it would have to be something guaranteed to remain static - I really don\u0027t want a change of that shared salt to unexpectedly invalidate all API keys in one fell swoop).","commit_id":"b36f065b04cd83059bfefa9cd3c3040d81b37d62"},{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"0f0ad949f7868b62ae1e6fce4c9c51fd82ed1741","unresolved":false,"context_lines":[{"line_number":133,"context_line":""},{"line_number":134,"context_line":"This feature will be configurable through the setting"},{"line_number":135,"context_line":""},{"line_number":136,"context_line":"  ``keystone.conf [trusts] standalone_trusts \u003d True``"},{"line_number":137,"context_line":""},{"line_number":138,"context_line":"which will be `True` by default. The rationale behind this default is giving as"},{"line_number":139,"context_line":"many users as possible the option to use lightweight trusts (thus keeping them"}],"source_content_type":"text/x-rst","patch_set":4,"id":"7a77a97e_ac8e0925","line":136,"updated":"2016-11-22 15:10:18.000000000","message":"I\u0027m full of implementation questions today. As a deployer ``standalone_trusts`` don\u0027t really jump out to me as something I am familiar with whereas ``api_key`` is. We could almost leave the configuration option name out of this section (to prevent people like me from bike-shedding) and just say that API key authentication can be turned on through configuration and it will default to being on. :)","commit_id":"b36f065b04cd83059bfefa9cd3c3040d81b37d62"},{"author":{"_account_id":12542,"name":"Johannes Grassler","email":"jgr-launchpad@btw23.de","username":"jgrassler"},"change_message_id":"8665107d61abee03b38da5637215e8dddc646f8d","unresolved":false,"context_lines":[{"line_number":133,"context_line":""},{"line_number":134,"context_line":"This feature will be configurable through the setting"},{"line_number":135,"context_line":""},{"line_number":136,"context_line":"  ``keystone.conf [trusts] standalone_trusts \u003d True``"},{"line_number":137,"context_line":""},{"line_number":138,"context_line":"which will be `True` by default. The rationale behind this default is giving as"},{"line_number":139,"context_line":"many users as possible the option to use lightweight trusts (thus keeping them"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5a74a57a_b84bdfaf","line":136,"in_reply_to":"7a77a97e_ac8e0925","updated":"2016-11-23 11:37:43.000000000","message":"Good point :-)\n\nI changed the name right here. I prefer that over picking a name later - someone might mistake the spec for documentation once this is implemented because it happens to be the first search result. For this sort of case I\u0027d rather err on the side of nailing down a little too much.","commit_id":"b36f065b04cd83059bfefa9cd3c3040d81b37d62"},{"author":{"_account_id":7725,"name":"David Stanek","email":"dstanek@dstanek.com","username":"dstanek"},"change_message_id":"8794129420b2a70f873a23ec4ded7961f0422208","unresolved":false,"context_lines":[{"line_number":19,"context_line":"a trust would enable users to create trusts on their own and generally reduce"},{"line_number":20,"context_line":"overhead in handling trusts."},{"line_number":21,"context_line":""},{"line_number":22,"context_line":"Problem Description"},{"line_number":23,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":24,"context_line":""},{"line_number":25,"context_line":"Trusts are currently tied to a trustee user. This is undesirable for the"}],"source_content_type":"text/x-rst","patch_set":5,"id":"5a74a57a_01b90415","line":22,"updated":"2016-11-28 20:50:32.000000000","message":"It would be nice to have an actual usecase or set of them that describes the feature from a user\u0027s point of view. Something that doesn\u0027t talk about trusts at all.","commit_id":"0af57a40d4aeaf73e4897eabee75722d1ca6c835"},{"author":{"_account_id":12542,"name":"Johannes Grassler","email":"jgr-launchpad@btw23.de","username":"jgrassler"},"change_message_id":"83505c965ad2633955f3eec12984b1bffd063329","unresolved":false,"context_lines":[{"line_number":19,"context_line":"a trust would enable users to create trusts on their own and generally reduce"},{"line_number":20,"context_line":"overhead in handling trusts."},{"line_number":21,"context_line":""},{"line_number":22,"context_line":"Problem Description"},{"line_number":23,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":24,"context_line":""},{"line_number":25,"context_line":"Trusts are currently tied to a trustee user. This is undesirable for the"}],"source_content_type":"text/x-rst","patch_set":5,"id":"5a74a57a_93438aae","line":22,"in_reply_to":"5a74a57a_01b90415","updated":"2016-11-29 16:05:51.000000000","message":"I\u0027ve got that in place throughout the spec (grant access to 3rd party tools/services without needing to give them their primary credentials), but it is probably a good idea to have it up here, yeah. I added a paragraph spelling out this use case to the Proposed Change section.","commit_id":"0af57a40d4aeaf73e4897eabee75722d1ca6c835"},{"author":{"_account_id":7725,"name":"David Stanek","email":"dstanek@dstanek.com","username":"dstanek"},"change_message_id":"8794129420b2a70f873a23ec4ded7961f0422208","unresolved":false,"context_lines":[{"line_number":44,"context_line":"  the trust is no longer needed, there\u0027s additional bookkeeping overhead in"},{"line_number":45,"context_line":"  removing the trustee user."},{"line_number":46,"context_line":""},{"line_number":47,"context_line":"Proposed Change"},{"line_number":48,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":49,"context_line":""},{"line_number":50,"context_line":"This change extends the trusts API by allowing trusts to be created without"}],"source_content_type":"text/x-rst","patch_set":5,"id":"5a74a57a_a1985079","line":47,"updated":"2016-11-28 20:50:32.000000000","message":"Won\u0027t we also need to make is easy to like a list of these trusts? I\u0027m thinking of how other services allow you to create application specific api-keys and then allow you to easily get a list of those and remove access when necessary. Does our current API give horizon that ability easily?","commit_id":"0af57a40d4aeaf73e4897eabee75722d1ca6c835"},{"author":{"_account_id":12542,"name":"Johannes Grassler","email":"jgr-launchpad@btw23.de","username":"jgrassler"},"change_message_id":"83505c965ad2633955f3eec12984b1bffd063329","unresolved":false,"context_lines":[{"line_number":44,"context_line":"  the trust is no longer needed, there\u0027s additional bookkeeping overhead in"},{"line_number":45,"context_line":"  removing the trustee user."},{"line_number":46,"context_line":""},{"line_number":47,"context_line":"Proposed Change"},{"line_number":48,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":49,"context_line":""},{"line_number":50,"context_line":"This change extends the trusts API by allowing trusts to be created without"}],"source_content_type":"text/x-rst","patch_set":5,"id":"5a74a57a_ae9d79bd","line":47,"in_reply_to":"5a74a57a_a1985079","updated":"2016-11-29 16:05:51.000000000","message":"For auditability reasons such a list in Horizon would definitely be a beneficial thing to have, even for trusts without this extension. For right now various OpenStack services just create trusts if they feel like they need them, with the user usually not even noticing.\n\nThat being said, I consider this listing feature out of scope for this change: the Keystone API already allows listing trusts (and for non-privileged users it filters for their own trusts). The API key is just another column in that table. So the changes to Horizon (if any) would be minimal.","commit_id":"0af57a40d4aeaf73e4897eabee75722d1ca6c835"},{"author":{"_account_id":7725,"name":"David Stanek","email":"dstanek@dstanek.com","username":"dstanek"},"change_message_id":"8794129420b2a70f873a23ec4ded7961f0422208","unresolved":false,"context_lines":[{"line_number":55,"context_line":"supplied along with it. Note that creating a standalone trust implies"},{"line_number":56,"context_line":"impersonation."},{"line_number":57,"context_line":""},{"line_number":58,"context_line":"This change does explicitely not remove the ability to tie a trust to a trustee"},{"line_number":59,"context_line":"user, for this can be used to provide additional security in cases where such a"},{"line_number":60,"context_line":"user is available anyway (e.g. when a trust is delegated to a service user)."},{"line_number":61,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"5a74a57a_413dbc8d","line":58,"updated":"2016-11-28 20:50:32.000000000","message":"*explicitly","commit_id":"0af57a40d4aeaf73e4897eabee75722d1ca6c835"},{"author":{"_account_id":12542,"name":"Johannes Grassler","email":"jgr-launchpad@btw23.de","username":"jgrassler"},"change_message_id":"83505c965ad2633955f3eec12984b1bffd063329","unresolved":false,"context_lines":[{"line_number":55,"context_line":"supplied along with it. Note that creating a standalone trust implies"},{"line_number":56,"context_line":"impersonation."},{"line_number":57,"context_line":""},{"line_number":58,"context_line":"This change does explicitely not remove the ability to tie a trust to a trustee"},{"line_number":59,"context_line":"user, for this can be used to provide additional security in cases where such a"},{"line_number":60,"context_line":"user is available anyway (e.g. when a trust is delegated to a service user)."},{"line_number":61,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"5a74a57a_4eadc5e7","line":58,"in_reply_to":"5a74a57a_413dbc8d","updated":"2016-11-29 16:05:51.000000000","message":"Done","commit_id":"0af57a40d4aeaf73e4897eabee75722d1ca6c835"},{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"df759683f76da7b4d7e3bbb3f4d8e6bef5c8bb86","unresolved":false,"context_lines":[{"line_number":74,"context_line":"* `trustee_user_id`"},{"line_number":75,"context_line":""},{"line_number":76,"context_line":"becomes optional. Omitting it tells keystone to create a standalone trust. This"},{"line_number":77,"context_line":"will cause keystone to create and record an API key for the trust. This API key"},{"line_number":78,"context_line":"can later be used to consume the trust. Note that the trust continues to"},{"line_number":79,"context_line":"require a project and roles to be delegated."},{"line_number":80,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"5a74a57a_c1938c59","line":77,"updated":"2016-11-28 20:23:05.000000000","message":"Another implementation question, but is the API key stored as an attribute of the trust? If so, is it indexable?","commit_id":"0af57a40d4aeaf73e4897eabee75722d1ca6c835"},{"author":{"_account_id":12542,"name":"Johannes Grassler","email":"jgr-launchpad@btw23.de","username":"jgrassler"},"change_message_id":"83505c965ad2633955f3eec12984b1bffd063329","unresolved":false,"context_lines":[{"line_number":74,"context_line":"* `trustee_user_id`"},{"line_number":75,"context_line":""},{"line_number":76,"context_line":"becomes optional. Omitting it tells keystone to create a standalone trust. This"},{"line_number":77,"context_line":"will cause keystone to create and record an API key for the trust. This API key"},{"line_number":78,"context_line":"can later be used to consume the trust. Note that the trust continues to"},{"line_number":79,"context_line":"require a project and roles to be delegated."},{"line_number":80,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"5a74a57a_b4606ca6","line":77,"in_reply_to":"5a74a57a_0f85ab58","updated":"2016-11-29 16:05:51.000000000","message":"Yes, definitely an attribute of the trust. It is indexable since the hash created from the API key is unique.","commit_id":"0af57a40d4aeaf73e4897eabee75722d1ca6c835"},{"author":{"_account_id":7725,"name":"David Stanek","email":"dstanek@dstanek.com","username":"dstanek"},"change_message_id":"bb60666b3b866a6d57895b01d980f5e01a9145c1","unresolved":false,"context_lines":[{"line_number":74,"context_line":"* `trustee_user_id`"},{"line_number":75,"context_line":""},{"line_number":76,"context_line":"becomes optional. Omitting it tells keystone to create a standalone trust. This"},{"line_number":77,"context_line":"will cause keystone to create and record an API key for the trust. This API key"},{"line_number":78,"context_line":"can later be used to consume the trust. Note that the trust continues to"},{"line_number":79,"context_line":"require a project and roles to be delegated."},{"line_number":80,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"5a74a57a_0f85ab58","line":77,"in_reply_to":"5a74a57a_c1938c59","updated":"2016-11-28 20:53:20.000000000","message":"It would have to be or else the performance would tank.","commit_id":"0af57a40d4aeaf73e4897eabee75722d1ca6c835"},{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"df759683f76da7b4d7e3bbb3f4d8e6bef5c8bb86","unresolved":false,"context_lines":[{"line_number":79,"context_line":"require a project and roles to be delegated."},{"line_number":80,"context_line":""},{"line_number":81,"context_line":"The API key is returned in the clear only upon creation and needs to saved for"},{"line_number":82,"context_line":"use. For authentication purposes a hash of the API key is saved in the `trusts`"},{"line_number":83,"context_line":"table."},{"line_number":84,"context_line":""},{"line_number":85,"context_line":"Changes to Trust Deletion API"}],"source_content_type":"text/x-rst","patch_set":5,"id":"5a74a57a_a14210ac","line":82,"updated":"2016-11-28 20:23:05.000000000","message":"So, this makes it seem as though there won\u0027t be the ability to list API keys for a user? If a user looses their API key, then they have to create a new one, without having the ability to clean up the old one, right? \n\nI\u0027m trying to draw comparisons to other systems that use API keys. Typically I have to go to a settings page after I\u0027ve authenticated and I\u0027m able to see my current API key (this is nice in case I don\u0027t have it stored anywhere).\n\nThis actually brings up another question. Every time I\u0027ve used an API key, I\u0027ve only ever had one... Are we going to limit that somehow?","commit_id":"0af57a40d4aeaf73e4897eabee75722d1ca6c835"},{"author":{"_account_id":12542,"name":"Johannes Grassler","email":"jgr-launchpad@btw23.de","username":"jgrassler"},"change_message_id":"83505c965ad2633955f3eec12984b1bffd063329","unresolved":false,"context_lines":[{"line_number":79,"context_line":"require a project and roles to be delegated."},{"line_number":80,"context_line":""},{"line_number":81,"context_line":"The API key is returned in the clear only upon creation and needs to saved for"},{"line_number":82,"context_line":"use. For authentication purposes a hash of the API key is saved in the `trusts`"},{"line_number":83,"context_line":"table."},{"line_number":84,"context_line":""},{"line_number":85,"context_line":"Changes to Trust Deletion API"}],"source_content_type":"text/x-rst","patch_set":5,"id":"5a74a57a_f75901fe","line":82,"in_reply_to":"5a74a57a_2fd6e74e","updated":"2016-11-29 16:05:51.000000000","message":"\"application specific passwords\" would be a good description, yes. This is the main use case I intended it for.","commit_id":"0af57a40d4aeaf73e4897eabee75722d1ca6c835"},{"author":{"_account_id":12542,"name":"Johannes Grassler","email":"jgr-launchpad@btw23.de","username":"jgrassler"},"change_message_id":"3bf72097aca6c77313a26d38f1df90e1023f1937","unresolved":false,"context_lines":[{"line_number":79,"context_line":"require a project and roles to be delegated."},{"line_number":80,"context_line":""},{"line_number":81,"context_line":"The API key is returned in the clear only upon creation and needs to saved for"},{"line_number":82,"context_line":"use. For authentication purposes a hash of the API key is saved in the `trusts`"},{"line_number":83,"context_line":"table."},{"line_number":84,"context_line":""},{"line_number":85,"context_line":"Changes to Trust Deletion API"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3a71b18c_674cbf9e","line":82,"in_reply_to":"5a74a57a_8cd98986","updated":"2016-12-05 15:47:19.000000000","message":"\u003e Got it - that helps clear some of this up. If I\u0027m the account owner, and I\n\u003e want to clean up the trust of an API key that has been compromised, how do I\n\u003e do that?\n\nThere are two ways to do that:\n\n1) Delete the trust by sending a DELETE request to /v3/OS-TRUST/trusts with the\n   trust\u0027s API key in its body (see section Changes to Trust Deletion API).\n   That can be done by anybody holding the API key, i.e. the trustee can use it\n   to voluntarily relinquish their powers (important to allow for automatic\n   cleanup).\n\n2) You delete the trust in the regular manner by sending a DELETE request to\n   /v3/OS-TRUST/trusts/{trust_id}. Only the trustee user can do that.\n\n\u003e Right now there isn\u0027t a way to trace an API key back to the trust it came\n\u003e from, is there?\n\nThere is: you hash the plaintext API key and look up the resulting hashed\nvalue, which is a primary key of the trusts table. Only Keystone can do that of\ncourse. It would be possible to add a GET operation that takes an API key,\nwhich would give allow the user to look up the trust that goes with an API key,\nthough. Should I add that?","commit_id":"0af57a40d4aeaf73e4897eabee75722d1ca6c835"},{"author":{"_account_id":12542,"name":"Johannes Grassler","email":"jgr-launchpad@btw23.de","username":"jgrassler"},"change_message_id":"83505c965ad2633955f3eec12984b1bffd063329","unresolved":false,"context_lines":[{"line_number":79,"context_line":"require a project and roles to be delegated."},{"line_number":80,"context_line":""},{"line_number":81,"context_line":"The API key is returned in the clear only upon creation and needs to saved for"},{"line_number":82,"context_line":"use. For authentication purposes a hash of the API key is saved in the `trusts`"},{"line_number":83,"context_line":"table."},{"line_number":84,"context_line":""},{"line_number":85,"context_line":"Changes to Trust Deletion API"}],"source_content_type":"text/x-rst","patch_set":5,"id":"5a74a57a_cd80f2f9","line":82,"in_reply_to":"5a74a57a_a14210ac","updated":"2016-11-29 16:05:51.000000000","message":"\u003e So, this makes it seem as though there won\u0027t be the ability to list API keys\n\u003e for a user? If a user looses their API key, then they have to create a new\n\u003e one, without having the ability to clean up the old one, right? \n\nThe user themselves (as in the trust\u0027s trustor) can always clean up an API key\nby deleting the trust it is associated with since the user does not need the\nAPI key by virtue of having the account\u0027s primary credentials (i.e. user name\nand password). \n\n\u003e I\u0027m trying to draw comparisons to other systems that use API keys. Typically\n\u003e I have to go to a settings page after I\u0027ve authenticated and I\u0027m able to see\n\u003e my current API key (this is nice in case I don\u0027t have it stored anywhere).\n\nThe problem with allowing later access to the API key is that we\u0027d have to\nstore it in the clear. Modulo the limits imposed by the trust being scoped to a\nproject/set of roles this is as bad as storing passwords in the clear.\n\n\u003e This actually brings up another question. Every time I\u0027ve used an API key,\n\u003e I\u0027ve only ever had one... Are we going to limit that somehow?\n\nOnly to the extent that the number of trusts is limited: the relationship\nbetween API keys and trusts is 1:1, i.e. there can only ever be one API key per\ntrust. Thus you\u0027d have to create another trust to generate a second API key.","commit_id":"0af57a40d4aeaf73e4897eabee75722d1ca6c835"},{"author":{"_account_id":7725,"name":"David Stanek","email":"dstanek@dstanek.com","username":"dstanek"},"change_message_id":"bb60666b3b866a6d57895b01d980f5e01a9145c1","unresolved":false,"context_lines":[{"line_number":79,"context_line":"require a project and roles to be delegated."},{"line_number":80,"context_line":""},{"line_number":81,"context_line":"The API key is returned in the clear only upon creation and needs to saved for"},{"line_number":82,"context_line":"use. For authentication purposes a hash of the API key is saved in the `trusts`"},{"line_number":83,"context_line":"table."},{"line_number":84,"context_line":""},{"line_number":85,"context_line":"Changes to Trust Deletion API"}],"source_content_type":"text/x-rst","patch_set":5,"id":"5a74a57a_2fd6e74e","line":82,"in_reply_to":"5a74a57a_a14210ac","updated":"2016-11-28 20:53:20.000000000","message":"Yes, this doesn\u0027t sound like an api-key. I implied this below, but to be more specific this sounds more like application specific passwords.","commit_id":"0af57a40d4aeaf73e4897eabee75722d1ca6c835"},{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"e033b0541172ca4a4adcb133445b4d63af6c5a45","unresolved":false,"context_lines":[{"line_number":79,"context_line":"require a project and roles to be delegated."},{"line_number":80,"context_line":""},{"line_number":81,"context_line":"The API key is returned in the clear only upon creation and needs to saved for"},{"line_number":82,"context_line":"use. For authentication purposes a hash of the API key is saved in the `trusts`"},{"line_number":83,"context_line":"table."},{"line_number":84,"context_line":""},{"line_number":85,"context_line":"Changes to Trust Deletion API"}],"source_content_type":"text/x-rst","patch_set":5,"id":"5a74a57a_8cd98986","line":82,"in_reply_to":"5a74a57a_cd80f2f9","updated":"2016-11-29 23:10:18.000000000","message":"Got it - that helps clear some of this up. If I\u0027m the account owner, and I want to clean up the trust of an API key that has been compromised, how do I do that? Right now there isn\u0027t a way to trace an API key back to the trust it came from, is there?","commit_id":"0af57a40d4aeaf73e4897eabee75722d1ca6c835"},{"author":{"_account_id":7725,"name":"David Stanek","email":"dstanek@dstanek.com","username":"dstanek"},"change_message_id":"8794129420b2a70f873a23ec4ded7961f0422208","unresolved":false,"context_lines":[{"line_number":147,"context_line":"Alternatives"},{"line_number":148,"context_line":"------------"},{"line_number":149,"context_line":""},{"line_number":150,"context_line":"Continue requiring a trustee user for trust creation."},{"line_number":151,"context_line":""},{"line_number":152,"context_line":"Security Impact"},{"line_number":153,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"5a74a57a_e1f088cb","line":150,"updated":"2016-11-28 20:50:32.000000000","message":"Is there no other alternative to solve the actual usecase?","commit_id":"0af57a40d4aeaf73e4897eabee75722d1ca6c835"},{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"df759683f76da7b4d7e3bbb3f4d8e6bef5c8bb86","unresolved":false,"context_lines":[{"line_number":147,"context_line":"Alternatives"},{"line_number":148,"context_line":"------------"},{"line_number":149,"context_line":""},{"line_number":150,"context_line":"Continue requiring a trustee user for trust creation."},{"line_number":151,"context_line":""},{"line_number":152,"context_line":"Security Impact"},{"line_number":153,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"5a74a57a_81ea7472","line":150,"updated":"2016-11-28 20:23:05.000000000","message":"What would the ramifications be of introducing a new token type that is dedicated to API keys, and not building it into trusts? Is that an alternative worth exploring and at least documenting here?","commit_id":"0af57a40d4aeaf73e4897eabee75722d1ca6c835"},{"author":{"_account_id":12542,"name":"Johannes Grassler","email":"jgr-launchpad@btw23.de","username":"jgrassler"},"change_message_id":"83505c965ad2633955f3eec12984b1bffd063329","unresolved":false,"context_lines":[{"line_number":147,"context_line":"Alternatives"},{"line_number":148,"context_line":"------------"},{"line_number":149,"context_line":""},{"line_number":150,"context_line":"Continue requiring a trustee user for trust creation."},{"line_number":151,"context_line":""},{"line_number":152,"context_line":"Security Impact"},{"line_number":153,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"5a74a57a_57c39537","line":150,"in_reply_to":"5a74a57a_81ea7472","updated":"2016-11-29 16:05:51.000000000","message":"That would indeed be an alternative and certainly worth exploring, thanks! I added a rough outline of this approach to the Alternatives section. I would prefer this approach, though (see the discussion in the updated Alternatives section for details).","commit_id":"0af57a40d4aeaf73e4897eabee75722d1ca6c835"},{"author":{"_account_id":7725,"name":"David Stanek","email":"dstanek@dstanek.com","username":"dstanek"},"change_message_id":"8794129420b2a70f873a23ec4ded7961f0422208","unresolved":false,"context_lines":[{"line_number":155,"context_line":"Once this feature (along with [0]) is widely known and adopted, it will"},{"line_number":156,"context_line":"arguably improve security since users no longer need to use their login"},{"line_number":157,"context_line":"credentials to grant applications or automation tools access to their OpenStack"},{"line_number":158,"context_line":"account. Instead they can provide these applications and automation tools with"},{"line_number":159,"context_line":"an API key that can be used to obtain trust scoped tokens. That being said,"},{"line_number":160,"context_line":"there are some security critical parts to this:"},{"line_number":161,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"5a74a57a_84b602f7","line":158,"updated":"2016-11-28 20:50:32.000000000","message":"An api-key is really just another bearer token, hopefully with limited scope.","commit_id":"0af57a40d4aeaf73e4897eabee75722d1ca6c835"},{"author":{"_account_id":12542,"name":"Johannes Grassler","email":"jgr-launchpad@btw23.de","username":"jgrassler"},"change_message_id":"83505c965ad2633955f3eec12984b1bffd063329","unresolved":false,"context_lines":[{"line_number":155,"context_line":"Once this feature (along with [0]) is widely known and adopted, it will"},{"line_number":156,"context_line":"arguably improve security since users no longer need to use their login"},{"line_number":157,"context_line":"credentials to grant applications or automation tools access to their OpenStack"},{"line_number":158,"context_line":"account. Instead they can provide these applications and automation tools with"},{"line_number":159,"context_line":"an API key that can be used to obtain trust scoped tokens. That being said,"},{"line_number":160,"context_line":"there are some security critical parts to this:"},{"line_number":161,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"5a74a57a_12b20b4c","line":158,"in_reply_to":"5a74a57a_84b602f7","updated":"2016-11-29 16:05:51.000000000","message":"Definitely with limited scope. Since it is tied to a trust it is limited to the roles/project delegated to that trust.","commit_id":"0af57a40d4aeaf73e4897eabee75722d1ca6c835"},{"author":{"_account_id":7725,"name":"David Stanek","email":"dstanek@dstanek.com","username":"dstanek"},"change_message_id":"8794129420b2a70f873a23ec4ded7961f0422208","unresolved":false,"context_lines":[{"line_number":165,"context_line":"  association with a trustee user is desired, this feature must be configurable"},{"line_number":166,"context_line":"  (just as trusts themselves are configurable)."},{"line_number":167,"context_line":""},{"line_number":168,"context_line":"* The API key itself needs to be generated in a secure manner since it is used"},{"line_number":169,"context_line":"  for both identification and authentication. In the simplest case it would be"},{"line_number":170,"context_line":"  a unique, long random string. The exact manner of creating this string should"},{"line_number":171,"context_line":"  be discussed in the course of spec review."}],"source_content_type":"text/x-rst","patch_set":5,"id":"5a74a57a_6f70dfa4","line":168,"updated":"2016-11-28 20:50:32.000000000","message":"What exactly will this string look like and what information will it contain? That\u0027s important context for my next question.","commit_id":"0af57a40d4aeaf73e4897eabee75722d1ca6c835"},{"author":{"_account_id":12542,"name":"Johannes Grassler","email":"jgr-launchpad@btw23.de","username":"jgrassler"},"change_message_id":"83505c965ad2633955f3eec12984b1bffd063329","unresolved":false,"context_lines":[{"line_number":165,"context_line":"  association with a trustee user is desired, this feature must be configurable"},{"line_number":166,"context_line":"  (just as trusts themselves are configurable)."},{"line_number":167,"context_line":""},{"line_number":168,"context_line":"* The API key itself needs to be generated in a secure manner since it is used"},{"line_number":169,"context_line":"  for both identification and authentication. In the simplest case it would be"},{"line_number":170,"context_line":"  a unique, long random string. The exact manner of creating this string should"},{"line_number":171,"context_line":"  be discussed in the course of spec review."}],"source_content_type":"text/x-rst","patch_set":5,"id":"5a74a57a_ad8d7632","line":168,"in_reply_to":"5a74a57a_6f70dfa4","updated":"2016-11-29 16:05:51.000000000","message":"It will be a long randomly generated string. I\u0027m not a cryptographer so I have a hard time coming up with a sensible length, but I\u0027d go for at least 128 characters. Since this is meant for use by machines not humans I see no reason not to make it even longer.","commit_id":"0af57a40d4aeaf73e4897eabee75722d1ca6c835"},{"author":{"_account_id":7725,"name":"David Stanek","email":"dstanek@dstanek.com","username":"dstanek"},"change_message_id":"8794129420b2a70f873a23ec4ded7961f0422208","unresolved":false,"context_lines":[{"line_number":170,"context_line":"  a unique, long random string. The exact manner of creating this string should"},{"line_number":171,"context_line":"  be discussed in the course of spec review."},{"line_number":172,"context_line":""},{"line_number":173,"context_line":"* Since the API key is a secret that can be used to acquire a token, it is not"},{"line_number":174,"context_line":"  directly stored in the keystone database. Instead a hash using a secure hash"},{"line_number":175,"context_line":"  function is computed and stored in the database. The hash is not salted to"},{"line_number":176,"context_line":"  allow for hashing and looking up a plaintext key provided in the course of"}],"source_content_type":"text/x-rst","patch_set":5,"id":"5a74a57a_84a1a248","line":173,"updated":"2016-11-28 20:50:32.000000000","message":"What are you protecting against here? If you don\u0027t use a salt wouldn\u0027t it be pretty easy to generate all possible api-keys anyway? Why not hash in the same way that we do for passwords?","commit_id":"0af57a40d4aeaf73e4897eabee75722d1ca6c835"},{"author":{"_account_id":12542,"name":"Johannes Grassler","email":"jgr-launchpad@btw23.de","username":"jgrassler"},"change_message_id":"83505c965ad2633955f3eec12984b1bffd063329","unresolved":false,"context_lines":[{"line_number":170,"context_line":"  a unique, long random string. The exact manner of creating this string should"},{"line_number":171,"context_line":"  be discussed in the course of spec review."},{"line_number":172,"context_line":""},{"line_number":173,"context_line":"* Since the API key is a secret that can be used to acquire a token, it is not"},{"line_number":174,"context_line":"  directly stored in the keystone database. Instead a hash using a secure hash"},{"line_number":175,"context_line":"  function is computed and stored in the database. The hash is not salted to"},{"line_number":176,"context_line":"  allow for hashing and looking up a plaintext key provided in the course of"}],"source_content_type":"text/x-rst","patch_set":5,"id":"5a74a57a_6d999e78","line":173,"in_reply_to":"5a74a57a_84a1a248","updated":"2016-11-29 16:05:51.000000000","message":"I am protecting against an attacker that lifts the Keystone database somehow and could then use API keys to authenticate if they are stored in plaintext. Creating a rainbow table for strings of 128 characters (or more) is probably a bit of a challenge, though. I\u0027d prefer salting these hashes, but I\u0027m not sure what to use for a salt (a random salt stored in keystone.conf would be one option, I guess).","commit_id":"0af57a40d4aeaf73e4897eabee75722d1ca6c835"},{"author":{"_account_id":7725,"name":"David Stanek","email":"dstanek@dstanek.com","username":"dstanek"},"change_message_id":"8794129420b2a70f873a23ec4ded7961f0422208","unresolved":false,"context_lines":[{"line_number":187,"context_line":"Notifications Impact"},{"line_number":188,"context_line":"--------------------"},{"line_number":189,"context_line":""},{"line_number":190,"context_line":"None"},{"line_number":191,"context_line":""},{"line_number":192,"context_line":"Other End User Impact"},{"line_number":193,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"5a74a57a_042af28f","line":190,"updated":"2016-11-28 20:50:32.000000000","message":"Will there be a need for any changes to notifications?","commit_id":"0af57a40d4aeaf73e4897eabee75722d1ca6c835"},{"author":{"_account_id":12542,"name":"Johannes Grassler","email":"jgr-launchpad@btw23.de","username":"jgrassler"},"change_message_id":"83505c965ad2633955f3eec12984b1bffd063329","unresolved":false,"context_lines":[{"line_number":187,"context_line":"Notifications Impact"},{"line_number":188,"context_line":"--------------------"},{"line_number":189,"context_line":""},{"line_number":190,"context_line":"None"},{"line_number":191,"context_line":""},{"line_number":192,"context_line":"Other End User Impact"},{"line_number":193,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"5a74a57a_f5b738f3","line":190,"in_reply_to":"5a74a57a_042af28f","updated":"2016-11-29 16:05:51.000000000","message":"Hmm. With a dedicated authentication method for this there might be a need for an extra notification. I\u0027m not sure what sort of events notifications need to be sent for (after all there are notifications upon token issue anyway).","commit_id":"0af57a40d4aeaf73e4897eabee75722d1ca6c835"},{"author":{"_account_id":7725,"name":"David Stanek","email":"dstanek@dstanek.com","username":"dstanek"},"change_message_id":"8794129420b2a70f873a23ec4ded7961f0422208","unresolved":false,"context_lines":[{"line_number":206,"context_line":"------------------"},{"line_number":207,"context_line":""},{"line_number":208,"context_line":"Keystone needs to be able to look up a trust from the database by API key, so"},{"line_number":209,"context_line":"the column holding a trust\u0027s API key should be a primary key for the `trusts`"},{"line_number":210,"context_line":"table."},{"line_number":211,"context_line":""},{"line_number":212,"context_line":"Other Deployer Impact"}],"source_content_type":"text/x-rst","patch_set":5,"id":"5a74a57a_8f161b4a","line":209,"updated":"2016-11-28 20:50:32.000000000","message":"*hashed* api key right?","commit_id":"0af57a40d4aeaf73e4897eabee75722d1ca6c835"},{"author":{"_account_id":12542,"name":"Johannes Grassler","email":"jgr-launchpad@btw23.de","username":"jgrassler"},"change_message_id":"83505c965ad2633955f3eec12984b1bffd063329","unresolved":false,"context_lines":[{"line_number":206,"context_line":"------------------"},{"line_number":207,"context_line":""},{"line_number":208,"context_line":"Keystone needs to be able to look up a trust from the database by API key, so"},{"line_number":209,"context_line":"the column holding a trust\u0027s API key should be a primary key for the `trusts`"},{"line_number":210,"context_line":"table."},{"line_number":211,"context_line":""},{"line_number":212,"context_line":"Other Deployer Impact"}],"source_content_type":"text/x-rst","patch_set":5,"id":"5a74a57a_15cd9486","line":209,"in_reply_to":"5a74a57a_8f161b4a","updated":"2016-11-29 16:05:51.000000000","message":"Yes. Fixed that.","commit_id":"0af57a40d4aeaf73e4897eabee75722d1ca6c835"},{"author":{"_account_id":7725,"name":"David Stanek","email":"dstanek@dstanek.com","username":"dstanek"},"change_message_id":"8794129420b2a70f873a23ec4ded7961f0422208","unresolved":false,"context_lines":[{"line_number":267,"context_line":"users who might otherwise provide their login credentials to"},{"line_number":268,"context_line":"applications/automation tools)."},{"line_number":269,"context_line":""},{"line_number":270,"context_line":"In both cases there needs to be some discussion of the scenarios where its use"},{"line_number":271,"context_line":"is appropriate. In admin guide there needs to be information on how to"},{"line_number":272,"context_line":"enable/disable it. Since it is enabled by default, the Ocata release notes"},{"line_number":273,"context_line":"should mention it."}],"source_content_type":"text/x-rst","patch_set":5,"id":"5a74a57a_af3f57b2","line":270,"updated":"2016-11-28 20:50:32.000000000","message":"I think some of that belongs above in this document.","commit_id":"0af57a40d4aeaf73e4897eabee75722d1ca6c835"},{"author":{"_account_id":12542,"name":"Johannes Grassler","email":"jgr-launchpad@btw23.de","username":"jgrassler"},"change_message_id":"83505c965ad2633955f3eec12984b1bffd063329","unresolved":false,"context_lines":[{"line_number":267,"context_line":"users who might otherwise provide their login credentials to"},{"line_number":268,"context_line":"applications/automation tools)."},{"line_number":269,"context_line":""},{"line_number":270,"context_line":"In both cases there needs to be some discussion of the scenarios where its use"},{"line_number":271,"context_line":"is appropriate. In admin guide there needs to be information on how to"},{"line_number":272,"context_line":"enable/disable it. Since it is enabled by default, the Ocata release notes"},{"line_number":273,"context_line":"should mention it."}],"source_content_type":"text/x-rst","patch_set":5,"id":"5a74a57a_153e7429","line":270,"in_reply_to":"5a74a57a_af3f57b2","updated":"2016-11-29 16:05:51.000000000","message":"I shouldn\u0027t have used \u0027discussion\u0027 :-)\n\nI rephrased that now. Also, I hope the explicit use case in the Proposed Change section satisfies the need for discussion now.","commit_id":"0af57a40d4aeaf73e4897eabee75722d1ca6c835"},{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"91c8208fff8c87d232b7b1ace60fdedfb4f4a56c","unresolved":false,"context_lines":[{"line_number":42,"context_line":"  pieces of data (user name, password and trust ID) to the entity using them,"},{"line_number":43,"context_line":"  where one (an API key) would suffice with standalone trusts in place. Once"},{"line_number":44,"context_line":"  the trust is no longer needed, there\u0027s additional bookkeeping overhead in"},{"line_number":45,"context_line":"  removing the trustee user."},{"line_number":46,"context_line":""},{"line_number":47,"context_line":"Proposed Change"},{"line_number":48,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":6,"id":"ba2be162_9d8d2f2d","line":45,"updated":"2017-03-06 18:25:43.000000000","message":"In addition to Steve comment below, we now have an official specification proposed for API keys. These use cases will be addressed upon the completion of that spec [0].\n\n[0] https://review.openstack.org/#/c/438761/","commit_id":"2931a31f11cd534494f96255980871d259e2bfe8"},{"author":{"_account_id":18338,"name":"Ron De Rose","email":"ronald.de.rose@intel.com","username":"derosenet"},"change_message_id":"6b268eeda5f17fe195766f54e096767e5e566739","unresolved":false,"context_lines":[{"line_number":42,"context_line":"  pieces of data (user name, password and trust ID) to the entity using them,"},{"line_number":43,"context_line":"  where one (an API key) would suffice with standalone trusts in place. Once"},{"line_number":44,"context_line":"  the trust is no longer needed, there\u0027s additional bookkeeping overhead in"},{"line_number":45,"context_line":"  removing the trustee user."},{"line_number":46,"context_line":""},{"line_number":47,"context_line":"Proposed Change"},{"line_number":48,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5ff73747_77e06bfb","line":45,"in_reply_to":"ba2be162_9d8d2f2d","updated":"2017-04-25 15:36:53.000000000","message":"We\u0027ve had 2 approaches for API keys, one that required requesting a scoped token; one that did not. I\u0027ve abandon the API Keys spec, in favor of an App Keys spec (required to request a scope token) [1].\n[1] https://review.openstack.org/#/c/450415/","commit_id":"2931a31f11cd534494f96255980871d259e2bfe8"},{"author":{"_account_id":6482,"name":"Steve Martinelli","email":"s.martinelli@gmail.com","username":"stevemar"},"change_message_id":"eb1807a19af7b0eb21e991684c3c7e124c30c1a8","unresolved":false,"context_lines":[{"line_number":59,"context_line":"user, for this can be used to provide additional security in cases where such a"},{"line_number":60,"context_line":"user is available anyway (e.g. when a trust is delegated to a service user)."},{"line_number":61,"context_line":""},{"line_number":62,"context_line":"With this change in place and enabled a user will be able to create an API key"},{"line_number":63,"context_line":"that grants a third party (i.e. not part of OpenStack) program or service (for"},{"line_number":64,"context_line":"instance a monitoring tool) limited access to their OpenStack user account"},{"line_number":65,"context_line":"without requiring that program to have access to their primary credentials"},{"line_number":66,"context_line":"(i.e. user name and password). The user will be able to do this in a"},{"line_number":67,"context_line":"self-service manner, without requiring another OpenStack user account to grant"},{"line_number":68,"context_line":"this access to."},{"line_number":69,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"3a71b18c_023ac8e6","line":66,"range":{"start_line":62,"start_character":0,"end_line":66,"end_character":30},"updated":"2016-12-07 04:51:35.000000000","message":"this is literally what os-oauth1 is solving :(\n\nProvide the ability for identity users to delegate roles to third party consumers via the OAuth 1.0a specification. Requires v3.0+ of the Identity API. An OAuth-derived token will provide a means of acting on behalf of the authorizing user.\n\nhttp://developer.openstack.org/api-ref/identity/v3-ext/index.html#os-oauth1-api","commit_id":"2931a31f11cd534494f96255980871d259e2bfe8"}]}