Wednesday, 2018-09-19

*** gyee has quit IRC00:19
*** evrardjp has quit IRC01:12
*** Dinesh_Bhor has joined #openstack-keystone01:29
*** sapd1_ has joined #openstack-keystone02:04
*** sapd1 has quit IRC02:07
*** Dinesh_Bhor has quit IRC02:22
openstackgerritVishakha Agarwal proposed openstack/keystone master: Adding test case for MappingEngineTester
*** Dinesh_Bhor has joined #openstack-keystone02:31
*** jistr has quit IRC03:00
*** jistr has joined #openstack-keystone03:00
*** BlackDex has quit IRC03:01
*** BlackDex has joined #openstack-keystone03:03
openstackgerritTao Li proposed openstack/keystone master: Use uuidutils instead of uuid.uuid4()
*** Dinesh_Bhor has quit IRC03:28
*** Dinesh_Bhor has joined #openstack-keystone03:34
*** Dinesh_Bhor has quit IRC03:42
*** prashkre has joined #openstack-keystone03:45
*** prashkre has quit IRC03:51
vishakhawxy-xiyuan: Hello. Can you pl review this test caes
*** jaosorior_ is now known as jaosorior04:13
vishakhacmurphy: Pl have a look on Need one more +204:14
*** Dinesh_Bhor has joined #openstack-keystone04:32
*** shyamb has joined #openstack-keystone05:24
*** shyamb has quit IRC05:29
*** rcernin has quit IRC05:30
*** rcernin has joined #openstack-keystone05:30
*** shyamb has joined #openstack-keystone05:50
*** rcernin_ has joined #openstack-keystone06:04
*** rcernin has quit IRC06:06
*** rcernin has joined #openstack-keystone06:34
*** rcernin_ has quit IRC06:36
*** deepak_mourya_ has quit IRC06:40
openstackgerritColleen Murphy proposed openstack/keystone master: Convert legacy functional jobs to Zuul-v3-native
*** shyamb has quit IRC07:04
*** rcernin has quit IRC07:06
*** Dinesh_Bhor has quit IRC07:09
*** shyamb has joined #openstack-keystone07:10
*** shyamb has quit IRC07:17
*** hoonetorg has quit IRC07:17
*** sonuk has joined #openstack-keystone07:18
*** shyamb has joined #openstack-keystone07:27
*** hoonetorg has joined #openstack-keystone07:30
*** Dinesh_Bhor has joined #openstack-keystone07:36
*** jamiec has quit IRC07:38
*** blake has joined #openstack-keystone07:38
*** jamiec has joined #openstack-keystone07:43
*** shyamb has quit IRC07:45
openstackgerritTao Li proposed openstack/keystone master: Use uuidutils instead of uuid.uuid4()
*** Emine has joined #openstack-keystone08:06
*** blake has quit IRC08:32
*** shyamb has joined #openstack-keystone08:38
*** shyamb has quit IRC08:43
*** shyamb has joined #openstack-keystone08:43
*** markvoelker has quit IRC09:25
*** shyamb has quit IRC09:29
*** shyamb has joined #openstack-keystone09:30
*** shyamb has quit IRC09:41
*** shyamb has joined #openstack-keystone09:45
*** Dinesh_Bhor has quit IRC09:49
*** Dinesh_Bhor has joined #openstack-keystone09:52
*** shyamb has quit IRC09:57
*** shyamb has joined #openstack-keystone10:00
*** Dinesh_Bhor has quit IRC10:04
*** shyamb has quit IRC10:05
*** markvoelker has joined #openstack-keystone10:30
*** shyamb has joined #openstack-keystone10:33
*** Dinesh_Bhor has joined #openstack-keystone10:37
*** Dinesh_Bhor has quit IRC10:39
*** pooja_jadhav has quit IRC10:40
*** shyamb has quit IRC10:49
*** shyamb has joined #openstack-keystone10:49
*** pooja_jadhav has joined #openstack-keystone10:56
*** pooja-jadhav has joined #openstack-keystone10:57
*** markvoelker has quit IRC11:00
*** shyamb has quit IRC11:06
*** imacdonn has quit IRC11:19
*** imacdonn has joined #openstack-keystone11:20
openstackgerritJuan Antonio Osorio Robles proposed openstack/oslo.policy master: Implement base for pluggable policy drivers
*** raildo has joined #openstack-keystone11:56
*** markvoelker has joined #openstack-keystone11:57
*** shyamb has joined #openstack-keystone12:15
*** pgaxatte has joined #openstack-keystone12:30
*** markvoelker has quit IRC12:31
pgaxatteI have an issue with keystone middleware in rocky12:32
pgaxatteI'm trying mistral and I use a memcache server12:32
pgaxattewhen installing mistral in a venv, I noticed I don't have python-memcached installed which causes an ImportError in keystonemiddleware12:33
pgaxattehere precisely:
pgaxattepython-memcached seems only required for the tests (according to the METADATA file of the egg)12:35
*** kukacz_ is now known as kukacz13:00
openstackgerritColleen Murphy proposed openstack/keystone master: Convert legacy functional jobs to Zuul-v3-native
mbeierlHey, knikolla, wondering if you've got any time to help with the keystone/shibboleth federation.  I got past the PAOS response error, but am still stuck with a fatal profile exception13:03
openstackgerritColleen Murphy proposed openstack/keystone master: Convert legacy functional jobs to Zuul-v3-native
mordredcmurphy: tox_envlist: all ?13:26
mordredcmurphy: would tox_envlist: functional be a better choice there?13:27
cmurphymordred: hi do you want to help me13:27
cmurphyi'm following
mordredOH -13:28
mordredthat's going to run tox in the tempest repo13:28
* mordred isn't always smart13:28
cmurphyheh okay13:29
cmurphybecause without it this was happening
mordredyeah. makes totally more sense now13:29
cmurphyi still don't know what i'm doing though, just trying to poke it till it works13:30
cmurphylbragstad: do you have advice for pgaxatte ^ i don't remember where we landed on that13:37
lbragstadon making python-memcache a hard requirement?13:38
lbragstadi don't remember a clear outcome :(13:38
lbragstadI think my initial knee-jerk reaction is to just include it officially13:39
lbragstad(i thought something with memcache was python three related, though)13:39
aningHi guys, is application credential stable in queens release?13:39
lbragstadaning it is13:42
lbragstadqueens was the initial release of application credentials and they were marked as stable from the beginning13:42
aningWhat other openstack services support application credentials if any?13:43
aningIs there any information about that?13:43
cmurphyapplication credentials are mostly meant to be used by end users, but any openstack service that uses keystonemiddleware automatically supports using application credentials for service user authentication13:47
aningcmurphy: but do we have to configure the [keystone_authtoken] section of the openstack service in order for it to use application credential?13:49
cmurphyaning: yes, there's an example here
aningIs it that once the service is configured with application credential, the service just natively and automatically use it?13:51
aningcmurphy: yep, I'm readning that document13:52
cmurphyaning: after creating the application credential and configuring [keystone_authtoken] like that it should just work13:52
aningcmurphy: ok ... I'm thinking does the service need some (extra) logic to read, understand, and send the application credential to keystone for authentication?13:54
aningIf this is all handled by keystonemiddleware, I could understand the serive doesn't need any change ...13:55
cmurphyaning: no, the service shouldn't need to do anything special, it's all handled in keystonemiddleware and keystoneauth13:55
aningcmurphy: yeah, got it.13:55
aningcmurphy: btw, which table is the application credential hash stored?13:57
cmurphyaning: 'application_credential'13:58
cmurphy'credential' is for something else13:59
aningcmurphy: so a new table is introdued.14:00
cmurphyaning: yes14:00
aningcmurphy: thx14:01
cmurphyaning: np14:02
*** shyamb has quit IRC14:03
lbragstadthat reminds me - i'd like to try and work on an example for using app creds for a single support user14:11
lbragstadin case anyone wants to double check my work -
lbragstad^ those are very similar deadlines to what we used for Queens14:46
*** aning_ has joined #openstack-keystone14:51
*** marvin_mhg has quit IRC14:53
*** aning has quit IRC14:54
lbragstadhrybacki the audit that gmann did here here is kind of similar to what you were doing (minus adding the granularity)
*** aning has joined #openstack-keystone14:55
* hrybacki looks14:57
*** aning_ has quit IRC14:57
hrybackilbragstad: looking at specs on gerrit can be the worst. I'll review that this afternoon14:58
lbragstadyep - no problem14:59
pgaxattecmurphy, lbragstad: reading keystonemiddleware code I don't understand the comment
pgaxatteit says to rely on oslo_cache to lazily import memcache15:06
pgaxattebut having oslo.cache also in my virtualenv has not added python-memcached as a dependency15:07
pgaxattealso, as soon as there is an "import blah" in the code, shouldn't it make the package blah a hard dependency?15:07
cmurphykmalloc: want to comment on that ^15:08
*** Emine has quit IRC15:10
hrybackikmalloc: I'm looking at the API ref to but can't find anything the HEAD endpoints for the v3/projects/<id>/tags and ve/projects/<id>/tags/<value> -- should they respond in the same way as a GET in this case?15:12
kmallochrybacki: head uses get unless explicitly defined.15:12
kmallocIf the behavior of head is fundamentally different than get (some of our APIs) then implement head specifically15:13
kmalloccmurphy: answering now15:13
hrybackikmalloc++ thanks for confirming. So how are we handling that with flask? /me keeps digging15:13
kmallochrybacki: just implement head when needed.15:14
hrybackiah, 'magic'15:14
kmallochrybacki: otherwise just let get work how it is supposed to (same behavior between head and get)15:14
kmallochrybacki: flask automatically removes content on head if it falls through to get (flask restful)15:15
kmallocpgaxatte: so, in our code, most of the time you can use different options on the backend. If you never use memcache, there is no reason to install it.15:17
kmallocpgaxatte: so, it is not a hard dep. Many folks use other options/no caching.15:17
kmallocpgaxatte: if it was pymemcache vs python-memcached we might make it a hard dep.15:18
kmalloccmurphy: ^ :)15:18
cmurphykmalloc: ty15:18
pgaxattekmalloc: I understand but this makes mistral, in my case, break horribly15:18
kmallocpgaxatte: explicitly add python-memcached in Mistral or just know you need to install it.15:19
pgaxattekmalloc: so I should install python-memcached separately as a dependency of my architecture15:19
kmallocI have moving to pymemcache on my backlog15:19
kmallocIt is pretty far down my list right now (sorry)15:19
kmallocI hope I can do it in stien, but am not sure.15:20
pgaxatteshould the "import memcache" at least by protected in case of ImportError?15:20
pgaxattebecause in my case, mistral throws a 500 and no message, no log, nothing15:21
pgaxatteI took me some time to find the root cause with pdb :D15:21
kmallocNot sure, can you point me at where this is happening? I want to know the context before answering.15:27
pgaxattekmalloc: I need to dig back in mistral to find the exact place this is happening15:28
kmallocBecause it might indicate Mistral needs it independently.15:28
cmurphy_MemcacheClientPool should only be instantiated if you have memcached_servers set in keystonemiddleware so you have to opt into it and you're assumed to have installed the dependencies if you do that15:29
kmalloccmurphy: ahh thats it.15:30
*** gyee has joined #openstack-keystone15:37
*** pcaruana has joined #openstack-keystone15:47
pgaxattekmalloc: ok so I cannot pinpoint the start of the problem in mistral but the middleware is added here:
pgaxattethis might not be helpful :D15:58
pgaxattethe problem occurs in the process_request of AuthProtocol15:58
kmallocYeah, it's a config bit, for now, install python-memcached as part of the architecture15:59
pgaxattekmalloc: alright, i'll do that15:59
pgaxattethanks ;)15:59
openstackgerritMerged openstack/keystone-tempest-plugin master: Import another job from project-config
*** pcaruana has quit IRC16:27
tobias-urdinheads up on broken keystone q->r upgrade path16:28
openstackLaunchpad bug 1793347 in OpenStack Identity (keystone) "keystone upgrade fails q->r oslo.log requirement to low" [Undecided,New]16:28
openstackgerritMerged openstack/keystone master: Use templates for cover and lower-constraints
aningcmurphy: I'm reading your blog at Looks like queens support both SAML2.0 WEBSSO and ECP. The setup with keystone and horizon is based on WEBSSO, and the k2k setup is based on ECP.  Do I understand right?17:04
tobias-urdinlbragstad: ping on launchpad link above fyi17:04
gagehugotobias-urdin lbragstad likely didn't get added until 3.37.017:34
lbragstadtobias-urdin there is a patch up for review
cmurphyaning: yes, mostly; keystone as a service provider can work with both websso and ecp, and using horizon depends on websso. when keystone is in a k2k setup it doesn't have websso support, so horizon relies on a kind of modified ecp flow on the backend18:16
aningcmurphy: Can I setup a keystone as SP with an external Idp (instead of keystone) and use ECP for the user agent to authenticate itself?18:22
aningcmurphy: the reason is that we may have an application (based on keystone client) that will use federated authentication.18:24
gagehugolbragstad can we not bump oslo.log in rocky?18:25
lbragstadgagehugo sounds like it violates stable policy18:25
lbragstadgagehugo we need to check with tonyb18:25
lbragstadsounds like he wants to better understand why it failed18:26
cmurphyaning: yes that is possible, it relies on the IdP supporting ECP (not all of them do) and the apache SP may need to have ECP turned on (shibboleth has it turned off by default)18:26
cmurphylbragstad: i think tonyb is on vacation for a couple of weeks18:27
lbragstadthanks cmurphy18:27
*** AJaeger has left #openstack-keystone18:28
aningcmurphy: so still relay on the apache SP mod (such as shiboketh)18:29
cmurphyaning: yes18:31
aningcmurphy: the user agent application, does keystoneclient support ECP already?18:32
aningcmurphy: since the user agent will talk to shiboleth mod in SAML ECP ...18:33
cmurphyaning: keystoneauth supports it which means keystoneclient and openstackclient also support it18:34
aningcmurphy: cool. I'll check if there are APIs for ECP Response ...18:34
aningcmurphy: the support should be in form of APIs right?18:35
aningcmurphy: or maybe not18:38
cmurphyaning: hmm not sure what you mean by in the form of APIs, if you pass it the right credentials and parameters it will get you a token which gives you normal access to all the openstack apis18:40
aningcmurphy: ok IC. same idea, it;s all handled in the background by keystoneauth18:41
*** jdennis has quit IRC18:51
*** ayoung has joined #openstack-keystone18:53
ayounghrybacki, kmalloc in a customer presentation at the moment.  Not sure if it will go long.  Have to wait til its over to switch to talking with you18:56
*** BlackDex has quit IRC18:57
kmallocAll good, just ping when done.18:57
hrybackiayoung: ack18:57
kmallocI am not on the thing yet18:57
*** BlackDex has joined #openstack-keystone18:58
hrybackiayoung: kmalloc I've got a few hurricane victims that are coming over to get settled -- might not be until after the mtg -- but will have to drop to help them for a bit18:59
hrybackikmalloc: wanna join now? I have some questions I can field off of you in the meantime18:59
kmallochrybacki: yeah joining now19:01
kmallocbtw, no mic/headset so dealing with laptop mic (gross)19:02
lbragstadcmurphy i ended up just putting most of the feedback for documentation improvements into a single report -
openstackLaunchpad bug 1793374 in OpenStack Identity (keystone) "Federated documentations lacks a concise introduction" [Low,Triaged]19:32
cmurphylbragstad: okay19:33
lbragstadalso - i was wrong about the document that jdennis authored19:33
cmurphylbragstad: i'm just gonna assign it to myself19:34
lbragstadi thought he wrote something for federation, but it was actually for PCI-DSS19:34
cmurphylbragstad: i thought he wrote all the deep-dive mod_auth_mellon docs19:35
lbragstadare those already in our docs?19:35
cmurphylbragstad: no, they're in mod_auth_mellon's docs
lbragstadoh - interesting19:36
lbragstadi wonder if we should just point to that if we don't already19:39
cmurphyi think the last time i touched our docs all that mellon had was the github readme19:40
lbragstadi remember sitting down with asettle, dolphm, and dstanek about 3 years ago, and we were talking pretty much the same thing as whats in
openstackLaunchpad bug 1793374 in OpenStack Identity (keystone) "Federated documentations lacks a concise introduction" [Low,Triaged] - Assigned to Colleen Murphy (krinkle)19:41
aningcmurphy: lbragstad: a deep-dive document would be great!19:42
cmurphyaning: check out the mod_auth_mellon user guide it gives a ton of useful background on SAML even if you're not using the mellon SP19:45
aningcmurphy: thx19:46
openstackgerritGage Hugo proposed openstack/keystone master: [WIP] Add functional testing gate
openstackgerritGage Hugo proposed openstack/keystone master: [WIP] Add functional testing gate
openstackgerritMerged openstack/keystone master: Remove unused revoke_by_user_and_project
*** dklyle has quit IRC20:47
*** raildo has quit IRC20:54
*** dklyle has joined #openstack-keystone21:42
adriantlbragstad: regarding all the policy and role work, is there an option to sneak an 'auth-only' role into the mix? A role that lets you do pretty much nothing other than maybe change your own password, and exist within a project scope (but with no permissions to any resources in it).21:45
lbragstadwe actually don't protect authentication or password changes with policies21:46
lbragstad(how do you verify the roles a user has at authentication time)21:46
adriantlbragstad: sorry, just had to run to morning standup21:57
adriantmy context is...21:57
adriantright now we have a lot of default policies in openstack. They amount to "user is authed"21:58
adriantwhich makes it really hard to go through and actually make roles that aren't affected by these default policies21:58
adriantif ALL the policy rules required a role, unless explicitly meant not to, then we can make roles that by default are no-ops21:59
adriantthis is useful in a few ways for me, but one... is Swift21:59
adriantSwift ACLs kind of conflict with Keystone roles, and to really use swift ACLs properly with users, or auth creds, you need a user that is auth'd but can't do anything so the ACLs can be assigned to them with the knowledge they can only do Swift things22:00
adriantSo a role that explicitly lets you do almost nothing, but can be used to give a user scope within a project, suddenly solves a lot of the Swift ACLs vs Keystone roles issues22:02
lbragstaddoes swift fall through if there are roles in the token used to access it's API?22:03
lbragstadbut it needs a project...22:03
adriantwell no, it needs an auth'd user22:04
lbragstadso - this might be a naive question, but can't you use an unscoped token?22:04
adriantbut I don't know if an unscoped token is quite enough, but you can do ACLs per project so a no-op role would be useful for limiting that22:04
adriant"A token for the user (scoped to any project)"22:05
*** jdennis has joined #openstack-keystone22:05
adriantso looks like not, but I've never actually tested it22:05
lbragstadso it does require a project...22:05
adriantbasically, if "member" lets you access all the containers in a project in Swift, then the ACLs are bypasses22:05
lbragstadand that's not what you want?22:06
lbragstadbecause you want to do more granular things with the ACLs?22:06
adriantI could assign member in a different project...22:06
adriantbut that's awful22:06
lbragstadso - we can't actually use policies for protecting authenticate22:07
lbragstadauthenticate doesn't actually have a policy22:07
adriantthat's not what I need though22:07
lbragstadso... what you could do22:08
adriantwe want a user to be auth'd, just don't do the default policy stuff which is 'an authed user' and instead make all the policies actually require explicit roles22:08
adriantwe've kind of done that internally, but finding and actually cleaning up all those empty default policies is annoying with some of the older policy files :(22:09
adriantlike, we use the member role as an explicit requirement for most API calls.22:09
lbragstadso - if you have a role called 'noop' and you give it to me on project foo, that doesn't work?22:09
adriantit does in our case22:10
adriantand with the upstream policy work you're doing with the new default roles, (read/write?) you are making most API calls explicit?22:10
adriantthe policy I mean22:10
lbragstadwe're going to provide new defaults, yes22:11
lbragstadand fit each API into one of three camps22:11
lbragstadso - read operations will need the 'reader' role at the very least22:11
lbragstad(e.g. getting or listing resources)22:11
adriantcool, I just wanted you to be aware of the usefulness as part of that work of an noop type role22:11
adriantor well, any new role by default would be a noop role22:12
lbragstadunless they are implied22:12
lbragstadwhich they are in our case22:12
lbragstadadmin implies member which implies reader22:12
lbragstadso if you have the member role on a project, you get the ability to perform list operations22:13
adriantand are you making 'reader' explicitly defined in the new default policy as a requirement?22:14
adriante.g. for a list "role:read"22:15
adriantwhich then the implied stuff handles?22:15
*** jdennis has quit IRC22:15
lbragstadit seemed like an appropriate compromise22:15
lbragstadinstead of defining something like "identity:list_users": "role:admin OR role:member OR role:reader"22:16
lbragstadinstead we just do "identity:list_users": "role:reader"22:16
adriantfantastic, then yes, hopefully by the end of that work, the default policies will allow an easy noop still role since there should be far far less empty policies22:16
lbragstadi guess i'm still a little lost on how the empty policies break that22:16
adriant"identity:list_users": "" < any auth'd user can call this API22:17
adriantvs "identity:list_users": "role:reader" where it must have a specific role22:18
adriantI know a lot of the various API just assume if you exist as a user in project scope, you can call APIs for resources on that project22:18
lbragstadso you've gone through and actually made those changes by overriding the policies so that I can't access something i'm not supposed to because I have a role called "swift-noop"22:19
lbragstadfrom a keystone perspective, there shouldn't be many empty policies i don't think?22:20
adriantwe're having to do that because all the empty rules are kind of too powerful still22:20
adriantnah, Keystone is pretty good22:20
adriantit's all the other services22:20
adriantnova was pretty bad22:20
adriantso many empty rules22:20
adriantBut it sounded like you were driving part of the cross project effort22:20
lbragstadit's a long ways away22:20
lbragstadwe need to build out the system-scope and new default roles in keystone so that other services at least have a reference to follow22:21
adriantso I thought you should be aware of the pain we're going through internally trying to fill all the blank rules.22:21
lbragstadafter that we might try and make it a community goal22:21
adriantok cool22:21
lbragstadif anyone from catalyst is interested in working on that upstream or pushing it forward, just ask...22:23
lbragstadwe should be able to break thing apart into bite-sized pieces22:23
adriantI'd gladly raise my hand, but I have so many things on my plate right now22:23
adriantBut I'll probably raise my hand anyway closer to the time22:24
lbragstadi hear ya22:24
adriantI've had a post-it on my wall for ages now to try and get this policy work done on our cloud so we can safely do an 'auth-only' role, and part of that was going to be review all our policies and play with patrole22:25
adriantall I want the role to do is be able to auth, update own password, and setup MFA for self, but first I need to make sure we've not left any other policies open :(22:26
adriantit's a pain22:26
adriantlbragstad, kmalloc: I'll try and have a new auth-receipts patch up soonish.22:28
adriantI want to try and get a large part of the MFA work done before the summit22:28
lbragstadyeah - i guess if you were to do a really limited role you could create something like 'auth-only'22:30
lbragstadand then have reader imply it22:30
lbragstadthen if there are any APIs that you want them to have access to (which I'm assuming wouldn't be many) you'd just override those to be role:auth-only instead or role:reader22:31
adriantpretty much.22:32
*** jdennis has joined #openstack-keystone22:33
adriantI've yet to play with implied roles much on our cloud, but will be doing something soon for resellers22:33
lbragstadit's pretty straight forward...22:33
lbragstadif you have a role assignment that implies another role, we just expand the token reference to include both during token validaiton22:34
adriantwe have a bunch of APIs we can't have resellers seeing so I'll have reseller_member imply member, and then the policy rule will read "role:member AND NOT role:reseller_member"22:34
lbragstadwhat kind of APIs can't resellers see?22:34
lbragstadlike deployment-specific stuff?22:34
adriantaccount admin and billing ones22:34
lbragstaddid you happen to see my patch for the credentials work?22:35
adriantwe talking app creds or 'credentials' ?22:35
lbragstadit is failing two tests...22:36
cmurphywe are the best at naming22:36
lbragstad^ fact22:36
adriantnaming things is hard :P22:36
* kmalloc kills "credentials" with something sharp22:36
adriant"secrets" ?22:37
lbragstadi mean... we *did* renaming tenants to projects....22:37
adriantjust rename them to secrets, because that is closer to what they are22:37
kmalloc"no really, this stuff should have been in barbican.. but we made some bad design decisions"22:37
adriantalthough barbican might complain22:37
lbragstadit's like we get bonus points if we overload the term, too22:37
kmalloci think that is the official name22:37
adriantself service elements to the credentials APIs would be good, but I'm willing to bet you people will end up using it, and the MFA rules directly and locking themselves out of their own users ;)22:39
lbragstadbut yeah - that patch is a WIP for trying in make the credentials API more self-serviceable22:39
lbragstadwe want to try and that applied consistently across stein22:39
lbragstadwhich will mean two things22:39
lbragstad1.) scope will be honored better than it is today22:39
adriantI say do it, but I'll write some sanity checking APIs in Adjutant for MFA management most likely22:39
lbragstad2.) policies will incorporate the new default roles22:40
lbragstadthat would make things easier for adjutant, right?22:40
lbragstadbecause you can just consume what we've done instead of having to write a layer on top that handles that?22:40
adriantI'd still use the admin level powers really unless I reuse the user token22:40
adriantpotentially yeah22:41
*** hoonetorg has quit IRC22:41
adriantI need to read through the patch!22:41
lbragstadyeah - i'd be curious to know if you have feedback22:41
lbragstadsince it sounds like adjutant has worked around a lot of this stuff22:41
adriantright now we do MFA a little differently since we aren't yet touching auth rules, hence why the MFA code isn't in core Adjutant22:42
adriantbut the eventual logic will be: "ask for a totp secret (which adjutant creates as a credential in keystone)" > "pass back a passcode" > "Adjutant validates passcode and adds auth rules for totp to user"22:43
adriantwhich doesn't exactly need a self service API since the user never touches credentials directly22:43
adriantor auth rules22:43
adriantand turning off totp is pretty much: "pass back a passcode" > "Adjutant validates passcode and removes auth rules for totp from user"22:44
adriantso again, user can't touch credentials directly22:44
*** rcernin has joined #openstack-keystone22:44
adriantsince that bypasses the need for them to prove they have the totp secret twice (once for auth, again for removal)22:45
adriantbut... without Adjutant around, self service is useful, but prone to accidentally doing things a little wrong without hand holding22:46
adriantI can always as part of the Adjutant setup docs include: "update these keystone policies to turn off self service"22:46
lbragstadwe do some interesting stuff in the policies to make sure the user can do that stuff, which might be interesting if you try to shut it off22:47
lbragstadfor example - how these are changing
lbragstadand how we are modifying the business logic of the API to account for it
lbragstadnotice the other half of the policy check strings22:49
lbragstadwe do "user_id:%(target.credential.user_id)s" to make sure the credential can be self-serviceable by its owner22:50
adriantI'd probably turn those off with: "role:admin and system_scope:all" and no 'OR' option22:51
adriantwhich should work... i think22:51
lbragstadyeah - that would mean you'd need to be a system admin to do anything with that22:51
adriantand Adjutant acts as one with it's user, so that's ok22:52
adriantalthough I know I'll need to change that a bit in Adjutant itself22:52
adriantbecause is still assuming project scope and "admin"22:52
adriantI like the changes. Will mean by default 'owner' can see their own creds, and if not system scoped the API is explicitly written to return only your user creds22:55
adriantnot that I have any use for it right now, but we're not doing anything with ?22:56
*** hoonetorg has joined #openstack-keystone22:58
*** mvkr has joined #openstack-keystone23:10
*** dklyle has quit IRC23:29

Generated by 2.15.3 by Marius Gedminas - find it at!