)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":6482,"name":"Steve Martinelli","email":"s.martinelli@gmail.com","username":"stevemar"},"change_message_id":"eacca9c2b2b3f84db201629919e54cb80411dd97","unresolved":false,"context_lines":[{"line_number":6,"context_line":""},{"line_number":7,"context_line":"New TOTP contrib plugin for non-admin access to TOTP credentials"},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"A new plugin similar to the ec3 contrib one to handle TOTP creation and"},{"line_number":10,"context_line":"management on a per user basis."},{"line_number":11,"context_line":""},{"line_number":12,"context_line":"Change-Id: I20869a409b58204552d84e36f867be89678f5c04"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"dada55a8_d495c688","line":9,"range":{"start_line":9,"start_character":28,"end_line":9,"end_character":31},"updated":"2016-07-22 17:49:09.000000000","message":"ec2","commit_id":"b5e8b107619e8383d3103ec733b6590a383d061d"}],"specs/keystone/ocata/totp-contrib.rst":[{"author":{"_account_id":6482,"name":"Steve Martinelli","email":"s.martinelli@gmail.com","username":"stevemar"},"change_message_id":"eacca9c2b2b3f84db201629919e54cb80411dd97","unresolved":false,"context_lines":[{"line_number":10,"context_line":""},{"line_number":11,"context_line":"`bp totp-contrib \u003chttps://blueprints.launchpad.net/keystone/+spec/totp-contrib\u003e`_"},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"A new plugin similar to the ec3 contrib one to handle TOTP creation and"},{"line_number":14,"context_line":"management on a per user basis."},{"line_number":15,"context_line":""},{"line_number":16,"context_line":"Problem Description"}],"source_content_type":"text/x-rst","patch_set":1,"id":"dada55a8_f48c4a81","line":13,"range":{"start_line":13,"start_character":28,"end_line":13,"end_character":31},"updated":"2016-07-22 17:49:09.000000000","message":"ec2","commit_id":"b5e8b107619e8383d3103ec733b6590a383d061d"},{"author":{"_account_id":6804,"name":"bruce-benjamin","email":"bruce.benjamin@jhuapl.edu","username":"bruce-benjamin"},"change_message_id":"f56d7fe9cd4de544e37c372ce0232d26c5acc062","unresolved":false,"context_lines":[{"line_number":44,"context_line":"Security Impact"},{"line_number":45,"context_line":"---------------"},{"line_number":46,"context_line":""},{"line_number":47,"context_line":"None"},{"line_number":48,"context_line":""},{"line_number":49,"context_line":"Notifications Impact"},{"line_number":50,"context_line":"--------------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"fa7ab95a_26e133d1","line":47,"range":{"start_line":47,"start_character":0,"end_line":47,"end_character":4},"updated":"2016-08-26 22:23:21.000000000","message":"Once the TOTP credential is established, I think it should be stated that this would have a positive security impact for the authentication of the user.","commit_id":"54c5f65456189682f3850c870d2a8aa3f84231a2"},{"author":{"_account_id":10420,"name":"Adrian Turjak","email":"devs+openstack@uncaught-exceptions.com","username":"adriant"},"change_message_id":"89326200e6f48f9cf20fbac7cf4b4d7238120d49","unresolved":false,"context_lines":[{"line_number":44,"context_line":"Security Impact"},{"line_number":45,"context_line":"---------------"},{"line_number":46,"context_line":""},{"line_number":47,"context_line":"None"},{"line_number":48,"context_line":""},{"line_number":49,"context_line":"Notifications Impact"},{"line_number":50,"context_line":"--------------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"fa7ab95a_2c1c9811","line":47,"range":{"start_line":47,"start_character":0,"end_line":47,"end_character":4},"in_reply_to":"fa7ab95a_26e133d1","updated":"2016-08-28 23:49:31.000000000","message":"TOTP via for MFA is covered by another spec/patch, but I will update this to something appropriate.","commit_id":"54c5f65456189682f3850c870d2a8aa3f84231a2"},{"author":{"_account_id":10420,"name":"Adrian Turjak","email":"devs+openstack@uncaught-exceptions.com","username":"adriant"},"change_message_id":"579bee99e55c0d9fbc8ed7bfea53c72da95b5888","unresolved":false,"context_lines":[{"line_number":44,"context_line":"Security Impact"},{"line_number":45,"context_line":"---------------"},{"line_number":46,"context_line":""},{"line_number":47,"context_line":"None"},{"line_number":48,"context_line":""},{"line_number":49,"context_line":"Notifications Impact"},{"line_number":50,"context_line":"--------------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"fa7ab95a_ec555050","line":47,"range":{"start_line":47,"start_character":0,"end_line":47,"end_character":4},"in_reply_to":"fa7ab95a_2c1c9811","updated":"2016-08-29 00:09:54.000000000","message":"TOTP for MFA is...\n\ntypo due to rewrite","commit_id":"54c5f65456189682f3850c870d2a8aa3f84231a2"},{"author":{"_account_id":6482,"name":"Steve Martinelli","email":"s.martinelli@gmail.com","username":"stevemar"},"change_message_id":"1f1847efe20db0208eac222b5ff5ac1b6fc73746","unresolved":false,"context_lines":[{"line_number":5,"context_line":" http://creativecommons.org/licenses/by/3.0/legalcode"},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":8,"context_line":"New TOTP contrib plugin for non-admin access to TOTP credentials"},{"line_number":9,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"`bp totp-contrib \u003chttps://blueprints.launchpad.net/keystone/+spec/totp-contrib\u003e`_"}],"source_content_type":"text/x-rst","patch_set":5,"id":"ba5da102_450b4d8e","line":8,"range":{"start_line":8,"start_character":9,"end_line":8,"end_character":16},"updated":"2016-11-01 15:26:02.000000000","message":"we no longer use \"contrib\" or \"plugins\", just make this whole thing part of core keystone","commit_id":"916fb45b17f592b65968486de8ac67e541a64736"},{"author":{"_account_id":6482,"name":"Steve Martinelli","email":"s.martinelli@gmail.com","username":"stevemar"},"change_message_id":"1f1847efe20db0208eac222b5ff5ac1b6fc73746","unresolved":false,"context_lines":[{"line_number":8,"context_line":"New TOTP contrib plugin for non-admin access to TOTP credentials"},{"line_number":9,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"`bp totp-contrib \u003chttps://blueprints.launchpad.net/keystone/+spec/totp-contrib\u003e`_"},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"A new plugin similar to the ec2 contrib one to handle TOTP creation and"},{"line_number":14,"context_line":"management on a per user basis."}],"source_content_type":"text/x-rst","patch_set":5,"id":"ba5da102_e5f0e193","line":11,"range":{"start_line":11,"start_character":4,"end_line":11,"end_character":16},"updated":"2016-11-01 15:26:02.000000000","message":"totp-per-user","commit_id":"916fb45b17f592b65968486de8ac67e541a64736"}],"specs/keystone/ocata/totp-per-user.rst":[{"author":{"_account_id":17860,"name":"Samuel de Medeiros Queiroz","email":"samueldmq@gmail.com","username":"samueldmq"},"change_message_id":"7ffeea02038568656f1a8d672398f1bb38dba351","unresolved":false,"context_lines":[{"line_number":12,"context_line":""},{"line_number":13,"context_line":"New endpoints similar to the ones for ec2 access keys to handle TOTP"},{"line_number":14,"context_line":"creation and management on a per user basis"},{"line_number":15,"context_line":""},{"line_number":16,"context_line":"Problem Description"},{"line_number":17,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":18,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"7a77a97e_2593dca4","line":15,"updated":"2016-11-16 13:48:59.000000000","message":"Credential entities have user_id and type properties.\nI would prefer to check on these properties on the policies than creating another API entry just because of different auth.\n\nThat way, current policies:\n\n    \"identity:create_credential\": \"rule:admin_required\",\n\nwould be changed to something like:\n\n    \"identity:create_credential\": \"rule:admin_required or (%(target.type)s and user_id:%(target.user_id)s\"\n\nI am not 100% sure this is possible today (to be tested_, but we could be exposing that info to the policy engine and having a simpler solution.","commit_id":"4f14924867f929cf74ca8e2feffcee89f050b621"},{"author":{"_account_id":10420,"name":"Adrian Turjak","email":"devs+openstack@uncaught-exceptions.com","username":"adriant"},"change_message_id":"d96bb7e754a7a8002997403de326079c64b41f4a","unresolved":false,"context_lines":[{"line_number":12,"context_line":""},{"line_number":13,"context_line":"New endpoints similar to the ones for ec2 access keys to handle TOTP"},{"line_number":14,"context_line":"creation and management on a per user basis"},{"line_number":15,"context_line":""},{"line_number":16,"context_line":"Problem Description"},{"line_number":17,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":18,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"7a77a97e_a678b9c5","line":15,"in_reply_to":"7a77a97e_2593dca4","updated":"2016-11-17 00:39:43.000000000","message":"I believe it is possible, as the EC2 controllers have this function to handle exactly that:\nhttps://github.com/openstack/keystone/blob/master/keystone/contrib/ec2/controllers.py#L363\n\nWhich is then part of why this policy works:\nhttps://github.com/openstack/keystone/blob/master/etc/policy.json#L68\n\nI haven\u0027t followed the logic all the way through, but I believe that is effectively what you are suggesting. While doable by also using that same function, I don\u0027t think this should be on the core credential endpoints.","commit_id":"4f14924867f929cf74ca8e2feffcee89f050b621"},{"author":{"_account_id":18666,"name":"Chris Plock","email":"chrisplo@cisco.com","username":"plockc"},"change_message_id":"5b22eec92b5ef49df8e81ad7f8fd39bd219cd81b","unresolved":false,"context_lines":[{"line_number":12,"context_line":""},{"line_number":13,"context_line":"New endpoints similar to the ones for ec2 access keys to handle TOTP"},{"line_number":14,"context_line":"creation and management on a per user basis"},{"line_number":15,"context_line":""},{"line_number":16,"context_line":"Problem Description"},{"line_number":17,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":18,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"7a77a97e_affd82b2","line":15,"in_reply_to":"7a77a97e_a678b9c5","updated":"2016-11-19 01:56:22.000000000","message":"Would like more discussion here . . this would be a third way to manage credentials right?  too many?\n* password via user API\n* credentials API\n* totp API\nuser api hasn\u0027t been mentioned, any thoughts there?","commit_id":"4f14924867f929cf74ca8e2feffcee89f050b621"},{"author":{"_account_id":10420,"name":"Adrian Turjak","email":"devs+openstack@uncaught-exceptions.com","username":"adriant"},"change_message_id":"2aa89c6be445baab29dfa08442c61f25bf2bc2b5","unresolved":false,"context_lines":[{"line_number":12,"context_line":""},{"line_number":13,"context_line":"New endpoints similar to the ones for ec2 access keys to handle TOTP"},{"line_number":14,"context_line":"creation and management on a per user basis"},{"line_number":15,"context_line":""},{"line_number":16,"context_line":"Problem Description"},{"line_number":17,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":18,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"7a77a97e_dbdb524d","line":15,"in_reply_to":"7a77a97e_affd82b2","updated":"2016-11-20 21:55:59.000000000","message":"Had a discussion around this the other day with, a new API is the easiest of the alternatives.\n\nI will update the spec with a summary of the alternatives and why they are not really an option right now.","commit_id":"4f14924867f929cf74ca8e2feffcee89f050b621"},{"author":{"_account_id":18666,"name":"Chris Plock","email":"chrisplo@cisco.com","username":"plockc"},"change_message_id":"5b22eec92b5ef49df8e81ad7f8fd39bd219cd81b","unresolved":false,"context_lines":[{"line_number":20,"context_line":"the unscoped nature of those endpoints, this is good. The issue though is"},{"line_number":21,"context_line":"that TOTP credentials, much like ec2 credentials, should be able to be"},{"line_number":22,"context_line":"managed by the user they are associated to. A user should be able to create,"},{"line_number":23,"context_line":"list, and delete their TOTP credentials with a valid token."},{"line_number":24,"context_line":""},{"line_number":25,"context_line":"Proposed Change"},{"line_number":26,"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":8,"id":"7a77a97e_bc29429d","line":23,"updated":"2016-11-19 01:56:22.000000000","message":"I think we need more flexibility here for an enterprise, where company would want to enforce MFA but manage the TOTP secret in their own workflow (via standalone-trusts) and block viewing the secret, updating it, or deleting it.","commit_id":"4f14924867f929cf74ca8e2feffcee89f050b621"},{"author":{"_account_id":10420,"name":"Adrian Turjak","email":"devs+openstack@uncaught-exceptions.com","username":"adriant"},"change_message_id":"2aa89c6be445baab29dfa08442c61f25bf2bc2b5","unresolved":false,"context_lines":[{"line_number":20,"context_line":"the unscoped nature of those endpoints, this is good. The issue though is"},{"line_number":21,"context_line":"that TOTP credentials, much like ec2 credentials, should be able to be"},{"line_number":22,"context_line":"managed by the user they are associated to. A user should be able to create,"},{"line_number":23,"context_line":"list, and delete their TOTP credentials with a valid token."},{"line_number":24,"context_line":""},{"line_number":25,"context_line":"Proposed Change"},{"line_number":26,"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":8,"id":"7a77a97e_7bbebeae","line":23,"in_reply_to":"7a77a97e_bc29429d","updated":"2016-11-20 21:55:59.000000000","message":"Properly enforcing MFA in any reasonable way is hard. To achieve this we would need to either redo the whole token system such that a user with some \"needs mfa\" flag can authenticate but get a sort of unscoped token which only lets them setup MFA. The alternative there is doing it with some sort of dynamic policies that allow conditions: if a user has the role \u0027needs_mfa\u0027, don\u0027t authorise for any other roles until they do have a TOTP credential. In either case, the work required is huge and has to be done carefully and slowly to not break backwards compatibility everywhere else.\n\nThe latter, allowing enterprise to manage TOTP secrets in their own workflow, that\u0027s perfectly doable but is not within the scope of Keystone at this time. Simply disable these new endpoints or set them to admin only in your policy files, and then use the admin credential APIs in some external service to manage TOTP for your users. In fact that is exactly how we\u0027ll be doing it in our deployment, through an external service which creates TOTP creds in Keystone on behalf of a user and won\u0027t let them disable it if an admin has enforced it. I\u0027ll hopefully have a prototype for this soon and will share it on the mailing list.\n\nThe scope of this spec specifically does not cover these because the work required is otherwise far too big, or because for now at least it is better or easier to do this outside of Keystone. What this spec hopes to achieve is the simplest and easiest way for users to manage their TOTP creds with the least amount of work in Keystone.","commit_id":"4f14924867f929cf74ca8e2feffcee89f050b621"},{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"b6f92c9687de418e64798bc203a3f582df719da0","unresolved":false,"context_lines":[{"line_number":29,"context_line":"TOTP credential management on a per user basis."},{"line_number":30,"context_line":""},{"line_number":31,"context_line":"It would allow a user to create a TOTP credential scoped to them, list ones"},{"line_number":32,"context_line":"they have (secret/blob should remain hidden), and delete their own TOTP"},{"line_number":33,"context_line":"credentials."},{"line_number":34,"context_line":""},{"line_number":35,"context_line":"Generation of a TOTP credential can optionally be done serverside with the"}],"source_content_type":"text/x-rst","patch_set":8,"id":"7a77a97e_8e49d662","line":32,"updated":"2016-11-18 03:11:37.000000000","message":"This would be inconsistent with the current API, which allows blobs to be returned when getting and listing credentials. I think this would be a backwards incompatible change to return an encrypted blob or no payload at all.","commit_id":"4f14924867f929cf74ca8e2feffcee89f050b621"},{"author":{"_account_id":10420,"name":"Adrian Turjak","email":"devs+openstack@uncaught-exceptions.com","username":"adriant"},"change_message_id":"2aa89c6be445baab29dfa08442c61f25bf2bc2b5","unresolved":false,"context_lines":[{"line_number":29,"context_line":"TOTP credential management on a per user basis."},{"line_number":30,"context_line":""},{"line_number":31,"context_line":"It would allow a user to create a TOTP credential scoped to them, list ones"},{"line_number":32,"context_line":"they have (secret/blob should remain hidden), and delete their own TOTP"},{"line_number":33,"context_line":"credentials."},{"line_number":34,"context_line":""},{"line_number":35,"context_line":"Generation of a TOTP credential can optionally be done serverside with the"}],"source_content_type":"text/x-rst","patch_set":8,"id":"7a77a97e_1b578a58","line":32,"in_reply_to":"7a77a97e_8e49d662","updated":"2016-11-20 21:55:59.000000000","message":"As discussed, new API, so this inconsistency is fine. Goal with not returning the secret is simply to make it so that once a TOTP cred has been setup by a user, even if they\u0027ve authenticated they can\u0027t see their own secret. Mainly a security thing, although it only stops someone else from being able to steal and use your secret if they\u0027ve somehow gained access once. Doesn\u0027t stop them getting the secret from your device, but does mean that it\u0027s a litter harder to get the secret.","commit_id":"4f14924867f929cf74ca8e2feffcee89f050b621"},{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"b6f92c9687de418e64798bc203a3f582df719da0","unresolved":false,"context_lines":[{"line_number":50,"context_line":"impact is a positive one."},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"The one downside is that if an admin sets a TOTP credential for you, the user"},{"line_number":53,"context_line":"will be able to disable it themselves. This could be avoided by making use of"},{"line_number":54,"context_line":"the extras field with an \"admin_enforced\" value, which when present and true"},{"line_number":55,"context_line":"does not allow a user to remove their own credential."},{"line_number":56,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"7a77a97e_2e29a237","line":53,"updated":"2016-11-18 03:11:37.000000000","message":"If an administrator enables a TOTP credential for a user, is there ever a reason why we would want to allow a user to disable it? I would think about building that into policy somehow to that a user can\u0027t disable it.","commit_id":"4f14924867f929cf74ca8e2feffcee89f050b621"},{"author":{"_account_id":10420,"name":"Adrian Turjak","email":"devs+openstack@uncaught-exceptions.com","username":"adriant"},"change_message_id":"2aa89c6be445baab29dfa08442c61f25bf2bc2b5","unresolved":false,"context_lines":[{"line_number":50,"context_line":"impact is a positive one."},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"The one downside is that if an admin sets a TOTP credential for you, the user"},{"line_number":53,"context_line":"will be able to disable it themselves. This could be avoided by making use of"},{"line_number":54,"context_line":"the extras field with an \"admin_enforced\" value, which when present and true"},{"line_number":55,"context_line":"does not allow a user to remove their own credential."},{"line_number":56,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"7a77a97e_5b4d82c2","line":53,"in_reply_to":"7a77a97e_2e29a237","updated":"2016-11-20 21:55:59.000000000","message":"As discussed, would require a new field on the TOTP object, or as said just below a value in extra, and then this API would simply check against it.","commit_id":"4f14924867f929cf74ca8e2feffcee89f050b621"},{"author":{"_account_id":17860,"name":"Samuel de Medeiros Queiroz","email":"samueldmq@gmail.com","username":"samueldmq"},"change_message_id":"7ffeea02038568656f1a8d672398f1bb38dba351","unresolved":false,"context_lines":[{"line_number":97,"context_line":"Dependencies"},{"line_number":98,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":99,"context_line":""},{"line_number":100,"context_line":"Related to but not dependant on:"},{"line_number":101,"context_line":"- Extended Password Auth with optional MFA"},{"line_number":102,"context_line":"- Credential Encryption"},{"line_number":103,"context_line":"- `Support TOTP credential \u003chttps://review.openstack.org/#/c/279854\u003e`_"}],"source_content_type":"text/x-rst","patch_set":8,"id":"7a77a97e_e2a9dae0","line":100,"range":{"start_line":100,"start_character":0,"end_line":100,"end_character":32},"updated":"2016-11-16 13:48:59.000000000","message":"(nit) I\u0027d add related things on the references section","commit_id":"4f14924867f929cf74ca8e2feffcee89f050b621"},{"author":{"_account_id":10420,"name":"Adrian Turjak","email":"devs+openstack@uncaught-exceptions.com","username":"adriant"},"change_message_id":"d96bb7e754a7a8002997403de326079c64b41f4a","unresolved":false,"context_lines":[{"line_number":97,"context_line":"Dependencies"},{"line_number":98,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":99,"context_line":""},{"line_number":100,"context_line":"Related to but not dependant on:"},{"line_number":101,"context_line":"- Extended Password Auth with optional MFA"},{"line_number":102,"context_line":"- Credential Encryption"},{"line_number":103,"context_line":"- `Support TOTP credential \u003chttps://review.openstack.org/#/c/279854\u003e`_"}],"source_content_type":"text/x-rst","patch_set":8,"id":"7a77a97e_c65a1550","line":100,"range":{"start_line":100,"start_character":0,"end_line":100,"end_character":32},"in_reply_to":"7a77a97e_e2a9dae0","updated":"2016-11-17 00:39:43.000000000","message":"Makes sense, will move them.","commit_id":"4f14924867f929cf74ca8e2feffcee89f050b621"},{"author":{"_account_id":6804,"name":"bruce-benjamin","email":"bruce.benjamin@jhuapl.edu","username":"bruce-benjamin"},"change_message_id":"056b6e11bf8cd0349b3e92af6d3440b01349355c","unresolved":false,"context_lines":[{"line_number":113,"context_line":"References"},{"line_number":114,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"None"}],"source_content_type":"text/x-rst","patch_set":8,"id":"7a77a97e_361802d3","line":116,"range":{"start_line":116,"start_character":0,"end_line":116,"end_character":4},"updated":"2016-11-18 15:54:35.000000000","message":"I\u0027d suggest you include these references and call them out in the text: \nhttp://docs.openstack.org/developer/keystone/auth-totp.html\nhttps://github.com/google/google-authenticator\nhttps://tools.ietf.org/html/rfc6238\nhttps://tools.ietf.org/html/rfc4226","commit_id":"4f14924867f929cf74ca8e2feffcee89f050b621"},{"author":{"_account_id":18666,"name":"Chris Plock","email":"chrisplo@cisco.com","username":"plockc"},"change_message_id":"5b22eec92b5ef49df8e81ad7f8fd39bd219cd81b","unresolved":false,"context_lines":[{"line_number":113,"context_line":"References"},{"line_number":114,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"None"}],"source_content_type":"text/x-rst","patch_set":8,"id":"7a77a97e_1c9eb606","line":116,"range":{"start_line":116,"start_character":0,"end_line":116,"end_character":4},"in_reply_to":"7a77a97e_361802d3","updated":"2016-11-19 01:56:22.000000000","message":"Maybe this one too?\nhttps://review.openstack.org/#/c/274901/","commit_id":"4f14924867f929cf74ca8e2feffcee89f050b621"},{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"8be2f3c712386d5a280446e15ee49b48348c5f7f","unresolved":false,"context_lines":[{"line_number":25,"context_line":"Proposed Change"},{"line_number":26,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":27,"context_line":""},{"line_number":28,"context_line":"Add new API endpoints very similar to the current ec2 one, specific to"},{"line_number":29,"context_line":"TOTP credential management on a per user basis."},{"line_number":30,"context_line":""},{"line_number":31,"context_line":"It would allow a user to create a TOTP credential scoped to them, list ones"}],"source_content_type":"text/x-rst","patch_set":9,"id":"7a77a97e_e973bde5","line":28,"updated":"2016-11-21 21:23:33.000000000","message":"I think we need to elaborate on why we need a new API endpoint here. This raises a maintenance red flag for me since we\u0027re introducing a new API for functionality we already have through another API.\n\nIf we have deficiencies in our existing credential API, maybe we need to consider refactoring it so that we don\u0027t have to introduce a whole new API to solve the problem above.","commit_id":"f47501e06fcf5a5834a8345d8bb4deef2725d812"},{"author":{"_account_id":10420,"name":"Adrian Turjak","email":"devs+openstack@uncaught-exceptions.com","username":"adriant"},"change_message_id":"404a195aeff1f8251bdda78ca64199867246e502","unresolved":false,"context_lines":[{"line_number":25,"context_line":"Proposed Change"},{"line_number":26,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":27,"context_line":""},{"line_number":28,"context_line":"Add new API endpoints very similar to the current ec2 one, specific to"},{"line_number":29,"context_line":"TOTP credential management on a per user basis."},{"line_number":30,"context_line":""},{"line_number":31,"context_line":"It would allow a user to create a TOTP credential scoped to them, list ones"}],"source_content_type":"text/x-rst","patch_set":9,"id":"7a77a97e_4193a54f","line":28,"in_reply_to":"7a77a97e_e973bde5","updated":"2016-11-21 23:36:56.000000000","message":"I started answering this and ended up writing more than I expected, so will just add it as a comment on the patch itself.","commit_id":"f47501e06fcf5a5834a8345d8bb4deef2725d812"},{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"8be2f3c712386d5a280446e15ee49b48348c5f7f","unresolved":false,"context_lines":[{"line_number":30,"context_line":""},{"line_number":31,"context_line":"It would allow a user to create a TOTP credential scoped to them, list ones"},{"line_number":32,"context_line":"they have (secret/blob should remain hidden), and delete their own TOTP"},{"line_number":33,"context_line":"credentials."},{"line_number":34,"context_line":""},{"line_number":35,"context_line":"Generation of a TOTP credential can optionally be done serverside with the"},{"line_number":36,"context_line":"response returning the generated secret."}],"source_content_type":"text/x-rst","patch_set":9,"id":"7a77a97e_c95d214a","line":33,"updated":"2016-11-21 21:23:33.000000000","message":"I assume credentials will be immutable, right?","commit_id":"f47501e06fcf5a5834a8345d8bb4deef2725d812"},{"author":{"_account_id":10420,"name":"Adrian Turjak","email":"devs+openstack@uncaught-exceptions.com","username":"adriant"},"change_message_id":"404a195aeff1f8251bdda78ca64199867246e502","unresolved":false,"context_lines":[{"line_number":30,"context_line":""},{"line_number":31,"context_line":"It would allow a user to create a TOTP credential scoped to them, list ones"},{"line_number":32,"context_line":"they have (secret/blob should remain hidden), and delete their own TOTP"},{"line_number":33,"context_line":"credentials."},{"line_number":34,"context_line":""},{"line_number":35,"context_line":"Generation of a TOTP credential can optionally be done serverside with the"},{"line_number":36,"context_line":"response returning the generated secret."}],"source_content_type":"text/x-rst","patch_set":9,"id":"7a77a97e_af13850c","line":33,"in_reply_to":"7a77a97e_c95d214a","updated":"2016-11-21 23:36:56.000000000","message":"Effectively yes. Once created a user cannot update one. Only remove, or create/upload.\n\nAt the same time, one of the arguments for making this a separate API is that we can do a special field for the delete which requires you to provide a 6 digit passcode valid for that secret.","commit_id":"f47501e06fcf5a5834a8345d8bb4deef2725d812"},{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"8be2f3c712386d5a280446e15ee49b48348c5f7f","unresolved":false,"context_lines":[{"line_number":36,"context_line":"response returning the generated secret."},{"line_number":37,"context_line":""},{"line_number":38,"context_line":"This would also allow validation of incoming secrets to ensure users are"},{"line_number":39,"context_line":"providing base32 secrets of a required minimum length."},{"line_number":40,"context_line":""},{"line_number":41,"context_line":"Compared to the alternatives this spec allows for the easiest and quickest"},{"line_number":42,"context_line":"solution to allow users to use MFA and manage their own TOTP credentials."}],"source_content_type":"text/x-rst","patch_set":9,"id":"7a77a97e_f40f142c","line":39,"updated":"2016-11-21 21:23:33.000000000","message":"We could build an existing validation mechanism into the existing implementation and turn it on using configuration.","commit_id":"f47501e06fcf5a5834a8345d8bb4deef2725d812"},{"author":{"_account_id":10420,"name":"Adrian Turjak","email":"devs+openstack@uncaught-exceptions.com","username":"adriant"},"change_message_id":"404a195aeff1f8251bdda78ca64199867246e502","unresolved":false,"context_lines":[{"line_number":36,"context_line":"response returning the generated secret."},{"line_number":37,"context_line":""},{"line_number":38,"context_line":"This would also allow validation of incoming secrets to ensure users are"},{"line_number":39,"context_line":"providing base32 secrets of a required minimum length."},{"line_number":40,"context_line":""},{"line_number":41,"context_line":"Compared to the alternatives this spec allows for the easiest and quickest"},{"line_number":42,"context_line":"solution to allow users to use MFA and manage their own TOTP credentials."}],"source_content_type":"text/x-rst","patch_set":9,"id":"7a77a97e_4f62f117","line":39,"in_reply_to":"7a77a97e_f40f142c","updated":"2016-11-21 23:36:56.000000000","message":"The problem is what we\u0027d effectively be doing is:\nif type \u003d\u003d \"totp\":\n    self.validate_totp(request)\n\nIf we did it we should do it properly such that each each type is given a plugin, and if a type does not have a plugin, then it requires admin to create/manage. That isn\u0027t a small task though, but anything else would be a ugly short term hack. A separate controller/API we can reuse most of to be a plugin later.","commit_id":"f47501e06fcf5a5834a8345d8bb4deef2725d812"},{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"8be2f3c712386d5a280446e15ee49b48348c5f7f","unresolved":false,"context_lines":[{"line_number":79,"context_line":""},{"line_number":80,"context_line":"The one downside is that if an admin sets a TOTP credential for you, the user"},{"line_number":81,"context_line":"will be able to disable it themselves. This could be avoided by making use of"},{"line_number":82,"context_line":"the extras field with an \"admin_enforced\" value, which when present and true"},{"line_number":83,"context_line":"does not allow a user to remove their own credential. TOTP enforcement though"},{"line_number":84,"context_line":"is really not within the scope of this spec nor a requirement, just a"},{"line_number":85,"context_line":"consideration of something to think about later."}],"source_content_type":"text/x-rst","patch_set":9,"id":"7a77a97e_947b407b","line":82,"updated":"2016-11-21 21:23:33.000000000","message":"What about making this a first-class attribute through a migration?","commit_id":"f47501e06fcf5a5834a8345d8bb4deef2725d812"},{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"12ad91bd11cf92e8e17bd968e424b337c6d275db","unresolved":false,"context_lines":[{"line_number":79,"context_line":""},{"line_number":80,"context_line":"The one downside is that if an admin sets a TOTP credential for you, the user"},{"line_number":81,"context_line":"will be able to disable it themselves. This could be avoided by making use of"},{"line_number":82,"context_line":"the extras field with an \"admin_enforced\" value, which when present and true"},{"line_number":83,"context_line":"does not allow a user to remove their own credential. TOTP enforcement though"},{"line_number":84,"context_line":"is really not within the scope of this spec nor a requirement, just a"},{"line_number":85,"context_line":"consideration of something to think about later."}],"source_content_type":"text/x-rst","patch_set":9,"id":"7a77a97e_ef1f1359","line":82,"in_reply_to":"7a77a97e_61b3410b","updated":"2016-11-22 15:17:25.000000000","message":"Well, I think leaving the piece about the downside is important because it makes reviewers think about the implications of the model. Whether or not the paragraph has the implementation detail around ``admin_enforced`` can be hashed out later.","commit_id":"f47501e06fcf5a5834a8345d8bb4deef2725d812"},{"author":{"_account_id":10420,"name":"Adrian Turjak","email":"devs+openstack@uncaught-exceptions.com","username":"adriant"},"change_message_id":"404a195aeff1f8251bdda78ca64199867246e502","unresolved":false,"context_lines":[{"line_number":79,"context_line":""},{"line_number":80,"context_line":"The one downside is that if an admin sets a TOTP credential for you, the user"},{"line_number":81,"context_line":"will be able to disable it themselves. This could be avoided by making use of"},{"line_number":82,"context_line":"the extras field with an \"admin_enforced\" value, which when present and true"},{"line_number":83,"context_line":"does not allow a user to remove their own credential. TOTP enforcement though"},{"line_number":84,"context_line":"is really not within the scope of this spec nor a requirement, just a"},{"line_number":85,"context_line":"consideration of something to think about later."}],"source_content_type":"text/x-rst","patch_set":9,"id":"7a77a97e_61b3410b","line":82,"in_reply_to":"7a77a97e_947b407b","updated":"2016-11-21 23:36:56.000000000","message":"Possible, but the more I think about it, the less I like the idea of enforcing totp in this manner. If we go down this path, then it will be really hard to switch to something better because what we\u0027d be doing here is effectively hardcoding something we can\u0027t easily do policy against.\n\nReally the solution would be some form of dynamic policy:\n\"users on this project can only replace/create credentials of type totp unless they have admin role\"\n\nI think I\u0027m just going to remove this paragraph from the spec because it really isn\u0027t meant to be part of the scope.","commit_id":"f47501e06fcf5a5834a8345d8bb4deef2725d812"},{"author":{"_account_id":6804,"name":"bruce-benjamin","email":"bruce.benjamin@jhuapl.edu","username":"bruce-benjamin"},"change_message_id":"3cad943dc2851688a37ef70f3e9831db237c527e","unresolved":false,"context_lines":[{"line_number":144,"context_line":"- `Credential Encryption \u003chttps://review.openstack.org/#/c/284950/\u003e`_"},{"line_number":145,"context_line":""},{"line_number":146,"context_line":"Further Reading:"},{"line_number":147,"context_line":"- `Time Based One Time Password Algorithm \u003chttps://tools.ietf.org/html\u003e`_"},{"line_number":148,"context_line":"- `Google Authenticator Key Uri Format \u003chttps://github.com/google/google-authenticator/wiki/Key-Uri-Format\u003e`_"},{"line_number":149,"context_line":""}],"source_content_type":"text/x-rst","patch_set":9,"id":"7a77a97e_6408af29","line":147,"range":{"start_line":147,"start_character":43,"end_line":147,"end_character":70},"updated":"2016-11-21 22:56:17.000000000","message":"Thanks for adding these references. It looks like you missed part of the RFC URL, since it\u0027s currently only pointing to the index. I think both of the RFCs below should be listed, since they provide important details about TOTP, they are both implemented in Google Authenticator, and your spec would support both of them.\n\nOTP: Time-Based One-Time Password Algorithm https://tools.ietf.org/html/rfc6238\n\nHOTP: An HMAC-Based One-Time Password Algorithm https://tools.ietf.org/html/rfc4226","commit_id":"f47501e06fcf5a5834a8345d8bb4deef2725d812"},{"author":{"_account_id":10420,"name":"Adrian Turjak","email":"devs+openstack@uncaught-exceptions.com","username":"adriant"},"change_message_id":"404a195aeff1f8251bdda78ca64199867246e502","unresolved":false,"context_lines":[{"line_number":144,"context_line":"- `Credential Encryption \u003chttps://review.openstack.org/#/c/284950/\u003e`_"},{"line_number":145,"context_line":""},{"line_number":146,"context_line":"Further Reading:"},{"line_number":147,"context_line":"- `Time Based One Time Password Algorithm \u003chttps://tools.ietf.org/html\u003e`_"},{"line_number":148,"context_line":"- `Google Authenticator Key Uri Format \u003chttps://github.com/google/google-authenticator/wiki/Key-Uri-Format\u003e`_"},{"line_number":149,"context_line":""}],"source_content_type":"text/x-rst","patch_set":9,"id":"7a77a97e_24e87716","line":147,"range":{"start_line":147,"start_character":43,"end_line":147,"end_character":70},"in_reply_to":"7a77a97e_6408af29","updated":"2016-11-21 23:36:56.000000000","message":"Oh blast... wrong link. Will fix.\n\nAs for HOTP, I didn\u0027t add that link because this spec explicitly does not cover HOTP. The implementation already in Keystone is TOTP only.","commit_id":"f47501e06fcf5a5834a8345d8bb4deef2725d812"},{"author":{"_account_id":7725,"name":"David Stanek","email":"dstanek@dstanek.com","username":"dstanek"},"change_message_id":"7fe6f06cccc4a6efe52a4f526a30d1045d7f2283","unresolved":false,"context_lines":[{"line_number":51,"context_line":"unrestricted creation of credentials for a user and will allow them to"},{"line_number":52,"context_line":"introduce credentials in formats which may not meet the requirements for a"},{"line_number":53,"context_line":"given credential and in turn may break other systems which interact"},{"line_number":54,"context_line":"with these credentials."},{"line_number":55,"context_line":""},{"line_number":56,"context_line":"Currently the API exposes the credentials as nothing more than a type:value"},{"line_number":57,"context_line":"store as owned by a user. To actually allow validation on a per type basis"}],"source_content_type":"text/x-rst","patch_set":10,"id":"7a77a97e_76c5973b","line":54,"updated":"2016-11-22 17:54:58.000000000","message":"Why is this the case? For known types we should validate and for unknown types it shouldn\u0027t matter anyway.","commit_id":"da31692aa4d665d11d3fa9dae286d641a5623162"},{"author":{"_account_id":10420,"name":"Adrian Turjak","email":"devs+openstack@uncaught-exceptions.com","username":"adriant"},"change_message_id":"f74905f79bc840b24742967d7eb290315f11ade1","unresolved":false,"context_lines":[{"line_number":51,"context_line":"unrestricted creation of credentials for a user and will allow them to"},{"line_number":52,"context_line":"introduce credentials in formats which may not meet the requirements for a"},{"line_number":53,"context_line":"given credential and in turn may break other systems which interact"},{"line_number":54,"context_line":"with these credentials."},{"line_number":55,"context_line":""},{"line_number":56,"context_line":"Currently the API exposes the credentials as nothing more than a type:value"},{"line_number":57,"context_line":"store as owned by a user. To actually allow validation on a per type basis"}],"source_content_type":"text/x-rst","patch_set":10,"id":"7a77a97e_d865b41d","line":54,"in_reply_to":"7a77a97e_76c5973b","updated":"2016-11-23 02:00:41.000000000","message":"I meant this part mainly as:\n\"If we just updated them to work with admin_or_owner and added no validation.\"\n\nAs that wouldn\u0027t be enough and would break things.","commit_id":"da31692aa4d665d11d3fa9dae286d641a5623162"},{"author":{"_account_id":7725,"name":"David Stanek","email":"dstanek@dstanek.com","username":"dstanek"},"change_message_id":"7fe6f06cccc4a6efe52a4f526a30d1045d7f2283","unresolved":false,"context_lines":[{"line_number":62,"context_line":"While doable, if we decide to go down this path we should do so later"},{"line_number":63,"context_line":"as part of a larger spec."},{"line_number":64,"context_line":""},{"line_number":65,"context_line":"If the above redesign to the credentials API ever occurs we can then"},{"line_number":66,"context_line":"reuse the code from this API for the later changes to the core"},{"line_number":67,"context_line":"credentials API, and migrate this API to internally use the credentials"},{"line_number":68,"context_line":"API logic as well. The same can be done for the EC2 access key API."}],"source_content_type":"text/x-rst","patch_set":10,"id":"7a77a97e_763af735","line":65,"updated":"2016-11-22 17:54:58.000000000","message":"I\u0027d rather see if a redesign is possible because if we add a new API we\u0027ll have to support it for an extended period of time. We should do it correct now.","commit_id":"da31692aa4d665d11d3fa9dae286d641a5623162"},{"author":{"_account_id":10420,"name":"Adrian Turjak","email":"devs+openstack@uncaught-exceptions.com","username":"adriant"},"change_message_id":"f74905f79bc840b24742967d7eb290315f11ade1","unresolved":false,"context_lines":[{"line_number":62,"context_line":"While doable, if we decide to go down this path we should do so later"},{"line_number":63,"context_line":"as part of a larger spec."},{"line_number":64,"context_line":""},{"line_number":65,"context_line":"If the above redesign to the credentials API ever occurs we can then"},{"line_number":66,"context_line":"reuse the code from this API for the later changes to the core"},{"line_number":67,"context_line":"credentials API, and migrate this API to internally use the credentials"},{"line_number":68,"context_line":"API logic as well. The same can be done for the EC2 access key API."}],"source_content_type":"text/x-rst","patch_set":10,"id":"5a74a57a_44ff5834","line":65,"in_reply_to":"7a77a97e_763af735","updated":"2016-11-23 02:00:41.000000000","message":"If we can find a redesign that satisfies all the possible differences between the credential types, that would be fantastic, but I\u0027m not really sure how maintainable such an API would be.\n\nThe easier approach would be to create new APIs per type (and pretend they are different models really), while keeping the raw credentials API as just a key:value store admins can use.\n\nWe already have the example with EC2 creds API, and nothing other than admins appear to actually use the credential API itself (I do, but for testing and prototyping really).\n\nThat said, while this is technically a new API it also technically falls under an extension of the user API exactly how EC2 works:\n\u0027/users/{user_id}/credentials/OS-EC2\u0027\n\u0027/users/{user_id}/credentials/OS-EC2/{credential_id}\u0027\n\nSo what I\u0027d like to do is something vaguely like (totp rather than OS-TOTP because the latter is ugly):\n\u0027/users/{user_id}/credentials/totp\u0027\n\u0027/users/{user_id}/credentials/totp/{credential_id}\u0027\n\u0027/users/{user_id}/credentials/totp/{credential_id}/activate\u0027\n\n\nI really need to add that to the spec so it is much clearer... as seeing what the API endpoints themselves looks like helps understand the purpose and use.","commit_id":"da31692aa4d665d11d3fa9dae286d641a5623162"}]}