Wednesday, 2016-11-30

openstackgerritMerged openstack/keystone: Removes unused default_assignment_driver method  https://review.openstack.org/40441100:12
openstackgerritMerged openstack/keystone: Removes unused method from assignment core  https://review.openstack.org/40441200:12
mordredjamielennox: yah - I hear that. however, the mechanics of submitting a task to the task manager should generally speaking not be a thing users have to think about ever (and I think we can rework the general_request_class part for sure)00:22
mordredfor the basic case, nobody should ever know it exists - for the advanced case, the thing a user _might_ want to do is pass in a class that implements the TaskManager interface00:24
jamielennoxyep i see that, i commented on the review00:24
jamielennoxthe taskmanager you have now is definitely intended to be outside the client interface00:24
jamielennoxso really if you want to do things like rate limit all you need is a context manager as per comment right?00:25
* mordred goes to read00:25
jamielennoxlooking through shade you are doing things like task_manager.submit(TheTask)00:25
openstackgerritGage Hugo proposed openstack/keystone: Add reason to notifications for PCI-DSS  https://review.openstack.org/39675200:25
mordredyah- nodepool has a different TaskManager it passes to shade's constructor currently00:25
jamielennoxah, nodepool makes sens00:26
jamielennoxi'm learning more and more about the wonderous nodepool00:26
mordredand then in https://review.openstack.org/#/c/384206/ is where I'm starting down the adapter wrapper path ...00:26
jamielennoxi wouldn't be surprised to find a sacrifice_kitten() rpc deep down there00:26
mordredwhich leads to fun like this: https://review.openstack.org/#/c/384208/15 - where eventually we'll not have any submitTask calls in shade00:26
mordredjamielennox: it's there for sure :)00:27
*** adu has joined #openstack-keystone00:27
mordredjamielennox: turns out, to use openstack at high volume, one must have a steady supply of kittens ...00:27
jamielennoxi mean $30 a month must buy more that 1 cpu and 512mb ram...00:27
* jamielennox didn't consult any providers for that price00:28
mordred:)00:28
mordredjamielennox: honestly - I think the contextmanager idea could work from a ksa perspective in terms of execution - lemme circle back around on it and take a stab at that so I can either answer why it _won't_ work or it can be  apath forwar00:30
mordred(I have a thought in my head, but I need to sacrifice a few kittens to test it out)00:30
jamielennoxso looking at https://review.openstack.org/#/c/384206/12/shade/_adapter.py we're already starting to ignore the client to RequestTask.main()00:30
jamielennoxas in the only thing you're doing there really is wrapping request_method in a task00:31
jamielennoxi mean again the interesting thing here is that the only interface between ksa.session and requests.Session is the .request() method and you can pass in your own session to ksa00:32
jamielennoxso really the easiest way i can see to do it today is00:32
jamielennoxclass ShadeSession(requests.Session):00:32
jamielennox    def request(*args, **kwargs):00:33
jamielennox        # something that rate limits00:33
jamielennox        return super(ShadeSession, self).request(*args, **kwargs)00:33
mordredyah - I have a patch with that somewhere in the history - I needed to change to adapter for reasons I don't fully remember00:33
jamielennoxs = session.Session(session=ShadeSession())00:33
jamielennoxoh yea, change adapter as well00:33
jamielennoxmodifying adapter gives you a bunch of other capabilities00:34
jamielennoxbut if you want to get underneath the covers and catch things like reauthentication that is handled behind the scenes you can catch it there00:34
jamielennoxnot using the clients here will save much pain :)00:35
mordredvery very much pain00:35
mordredoh right - that's why I did adapter00:35
mordredwhen I did session ...00:35
mordredit caught _everything_00:35
mordredbut that means that there would be a running Task that would spin out an auth request00:35
mordredbut since we serialize tasks00:35
mordredit meant essentially a deadlock00:36
mordredwhoops00:36
mordred:)00:36
mordreddoing it at the adapter level meant that it didn't affect anything at the python-*client level that wasn't already wrapped in a Task00:36
mordredso we could swap out calls piecewise00:36
mordredwhich is, of course, preferrable00:36
*** adu has quit IRC00:40
jamielennoxthat would probably happen with the taskmanager as well im guessing00:41
mordredyah00:52
mordredmorgan: when you're back online - I'm going to start drinking - but I have an idea of addressing the above conversation ^^00:52
*** hoangcx has joined #openstack-keystone00:55
*** adrian_otto has joined #openstack-keystone00:58
morganmordred: o/01:04
mordredmorgan: tl;dr - have the bits in ksa.Session be like what jamielennox suggests - with self._contextmanager: return self.request()01:06
*** guoshan has joined #openstack-keystone01:06
morganah01:06
mordredmorgan: then have a TaskContextManager object that takes a TaskManager and wraps it01:06
mordredso that one could pass _that_ into ksa.Session and have the thing we're poking at01:07
mordredbut other people could just generally pass in context managers01:07
mordredyah?01:07
morganinteresting01:07
morgandigesting the idea01:07
mordredmorgan: it may suck01:07
morgan(and food)01:07
mordredmorgan: but seems worth poking at :)01:07
*** dave-mccowan has joined #openstack-keystone01:07
morgantrying to suss this out and reading backlog01:12
morganso we're just changing the session bit to make the taskManager run in a context manager?01:12
openstackgerritRon De Rose proposed openstack/keystone: PCI-DSS Force users to immediately change their password upon first use  https://review.openstack.org/40391601:14
*** gyee has quit IRC01:15
*** adrian_otto has quit IRC01:17
*** guoshan has quit IRC01:19
*** guoshan has joined #openstack-keystone01:21
*** liujiong has joined #openstack-keystone01:21
*** guoshan has quit IRC01:22
*** guoshan has joined #openstack-keystone01:22
*** guoshan has quit IRC01:27
*** spzala has quit IRC01:27
*** guoshan has joined #openstack-keystone01:29
mordredmorgan: well, to make the session interface a generic context manager interface01:33
*** adrian_otto has joined #openstack-keystone01:33
*** guoshan has quit IRC01:34
mordredso that what you pass to the session constructor is any old context manager - and maybe something something about being able to pass informaiton about the specific call to the context manager01:34
morganright01:34
morgantask manager just *happens* to be a context manager in this case01:34
* mordred waves hands furiously01:34
mordredyah01:34
morgansure. should be pretty straight forward.01:34
mordredor we make a thing that takes a task manager and returns a context manager we can pass in01:34
mordredor something01:34
morganand we can just make the basic taskcontext a do-nothing thing.01:35
mordredmaybe we just drink01:35
mordredyah01:35
morgani would rather drink...01:35
*** Zer0Byte__ has quit IRC01:35
mordred++01:35
* mordred having caipirinha now01:35
morganbut seeing as it is better to drink *with* people...01:35
mordredindeed01:35
morganI am going to refrain from drinking01:35
morganalso... i'd totally drink one ot the caipirinhas you make. those are damn good01:36
*** adrian_otto has quit IRC01:37
*** guoshan has joined #openstack-keystone01:39
morganmordred:  i think i can respin these patches to be context manager-style in a couple hours01:44
morgannow that I see what is intended there01:45
*** chrisplo has quit IRC01:58
*** anush has joined #openstack-keystone02:06
*** tqtran has quit IRC02:07
*** anush has quit IRC02:07
*** stevemar__ has joined #openstack-keystone02:29
*** topol has quit IRC02:46
*** browne has quit IRC02:52
*** ayoung has joined #openstack-keystone03:02
*** ChanServ sets mode: +v ayoung03:02
*** topol has joined #openstack-keystone03:14
*** ChanServ sets mode: +v topol03:14
*** code-R has joined #openstack-keystone03:20
*** code-R_ has joined #openstack-keystone03:21
*** guoshan has quit IRC03:22
*** code-R has quit IRC03:25
*** code-R_ has quit IRC03:25
*** code-R has joined #openstack-keystone03:25
*** links has joined #openstack-keystone03:28
*** tlbr has quit IRC03:44
*** tlbr has joined #openstack-keystone03:45
*** zhangjl has joined #openstack-keystone03:48
*** zhangjl1 has joined #openstack-keystone03:53
*** zhangjl has quit IRC03:55
*** nicolasbock has quit IRC03:57
*** code-R_ has joined #openstack-keystone04:04
*** code-R has quit IRC04:07
*** Marcellin__ has quit IRC04:08
*** dave-mccowan has quit IRC04:14
openstackgerritSteve Martinelli proposed openstack/keystone: Deprecate the AdminTokenAuthMiddleware  https://review.openstack.org/30528704:17
*** stevemar__ has quit IRC04:19
*** stevemar__ has joined #openstack-keystone04:19
*** stevemar__ has quit IRC04:24
*** adu has joined #openstack-keystone04:34
*** adriant has quit IRC04:35
*** hoangcx has quit IRC04:35
*** hoangcx has joined #openstack-keystone04:35
*** udesale has joined #openstack-keystone04:51
*** adu has quit IRC05:06
*** catinthe_ has quit IRC05:19
*** catintheroof has joined #openstack-keystone05:21
*** code-R_ has quit IRC05:26
*** catintheroof has quit IRC05:26
*** rha has quit IRC05:37
*** rha has joined #openstack-keystone05:38
*** guoshan has joined #openstack-keystone05:39
*** jaosorior has joined #openstack-keystone06:06
*** code-R has joined #openstack-keystone06:08
*** masuberu has quit IRC06:13
*** masuberu has joined #openstack-keystone06:24
*** code-R_ has joined #openstack-keystone06:26
*** masber has joined #openstack-keystone06:27
*** stevemar__ has joined #openstack-keystone06:29
*** masuberu has quit IRC06:29
*** code-R has quit IRC06:30
*** rha has quit IRC06:32
*** stevemar__ has quit IRC06:33
*** tsufiev has quit IRC06:35
*** tsufiev has joined #openstack-keystone06:39
*** richm has quit IRC06:42
*** code-R_ has quit IRC06:42
*** josecastroleon has joined #openstack-keystone06:57
*** jaosorior has quit IRC07:08
*** jaosorior has joined #openstack-keystone07:08
*** hoonetorg has quit IRC07:21
*** hoonetorg has joined #openstack-keystone07:21
*** hoonetorg has quit IRC07:24
*** hoonetorg has joined #openstack-keystone07:24
*** rcernin has joined #openstack-keystone07:28
*** tsufiev has quit IRC07:54
*** tsufiev has joined #openstack-keystone07:58
*** chrisplo has joined #openstack-keystone08:01
*** josecastroleon has quit IRC08:02
*** chrisplo has quit IRC08:06
*** links has quit IRC08:06
*** josecastroleon has joined #openstack-keystone08:09
*** aloga_ has joined #openstack-keystone08:09
*** rha has joined #openstack-keystone08:12
*** aloga_ has quit IRC08:15
*** links has joined #openstack-keystone08:19
*** amoralej|off is now known as amoralej08:25
*** stevemar__ has joined #openstack-keystone08:30
*** stevemar__ has quit IRC08:34
*** zzzeek has quit IRC09:00
*** zzzeek has joined #openstack-keystone09:00
*** aloga_ has joined #openstack-keystone09:08
*** jaosorior is now known as jaosorior_lunch09:13
guoshanwhois xuao09:13
guoshansorry, wrong msg sending09:14
*** zhangjl1 has quit IRC09:24
*** aloga_ has quit IRC09:24
*** 14WAANMV5 has joined #openstack-keystone09:35
*** masuberu has joined #openstack-keystone09:36
*** masber has quit IRC09:39
*** 14WAANMV5 is now known as asettle09:41
*** guoshan has quit IRC09:57
*** guoshan has joined #openstack-keystone09:58
*** guoshan has quit IRC10:03
*** aloga_ has joined #openstack-keystone10:03
*** code-R has joined #openstack-keystone10:04
*** links has quit IRC10:05
*** code-R_ has joined #openstack-keystone10:07
*** code-R has quit IRC10:10
*** hoonetorg has quit IRC10:15
*** liujiong has quit IRC10:15
*** andreaf has quit IRC10:17
*** andreaf has joined #openstack-keystone10:18
*** mkoderer___ has joined #openstack-keystone10:18
*** jlwhite_ has joined #openstack-keystone10:18
*** Krenair has quit IRC10:19
*** mkoderer__ has quit IRC10:19
*** htruta has quit IRC10:19
*** anteaya has quit IRC10:19
*** jlwhite has quit IRC10:19
*** jlwhite_ is now known as jlwhite10:19
*** jaosorior_lunch has quit IRC10:19
*** ayoung has quit IRC10:19
*** mrsoul has quit IRC10:19
*** brad[] has quit IRC10:19
*** rdo has quit IRC10:19
*** g2 has quit IRC10:19
*** briancurtin has quit IRC10:19
*** Adri2000 has quit IRC10:19
*** DinaBelova has quit IRC10:19
*** darrenc has quit IRC10:19
*** mfisch has quit IRC10:19
*** dhellmann has quit IRC10:19
*** darrenc has joined #openstack-keystone10:20
*** DinaBelova has joined #openstack-keystone10:21
*** links has joined #openstack-keystone10:22
*** mfisch has joined #openstack-keystone10:23
*** mfisch has quit IRC10:23
*** mfisch has joined #openstack-keystone10:23
*** htruta has joined #openstack-keystone10:23
*** dhellmann has joined #openstack-keystone10:23
*** briancurtin has joined #openstack-keystone10:24
*** pnavarro has joined #openstack-keystone10:24
*** mrsoul has joined #openstack-keystone10:24
*** hoonetorg has joined #openstack-keystone10:24
*** BrAsS_mOnKeY has joined #openstack-keystone10:24
*** Krenair has joined #openstack-keystone10:24
*** Krenair has joined #openstack-keystone10:24
*** brad[] has joined #openstack-keystone10:24
*** clsacramento_ has joined #openstack-keystone10:24
*** clsacramento has quit IRC10:25
*** Daviey has quit IRC10:25
*** alex_xu has quit IRC10:25
*** boris-42 has quit IRC10:25
*** code-R_ has quit IRC10:25
*** rdo has joined #openstack-keystone10:25
*** hoangcx has quit IRC10:25
*** code-R has joined #openstack-keystone10:26
*** alex_xu has joined #openstack-keystone10:27
*** Adri2000 has joined #openstack-keystone10:28
*** boris-42 has joined #openstack-keystone10:28
*** BrAsS_mOnKeY is now known as g210:28
*** chrisplo has joined #openstack-keystone10:29
*** slunkad has joined #openstack-keystone10:29
*** anteaya has joined #openstack-keystone10:31
*** jaosorior_lunch has joined #openstack-keystone10:31
*** chrisplo has quit IRC10:33
*** pcaruana has joined #openstack-keystone10:35
*** Daviey has joined #openstack-keystone10:36
*** jaosorior_lunch is now known as jaosorior10:41
*** mvk has quit IRC10:50
*** udesale has quit IRC10:57
*** mahatic_ has joined #openstack-keystone11:05
*** links has quit IRC11:07
*** links has joined #openstack-keystone11:08
*** tqtran has joined #openstack-keystone11:09
*** aloga_ has quit IRC11:10
*** richm has joined #openstack-keystone11:12
*** tqtran has quit IRC11:13
*** mvk has joined #openstack-keystone11:21
*** mvk has quit IRC11:23
*** mvk has joined #openstack-keystone11:24
*** jlk has quit IRC11:31
*** jlk has joined #openstack-keystone11:31
*** jlk has quit IRC11:31
*** jlk has joined #openstack-keystone11:31
*** dave-mccowan has joined #openstack-keystone11:37
*** josecastroleon has quit IRC11:37
*** aloga_ has joined #openstack-keystone11:50
*** nicolasbock has joined #openstack-keystone12:11
*** josecastroleon has joined #openstack-keystone12:11
*** raildo has joined #openstack-keystone12:15
*** aloga_ has quit IRC12:19
*** catintheroof has joined #openstack-keystone12:29
*** guoshan has joined #openstack-keystone12:30
*** catinthe_ has joined #openstack-keystone12:32
*** links has quit IRC12:34
*** catintheroof has quit IRC12:34
*** jrist has joined #openstack-keystone12:37
*** amoralej is now known as amoralej|lunch12:50
*** aloga_ has joined #openstack-keystone12:52
*** chrisplo has joined #openstack-keystone12:56
*** guoshan has quit IRC12:56
*** chrisplo has quit IRC13:01
*** guoshan has joined #openstack-keystone13:05
*** catintheroof has joined #openstack-keystone13:12
*** catinthe_ has quit IRC13:16
*** code-R_ has joined #openstack-keystone13:22
*** code-R has quit IRC13:24
*** links has joined #openstack-keystone13:36
*** links has quit IRC13:36
*** edmondsw has joined #openstack-keystone13:36
*** stevemar__ has joined #openstack-keystone13:37
*** pnavarro has quit IRC13:40
*** lamt has joined #openstack-keystone13:41
*** rodrigods is now known as rodrigods_13:58
*** hrybacki is now known as hrybacki|mtg14:00
*** code-R has joined #openstack-keystone14:05
bretonugh, https://review.openstack.org/#/c/379905/ broke  a lot of things for us in mitaka.14:05
*** code-R_ has quit IRC14:08
samueldmqmorning keystone14:08
lbragstado/14:08
*** amoralej|lunch is now known as amoralej14:11
*** jperry has joined #openstack-keystone14:12
samueldmqlbragstad: o/14:12
openstackgerritAndrey Grebennikov proposed openstack/keystone: Allow to specify ID on project creation  https://review.openstack.org/40386614:13
*** agrebennikov has joined #openstack-keystone14:14
knikollao/14:15
*** donnalezyty has joined #openstack-keystone14:22
stevemar__o/14:25
stevemar__breton: yes, thqt one has caused a few issues now14:26
*** ayoung has joined #openstack-keystone14:29
*** ChanServ sets mode: +v ayoung14:29
*** rodrigods_ is now known as rodrigods14:31
*** tsufiev has quit IRC14:33
*** donnalezyty_ has joined #openstack-keystone14:34
*** donnalezyty has quit IRC14:34
*** tsufiev has joined #openstack-keystone14:37
dstanekmorning samueldmq14:42
*** bigjools has quit IRC14:44
*** aloga_ has quit IRC14:47
openstackgerritBrant Knudson proposed openstack/keystone: Validate token issue input  https://review.openstack.org/40480614:49
*** spzala has joined #openstack-keystone14:50
bknudsonbreton: you should set up 3rd party CI to prevent upstream changes from breaking stuff for you.14:53
*** pnavarro has joined #openstack-keystone14:53
*** guoshan has quit IRC14:54
*** chlong has joined #openstack-keystone14:55
*** jaosorior has quit IRC14:57
*** jaosorior has joined #openstack-keystone14:59
*** udesale has joined #openstack-keystone15:00
*** chris_hultin|AWA is now known as chris_hultin15:02
stevemar__https://review.openstack.org/#/c/386183/15:03
stevemar__!!!!!!!!!!!15:03
openstackstevemar__: Error: "!!!!!!!!!!" is not a valid command.15:03
*** hrybacki|mtg is now known as hrybacki15:04
*** jdennis1 has joined #openstack-keystone15:05
*** jdennis has quit IRC15:05
lbragstadnice!15:05
samueldmqdstanek: o/15:08
samueldmqlbragstad: stevemar__ great15:09
openstackgerritBrant Knudson proposed openstack/keystone: Validate token issue input  https://review.openstack.org/40480615:15
*** stevemar__ has quit IRC15:18
*** stevemar__ has joined #openstack-keystone15:19
*** ayoung has quit IRC15:30
*** darrenc has quit IRC15:41
*** darrenc has joined #openstack-keystone15:42
*** ravelar has joined #openstack-keystone15:51
lbragstadreminder that the policy meeting will be starting in 8 minutes (in #openstack-meeting-cp)15:53
*** edtubill has joined #openstack-keystone15:55
stevemar__lbragstad: thanks for the reminder15:56
lbragstadstevemar__ anytime15:56
*** jaosorior has quit IRC15:58
*** phalmos has joined #openstack-keystone15:59
*** phalmos has quit IRC15:59
agrebennikovfolks, I just wanted to ask you - what is the reason of having validations in resources/schema.py (for example for the project name), if in fact it allows me to use special symbols16:00
*** spilla has joined #openstack-keystone16:00
agrebennikovI may create the project with names like "project+"16:00
agrebennikoveven though the validation forbids it16:01
agrebennikovoh, sorry.... nevermind16:01
agrebennikovstupid me16:01
*** edmondsw_ has joined #openstack-keystone16:02
*** rcernin has quit IRC16:02
lbragstadping raildo, ktychkova, dolphm, dstanek, rderose, htruta, atrmr, gagehugo, lamt, thinrichs, edmondsw, ruan16:02
*** code-R has quit IRC16:02
*** edmondsw has quit IRC16:02
*** edmondsw_ has quit IRC16:02
lbragstadpolicy meeting starting in #openstack-meeting-cp16:02
*** chlong has quit IRC16:03
*** edmondsw has joined #openstack-keystone16:03
lbragstadayoung ^16:03
*** chlong has joined #openstack-keystone16:18
*** jaugustine has joined #openstack-keystone16:21
stevemar__agrebennikov: used the v2 api eh?16:24
agrebennikovno, just didn't notice the name is going to be just a string16:25
*** bigjools has joined #openstack-keystone16:25
agrebennikovvs all others are checked with id_string16:25
*** code-R has joined #openstack-keystone16:27
*** thiagolib has quit IRC16:28
*** adrian_otto has joined #openstack-keystone16:29
*** ayoung has joined #openstack-keystone16:32
ayoungwhere is the Policy meeting lbragstad ?16:32
*** chrisplo has joined #openstack-keystone16:33
lbragstadayoung in #openstack-meeting-cp http://eavesdrop.openstack.org/#Keystone_Policy_Meeting16:33
*** code-R has quit IRC16:35
*** Zer0Byte__ has joined #openstack-keystone16:55
*** ruan_09 has joined #openstack-keystone17:00
lbragstadruan_09 for example - what the hook would look like, want information needs to be passed, how we get information from keystone to the external PDP, etc...17:01
lbragstadruan_09 that would be a good way to get that kind of discussion started17:01
ayounglbragstad: one thing to keep in mind:  we have the policy/RBAC/ABAC saavy people taking part in this discussion.  We need to make sure that the base mechanism  we support can be used by the average user.17:02
ayounglbragstad: the hook would be different for each service, potentially different for each PEP call17:02
ruan_09the hood is the code in oslo.policy which delegates authorization to an external PDP17:02
ruan_09since each service invokes oslo.policy, the external PDP can than be enforced by all the services17:03
ayoungfor example, creating a network based resources would need to know about networks, subnets, ports, routers. interfaces and creating a VM would need to know about the other things.  So defining the attributes for a Full ABAC system is the most intensive portion17:03
ruan_09intead of making a local authorization based on policy.json17:04
ayoungwhatever the attributes are that we are enforcing on need to be marshalled to the Remote PDP17:04
ruan_09ayoung: this is up each PDP17:04
lbragstadruan_09 so - part of that would be finding an external PDP/PEP system that is flexible enough to support that usecase17:04
lbragstadruan_09 right - but we have to get the PDP information from keystone and possibly the other service some how, so there has to be an interface around that17:05
ruan_09lbragstad: we should do that in 2 steps17:06
ruan_091. let external PDP fetches info from each services17:06
ayoungruan_09: yes, but what that means is that it is up to the Nova team to determine how nova calls it, and Neutron team for Neutron, and so on.  And those attributes which are goign to be pulled out of the request, data, and response objects are now going to be "locked in" essentially becomeing a public interface.  And those temas might not be comfortable doing that for every API17:06
*** code-R has joined #openstack-keystone17:06
ruan_092. make a concensus with each service which info can be shared17:06
ruan_09ayoung: let the external PDP fetches info from Nova, the external PDP gets only what it needs17:07
ayoungruan_09: I don't think you realize just how difficult it is to get consensus on anything in OpenStack, or you might think twice about proposing that.17:07
ruan_09ayoung: I have an implementation which works well17:08
ayoungruan_09: for which services?  Which operations.17:08
ruan_09for all the operations of nova and swift17:09
openstackgerritDavid Stanek proposed openstack/keystone-specs: Show team and repo badges on README  https://review.openstack.org/40287817:09
*** catintheroof has quit IRC17:11
*** catintheroof has joined #openstack-keystone17:12
ayoungok gotta check out for a bit17:12
ruan_09lbragstad: finally, I believe that all the authorization-related information should be centralized17:13
ruan_09but that may take long time to converge17:14
lbragstadruan_09 what do you mean by authorization information?17:14
ruan_09like role, user-role assignment17:15
lbragstadthat's already centralized in keystone17:15
ruan_09also information in policy.json17:16
*** ayoung has quit IRC17:16
stevemar__dstanek: ha, i said the same thing: https://review.openstack.org/#/c/402878/2..317:17
*** topol has quit IRC17:17
*** code-R has quit IRC17:17
*** chlong has quit IRC17:21
*** pcaruana has quit IRC17:23
dstanekstevemar__: fingers crossed17:23
dstanekruan_09: i agree with that. having everything in the same place would make it easier to implement more advanced things like domain specific policies17:24
*** code-R has joined #openstack-keystone17:25
*** spzala has quit IRC17:25
*** rodrigods is now known as rodrigods_17:31
*** woodster_ has joined #openstack-keystone17:33
*** chlong has joined #openstack-keystone17:34
*** chrisplo has quit IRC17:37
*** udesale has quit IRC17:38
*** mvk has quit IRC17:40
dstanekstevemar__: no dice17:42
*** thiagolib has joined #openstack-keystone17:43
*** ruan_09 has quit IRC17:45
*** gyee has joined #openstack-keystone17:54
*** spzala has joined #openstack-keystone17:59
stevemar__dstanek18:01
stevemar__Steve Martinelli: Patch Set 2: Code-Review+2: this should build now18:01
stevemar__David Stanek: Patch Set 3: Code-Review+2: This works locally for me now18:01
stevemar__Jenkins: NOPE! -118:01
*** spzala has quit IRC18:03
stevemar__dstanek: for some reason a really old sphinx is installed18:04
stevemar__dstanek: http://logs.openstack.org/78/402878/3/check/gate-keystone-specs-docs-ubuntu-xenial/68eff27/console.html#_2016-11-30_17_11_17_45829918:04
*** Ephur has joined #openstack-keystone18:05
stevemar__oh i didn't realize we don't install > 1.418:05
stevemar__sphinx>=1.2.1,!=1.3b1,<1.418:05
stevemar__dstanek: i see you already investigated this!18:05
dstanekstevemar__: :-) you need to catch up18:08
*** ayoung has joined #openstack-keystone18:16
*** ChanServ sets mode: +v ayoung18:16
*** chrisplo has joined #openstack-keystone18:19
*** topol has joined #openstack-keystone18:23
*** ChanServ sets mode: +v topol18:23
*** dave-mcc_ has joined #openstack-keystone18:23
stevemar__dstanek: clearly18:25
stevemar__dstanek: silly me, eating lunch and all that :)18:26
*** dave-mccowan has quit IRC18:26
openstackgerritRon De Rose proposed openstack/keystone: PCI-DSS Force users to immediately change their password upon first use  https://review.openstack.org/40391618:26
*** edtubill has quit IRC18:26
*** tqtran has joined #openstack-keystone18:27
bretonbknudson: not enough resources :(18:29
*** adrian_otto has quit IRC18:30
*** tqtran has quit IRC18:31
mfischjamielennox: you awake yet?18:35
mfischnm looks early ;)18:36
mfischjamielennox: can you ping me about 1640891 when you get in? I think there's an oslo.context bug I found18:36
*** spzala has joined #openstack-keystone18:43
*** spzala has quit IRC18:47
*** amoralej is now known as amoralej|off18:47
*** spzala has joined #openstack-keystone18:47
*** rodrigods_ is now known as rodrigods18:49
*** jvarlamova has quit IRC18:50
spligakAs an admin user, is there a way to get keystone to issue a valid token for another user? To allow you to support a "pose as user" sort of workflow?18:56
ayoungspligak, Trusts API18:56
ayounguser has to opt in, but that is what Trusts are for18:57
*** pnavarro has quit IRC19:05
spligakayoung, okay - that might be an option. is there a way for an admin user to get a token scoped to a particular project? not a full "pose as user" workflow, but at least a project-limited scenario?19:11
spligakayoung, perhaps I can frame that better. I want an admin user to be able to view a project the way a particular user would. I don't need to literally "pose as" a user, but I'd like to get a token that limits my project and role similar to how a user would see their own resources.19:12
*** asettle has quit IRC19:13
ayoungspligak, a trust is explicitly scoped to a project, and can have a subset of the users roles assigned on that project19:13
*** tqtran has joined #openstack-keystone19:14
ayoungpeople have been asking for a "READ ONLY" role and that is really hard to do, sounds like what you want, though.19:14
openstackgerritSteve Martinelli proposed openstack/keystone-specs: Show team and repo badges on README  https://review.openstack.org/40287819:17
stevemar__dstanek: ok *now* it'll work19:17
openstackgerritRon De Rose proposed openstack/keystone: PCI-DSS Force users to immediately change their password upon first use  https://review.openstack.org/40391619:20
openstackgerritBrant Knudson proposed openstack/keystone: Validate token issue input  https://review.openstack.org/40480619:40
*** lunarlamp has joined #openstack-keystone19:40
*** adrian_otto has joined #openstack-keystone19:41
*** adriant has joined #openstack-keystone19:45
openstackgerritayoung proposed openstack/keystone: URL pattern based RBAC Management Interface  https://review.openstack.org/40180819:45
stevemar__bknudson: lgtm!19:51
*** catintheroof has quit IRC19:54
stevemar__bknudson & dstanek are we finally going to merge this chain: https://review.openstack.org/#/c/261188/ ?20:04
bknudsonstevemar__: I got sick of reviewing that one so do whatever.20:04
stevemar__bknudson: before i review it, what was wrong with it that made you sick?20:05
bknudsonI made several comments on patch set 1920:06
bretonlets just add a bunch of other methods20:08
bretonlist_as_object, get_as_object20:09
bretonand so on20:09
bretonalso, dstanek had an alternative, hadn't he?20:09
bretonwhich was a little mind-blowing, but nice.20:09
bknudsonmy complaints didn't have anything to do with wanting new methods.20:11
bknudsonit was just asking to change the base methods (.get(), .head(), .post(), etc.) to include the request ID.20:11
bretoni understand that20:12
bretoni am talking about the issue in geenral20:13
*** asettle has joined #openstack-keystone20:14
bknudsonI'm fine with the way this is being done. This is how python is supposed to work (duck typing)20:14
morganmorning keystone (or erm.. lunch!)20:16
*** edtubill has joined #openstack-keystone20:18
dstanekstevemar__: i think it's a terrible thing to do from an engineering standpoint20:18
dstanekbreton: i did, but i think it was more invasive20:19
dstanekbreton: https://review.openstack.org/#/c/32991320:19
stevemar__dstanek: also please punt https://review.openstack.org/402878 through :)20:19
dstanekstevemar__: how'd you get it to work?20:20
*** asettle has quit IRC20:22
stevemar__dstanek: there's a reference to the README here: http://specs.openstack.org/openstack/keystone-specs/20:22
stevemar__dstanek: we can always turn that into a doc of it's own, something like "how to contribute a new spec"20:23
openstackgerritMerged openstack/keystone-specs: Show team and repo badges on README  https://review.openstack.org/40287820:23
stevemar__dstanek: which i'm happy to do the work for, nova already has a nice starter in their readme: https://github.com/openstack/nova-specs/blob/master/README.rst20:25
stevemar__i guess some projects dont fail when warnings are produced20:25
morganstevemar__: ping - re the user-specified id patch20:27
morganstevemar__: for projects20:27
morganstevemar__: can you confirm we want this functionality or not. we had this discussion before and I want to make sure we're clearing the runway for it (aka it wont be killed again on "we don't want this" purposes) so that agrebennikov can continue working on it with the expectation that with good code, it can land20:28
stevemar__morgan: i like your idea about enforcing uuid4 IDs20:28
stevemar__with that i'm OK with it20:29
morganmind saying that on a comment on the patch20:29
stevemar__i did?20:29
morgani'll lift my -2 then (down to a -1)20:29
* morgan goes to look20:29
*** basilAB has quit IRC20:29
stevemar__i think i reviewed a few minutes before you pinged20:29
morganaha20:29
*** basilAB has joined #openstack-keystone20:29
morgani saw a "put this in the schema"20:29
morganlet me check if i missed other bits20:29
morganah i see it20:30
morgan"not crazy about..."20:30
morgani really would rather not add more config options20:30
morganbut if that is the requirement, sure.20:30
stevemar__morgan: nah20:31
* morgan likes consistent/interoperable clouds.20:31
morganwith no guessing on functionality20:31
stevemar__morgan: andrey talked to me about it, it didn't make sense20:31
morganbut i def. want it to conform to the standard for id values for projects20:31
stevemar__if the switch is off, then keystone generates a uuid, if it's on, it's another uuid (from the req)20:31
*** browne has joined #openstack-keystone20:31
morganthe way i see it...20:32
morganthe uuid from the req or it's auto-generated20:32
stevemar__yep20:32
morganmeaning, yes someone could create projects with deadbeefdeadbeefdeadbeefdeadbeef20:32
morganids20:32
morganbut i don't see a switch as needed.20:32
morgansince the IDs are just that... unique and conforming to a known format20:32
morganthe only *concern* is if things aren't cleaned up20:33
morganand an old role assignment lingers past deletion20:33
agrebennikovand what we end up with - just a string of [0-9a-f]+20:33
agrebennikov32 bites long20:33
morganbut that is a legit bug.20:33
morgannot a real security issue20:33
morganoooh crud20:34
morganstevemar__: thought of something20:34
*** Zer0Byte__ has quit IRC20:34
morganthis means UUID tokens could become valid for a wrong project.20:34
morganstevemar__: delete the project, create a new project (different owner).20:35
morganold tokens are valid for new (different) project20:35
agrebennikovthey cannot since the IDs are uniq?20:35
agrebennikovand tokens tend to expire20:35
morganagrebennikov: right. it's a window of opportunity20:35
morganit's not super likely imo20:35
morganbut it is a minor concern20:35
morgani'm still lifting my -2 based on this convo :)20:36
agrebennikovso stevemar__, we go with regex, not the pure uuid, are you ok with that?20:36
*** rcernin has joined #openstack-keystone20:37
*** Zer0Byte__ has joined #openstack-keystone20:39
*** rodrigods is now known as rodrigods_20:41
lbragstadmorgan you worked with adriant on the outcomes of user managed TOTP yesterday after the meeting, didn't you?20:41
*** raildo has quit IRC20:41
dstanekmorgan: would the data from thos IDs be value UUID values? as in i can use the UUID objects to hold them?20:43
lbragstadthat would be nice because we could convert them to byte representations20:43
morganit would conform to straight uuid.hex20:43
morganwhich can be converted to bytes20:43
morganeaisly20:44
morganeasily*20:44
lbragstadcool20:44
morgansince it is HTTP1, and json...20:44
morganwe need it human readable, and .hex is better than uuid with '-' included in that case,  since we already do that everywhere in keystone20:44
morgan(though... to be fair... i'm not sure why we chose that)20:44
morgan(a couple extra bytes here an there wont hurt anything)20:45
morganmordred: silly question... since you know these things...20:45
morganand i can ask you :P20:45
morganmordred:  would converting things that don't need uuids to auto-inc ints in mysql (and other DBs) be more efficient20:45
morganor not worth the effort(s).20:46
* morgan asks the dirty mysql questions of the dude who "knows" things.20:46
* morgan expects a wet cat to be thrown.20:46
mordredmorgan: yah - auto-inc ints are always more efficient - especially if they are primary keys20:47
morganmordred: ok i'll toss that on my backlog of things to consider when i need some time to do things.20:48
mordredmorgan: https://www.percona.com/blog/2007/03/13/to-uuid-or-not-to-uuid/20:48
morganfair enough20:50
morganwe should ocnsider moving towards a binary compression of the keys where possible if we're going to use them [long term perf considerations] if we're getting into nitty-grittys here20:51
morganbased on that article20:51
morganbut auto-inc as a PK is more efficient and provides proper data clustering at scale, where at small-to-mid row counts, uuid is less likely ot have as big an impact, and possibly have better distribution20:51
morganwow. that is a good article :)20:51
morganthanks!20:52
*** catintheroof has joined #openstack-keystone20:54
*** spzala has quit IRC20:54
adriantlbragstad, morgan: We didn't really end up talking about the user self management side of it. Mainly just the need to have keystone be able to enforce multiple auth plugins properly.20:58
adriantI still think user totp management in keystone would be useful, but unless we can find a good solution for it people are the least unhappy about, I not sure what good pushing it will do :(21:01
dstanekmorgan: hex bytes consistent with the UUID size would be great21:02
morgandstanek: aye.21:02
dstaneki think i'm going to go get a late lunch now21:02
morgandstanek: i need lunch :(21:05
*** Zer0Byte__ has quit IRC21:05
morganoh holy crap when did it become 1pm21:05
* morgan isn't even hungry21:05
bknudsonwe can also use tempest validate the response matches a schema: https://review.openstack.org/#/c/404962/21:05
dstanekmorgan: i just realized it was 4pm and i'm starving21:06
*** Zer0Byte__ has joined #openstack-keystone21:06
morganbknudson: ++21:07
*** Marcellin__ has joined #openstack-keystone21:08
openstackgerritRon De Rose proposed openstack/keystone: PCI-DSS Force users to immediately change their password upon first use  https://review.openstack.org/40391621:10
morganadriant: so, what if keystoneclient could generate the secret?21:11
morganadriant: we have to transmit the secret in either case to/from keystone (one way or another)21:11
morganI would rather the code not be *in* keystone itself21:11
morgannow, there is a concern about entropy on end-user machines21:11
adriantmorgan: yeah, that's not something I considered, but in general I just thought server generation was the safest as it is then under deployer control21:13
morganadriant: i view this as something that shouldn't be *in* keystone21:14
morgani don't mind having official utilities that can do it outside of keystone21:14
morganso, for example, your user-management portal (i assume you have one since admin-requirement and for other reasons)21:14
adriantI can live with that.21:14
morgancan do these things.21:14
adriantyes, we have a user management portal that does everything for users in keystone except auth and password changes21:15
adriantand we can throw our MFA code into that21:15
morganin fact, if we didn't already have EC2 key generator apis in keystone, i'd advocate this should be in associated utils as well21:15
morganadriant: lets not put it in the keystone server itself. credentials are "special" cased in keystone for the most part anyway21:16
adriantOk, but we still probably want a way for users to upload them. We can just change the credentials api to allow "admin_or_owner"21:16
adriantwe can allow that policy provided we add... sec let me find the code21:17
adriantmorgan: I beleive throwing something close to how EC2 does this into the core credentials code is enough: https://github.com/openstack/keystone/blob/master/keystone/contrib/ec2/controllers.py#L35621:18
morganadriant: using the base credential api and setting a type should be fine21:18
morganas long as we provide clear documentation on how to do it21:19
adriantbecause by default the policy stuff can't access the field on the model itself I believe, but this change that EC2 have done does allow that check21:19
*** franza has joined #openstack-keystone21:19
morganfwiw, i think the credential API has security flaws in it... but that aside.21:19
morganthe "ec2" controller just does some magic with creating the credential data21:20
morganwe can do the same things with the normal api, and totp is much much much simpler credential data21:20
adriantmorgan: I don't think we need to do anything special, my main concern is the cross user problem21:20
*** gyee has quit IRC21:21
*** amoralej|off is now known as amoralej21:21
morganwe can define the standard like google does21:21
morganfor what the secret needs to be21:21
morganwe can provide a simple validator in our utils for the secret21:22
morgani worry that we're going to have to add HOTP next because people want it.21:22
rcernindo we have something like RSA tokens for Horizon auth?21:22
morganor <new fangled crazy MFA>21:22
adriantnot HOTP :(21:23
rcernin:)21:23
adrianttotp is better than hotp :P21:23
morganadriant: right. just wait though, if we add more and more of these "things" as top-level apis...21:23
morganadriant: debatable21:23
morganadriant: totp is way easier to manage21:23
morganbut i'd argue each has pros and cons21:23
adriantmorgan: I'm aware, I just prefer totp as it's less of a hassle most of the time.21:24
*** Zer0Byte__ has quit IRC21:24
morganso do i21:24
morganbut I also want to implement FIDO u2f for keystone21:25
morgan;)21:25
morganbut that only works with chrome atm... sooooo21:25
*** mvk has joined #openstack-keystone21:25
morgannot useful for keystone (yet)21:25
*** Zer0Byte__ has joined #openstack-keystone21:25
morgananyway let me write this spec up unless you posted one already21:26
adriantThat would be interesting, although possibly very painful to get working no?21:26
morganpossibly, but awesome21:26
adriantI have a user-self management one, I can rewrite it to reflect this talk.21:26
adrianthttps://review.openstack.org/#/c/34570521:27
morganalso, if we do it without needing the keystone API to generate, it is easier to setup with a yubikey21:27
morgancool. let me comment on it and lets get it ready to go :)21:27
morganoh no not just that one21:27
rcerninbtw guys qq how does the services authenticate if you use totp or others, or you simply keep the password in methods?21:27
rcernin^^21:27
morganrcernin: that is the idea21:28
morganrcernin: the plan is to make it so a given user can require specific auth plugins21:28
morganaka, must use totp and password21:28
morganor a service user can use just password21:28
adriantmorgan: I'm just curious how we'll eventually connect that to horizon :(21:28
morganadriant: we need the spec to update the auth plugin model with per-user requirements21:28
adriantmorgan: yes, that too. You throw up that one, I'll amend the user management one.21:29
morgancool.21:29
adriantI'll change it to just be for: "fix/alter the credentials api to make this possible while adding basic validation", "add generation of totp to keystoneclient""21:30
rcerninbtw can you block the password from horizon ui as long as you have the user/password combination you wouldn't need totp and it would loose the effect wouldn't it?21:30
rcerninsplit the service use the password method while users would need to use the tokens21:31
morganrcernin: not sure what you're asking21:31
adriantmorgan, rcernin: my problem is Horizon doesn't know, "this user need totp and password"21:31
rcerninif you implement tokens, and still need to have the passwords enabled for services as they can't use the tokens, isn't it useless ?21:31
adriantand we can't really pre-fetch that info and load the UI based on it :(21:32
rcerninyeah21:32
adriantmorgan: hence my password_totp stuff :(21:32
adriantI didn't want to go down the rabbit hole of fixing/changing that whole process yet21:32
morganadriant: the thought i always had was if totp was required, you get an response back (we have an error response that works like this, look a tthe challenge-response example) and we then re-request with the data inc the totp- it's two pages, but most totp is.21:33
morganadriant: i.e. google.21:33
morganadriant: and dropbox, and amazon, and etc etc, mostly MFA is "here is pre-auth, ok now we need OTP, give me OTP"21:33
adriantmorgan: I had a similar idea, but the best way I thought it would work was by returning a semi-unscoped token that as approved with password but not totp yet.21:33
morganunless you use something like how FreeIPA does it, which is what you're advocating - password+OTP21:34
adriantso the token itself knows "this is the auth I was given" and a token only gets proper roles when all the auth types are done for it.21:34
morganthat actually would be super easy to do.21:34
morganit's a new token-type (in the fernet has multiple token-types)21:34
adriantbasically, we make the token itself the auth status as well as the challenge response21:34
morganin fernet land, you'd get a new token when you finished totping21:35
adriantyep21:35
morganin uuid land... it could go either way21:35
adriantThat's the only not awful solution I saw for doing proper challenge response in keystone21:36
adriantI'm not sure if there is a better way to do it, but I don't know keystone well enough yet anyway.21:36
morganor, you re-send the password and totp, horizon could maintain the password field populated (and even hidden) based upon the response21:36
morganso only totp is included.21:36
morganafter.21:37
morganthere are many ways to slice this.21:37
adriantThat's possible, we could update openstack django auth to handle that21:37
morganexactly21:37
morganbut it still is predicated on having the ability to require the auth-types on a per-user basis21:37
adriantnot sure how I feel about storing the password there between responses, but it's not too awful21:37
adriantand if the error messages and code coming from keystone are good enough to let os-django-auth programatically do all this, it would totally work.21:38
morganthe errors for a challenge/response style should be sufficient21:38
morganas they sit21:38
rcerninadriant: did you mean this on-per-user-basis MFA https://blueprints.launchpad.net/keystone/+spec/password-totp-plugin21:39
adriantrcernin: yes and here is the patch: https://review.openstack.org/#/c/34342221:40
adriantrcernin: it literally works by expected a 6digit passcode appended to the password.21:41
adriantif totp has been setup for a user21:41
*** Zer0Byte__ has quit IRC21:43
adriantmorgan: ok, should we just do the spec for auth plugins as discussed and then worry about challenge response later? Or include that in the spec?21:43
morgani'll include the details of that in the spec, but leave that bit to the implementation details21:44
morganif we add it or not.21:44
adriantmorgan: ok. I mention it just because how we do the auth plugins might affect what we can do with challenge response later. As trying to alter it later may break backwards compatibility :(21:46
morgannah.21:47
morgani think we can make it consistent enough so that django openstack auth can work from it21:48
*** adrian_otto has quit IRC21:48
morgani lean towards not doing "temp auth" tokens21:48
morganbut we can discuss a bit more in the spec once posted21:48
*** Zer0Byte__ has joined #openstack-keystone21:48
adriantmorgan: so reauth based on errors?21:48
morganyes. since this is RESTful, it already works like that21:49
morganand it follows the patternof our current challenge/response concept21:49
morganslash example21:49
adriantyeah fair enough21:49
adriantmorgan: sounds good. We can then work with Horizon and OS-client devs to add in support for it properly too.21:50
*** edmondsw has quit IRC21:50
adriantalthough OS-Client will not need too much work if we do a lot of it in KeystoneAuth121:50
morganin some ways i wish our specs were more like RFCs21:51
morganthen i read RFCs and ...21:51
morganam glad our specs are more human readable21:51
*** adrian_otto has joined #openstack-keystone21:52
adriantmorgan: oh, for this the auth plugins spec. I think the default if a user has no rules enforced is just "any single auth method"21:53
morganyep21:53
adriantcorrection21:53
morganthat is the plan21:53
adriant"at least one"21:53
openstackgerritLance Bragstad proposed openstack/keystone: Remove exception from v2 validation path  https://review.openstack.org/40497721:54
adriantmorgan: I'm looking forward to this. ;) As I can then throw in some silly auth layers like allowing users to set IP ranges they can only auth from.21:55
*** gyee has joined #openstack-keystone21:57
*** gyee has quit IRC21:58
ayoungdstanek, stevemar__ cannot build docs for specs. When I try I get21:59
ayoungFile "/tmp/pip-build-nhxd68z3/feedformatter/feedformatter.py", line 7721:59
ayoung        (("pubDate", "pubdate", "date", "published", "updated"), "pubDate", lambda(x): _format_datetime("rss2",x)),21:59
ayoungthis is a dependecny from yasfb22:00
adriantmorgan: actually, as part of the default, I think we need a default we can set in the config (at least one of: "password, totp, ..."), and if that config default isn't set, then we go by "at least one of all active methods"22:01
*** jrist has quit IRC22:01
*** Zer0Byte__ has quit IRC22:01
morganadriant: i am hesitant to add that. but we cna discuss once i post the spec22:01
adriantmorgan: just because there will be some plugins that really shouldn't be used by themselves. So a deployer can ensure totp isn't used by itself without password.22:01
adriantmorgan: otherwise they need to set it for all old and new users :(22:02
adriantwhich is a huge and ugly pain22:02
*** jrist has joined #openstack-keystone22:02
morganin the case of password+totp you need to configure totp for old users anyway22:02
ayoungmorgan, your argument for the security hole with the project ID is another argument in favor of soft deletes of projects22:02
morganyou need to update users.22:02
morganayoung: yes. i know.22:02
adriantmorgan: I mean more the situation. A cloud has "password, totp, external, etc" auth methods turned on. But the deployer doesn't want totp ever being used by itself.22:03
adriantso to do that they would need to set all users "at least one of all, but not totp"22:04
adrianta changable global default makes this easier22:04
ayoungadriant, morgan is this really going to be on a per- user basis, or is it more likely to be on "all users in this domain" basis?22:04
adriantayoung: per user22:05
morganayoung: to start per-user22:06
ayoungadriant, so it should be a property of the user that is checked on the password plugin22:06
morganwe can expand to "any user that belongs to <domain>" (not "has a role on domain")22:06
morganayoung: correct. the user will have an attribute with a list of rules for authentication-types22:07
morgane.g.:22:07
*** jrist has quit IRC22:07
morganhttps://www.irccloud.com/pastebin/vLAunqx9/22:07
adriantpretty much per user auth policy :P22:07
openstackgerritSamuel Pilla proposed openstack/keystone: [WIP] Add password expiration queries for PCI-DSS  https://review.openstack.org/40389822:08
ayoungif a user has OTP set, they *MUST* pass in the OTP value.  After that, the OTP value gets removed, and it is no longer valid, and their password must be reset or whatevber business logic you have22:08
ayoungfor password plugin, if OTP is set, use the OTP value, otherwise use password, and all the validation there.22:08
morganayoung: correct, the auth-plugin (keystone server side) needs to know how to handle that22:08
morganif it's HOTP, the counter is incremented22:08
morganif it is true OTP, it is invalidated22:09
adriantmorgan: one thing though with the totp-self management is how can that fit into adding those rules to the user without another service doing it for them?22:09
ayoungfrom a KC perspective it is still OS_PASSWORD, just set to {{ OTP VALUE }}22:09
morganif it is OTP + password, jus the OTP is invalidated, but still confirmed22:09
morganadriant: it requires a user-update, we can add an api similar to password change22:09
morganadriant: that is self-service22:09
ayoungIf it is used, it is discarded.  Otherwise it is not a OTP.  HOTP, as you described it, sounds like a bastard abomination from hell.  Or at least misnamed.22:10
* morgan continues to write this spec up22:10
morganayoung: it is how HOTP works22:10
morganyou have a counter (offset) vs a timer22:10
morganeach token is valid once22:10
ayoungAh, it that what the gemalto tokens are doing?  and the RSA ones?22:10
morganthe server tries a few options22:10
morganyour redhat token for vpn is HOTP22:10
morganfor example22:10
ayounggot it22:10
*** clayg has joined #openstack-keystone22:10
morganit is why a re-sync is sometimes needed22:10
adriantmorgan: and do we want a difference between user set auth rules, and admin set auth rules for a user? Do we care?22:11
morganadriant: you can always deny users access to the self-service api22:11
morganvia policy22:11
adrianttrue22:11
ayoungSo it all comes through the password field, but the processing is done by a pipeline of Auth plugins?22:11
adriantok, by default a user entirely controls their rules22:11
morganayoung: depends on implementation22:11
morganayoung: some do it like we do at RH with a password+OTP22:12
morganin one field22:12
ayoungso right now we have:  [auth] password= keystone.auth.plugins.Password22:12
morgansome work like google, which is send password, then send OTP22:12
adriantayoung: look at the existing totp plugin, it expects a separate passcode value in a different method22:12
ayoungdo we really want22:12
morgansome look like "send password, and otp same request but different fields"22:12
ayoung[auth] password=  keystone.auth.plugins.HTOP,  keystone.auth.plugins.OTP,  keystone.auth.plugins.Password22:12
morganthat is just telling keystone what plugins to enable22:12
adriantayoung: no22:12
morganand load22:12
ayoungand have them processed in that order for the "password" auth method in the token request?22:12
morganwe require the auth request to specify the type for each value22:13
morganand we will maintain it22:13
morganin a an auth-request you can have multiple plugins22:13
ayoungmorgan, that is a very poor user experience22:13
morganin a RESTful API, it is fine22:14
morganthe UI/CLI can make the UX better22:14
morganit can do splits etc22:14
ayoungmorgan, ok...lets skip this part, and jump right to WHY you want it this way22:14
morganbecause we already have it this way and changing it would break our API and auth contract22:14
morganwhich is horrifying22:14
ayoungSo...no22:14
ayoungthat is not true and not really an answer22:14
morganwe aren't breaking our auth contract22:14
morganyes it is true. it is exactly how it works now22:15
ayoungmorgan, when you send in an OTP, it *is* a password22:15
adriantayoung: let me show you and example of a what a request looks like: http://paste.openstack.org/show/591023/22:15
ayoungmorgan, do you realize how much unnecssary pain that will cause?22:15
ayoungso...let me ask again22:15
morganok. we have a plugin that reads "password", traditionally or OTP, or x50922:16
ayoung"Why" should we not treat an OTP just like a normal password22:16
morganyou are passing what version of password you're using. they are all passwords22:16
ayoungis it cuz we need to be able to send it *with* a passwrod for some use cases?22:16
morganbut the plugin must know what form of password it is22:16
adriantbecause it isn't a password, it's only really useful alongside a normal password22:16
morganwe *already* support multiple forms for auth22:16
adrianttrue otp we can do, but we need to know its type22:17
morganand if you are authing with totp, you say this is totp: "value" in the auth requst22:17
ayoungadriant, not the HOTP one.  That replaces a password22:17
morganvs "password": <password value>"22:17
ayoungif an account is locked due to expired passwrod, you require the user to send the OTP and the original password?22:17
morganin keystone we also support auth: ["password": <details>", "totp": <details>]22:17
morganand the token says "hey you used both"22:17
morganayoung: right now self-service password changes cannot be done with expired passwords22:18
morganthis doesn't change anything22:18
ayoungmorgan, I know all that. I was there when Guang wrote it.  I battled with David CHadwick to have the specific mechanism in that field basedd on the requer as opposed to just having a "Federated" auth plugin...which is what we ended up with22:18
ayoungI made all the mistakes22:18
morganunless you have an alternative form of auth configured22:18
ayoungso  If a user has OTP set up, their normal password will work just fine22:18
morganright now, OTP is just a form of password22:19
morganit is *not* MFA in keystone22:19
morganthis change is simply allowing us, per-user to require multiple forms of auth. making it really MFA support22:19
morganaka must send the OTP *and* traditional password (if that is what is configured)22:19
ayoungGot it22:20
adriantayoung: right now, this here is a valid auth request: http://paste.openstack.org/show/591024/22:20
ayoungso MFA is a per-user thing?22:20
adriantyes22:20
morganthat is the intent22:20
morganit can be expanded22:20
morganbut we're starting with per-user22:20
morganif you configure MFA, you must use MFA. not per-domain or per-scope (this gets really ugly to support and i think a worse UX by far)22:21
morgani also see us *maybe* requiring a user to have MFA for a specific scope, but i like the github model22:21
ayoungThis is really going to suck22:21
ayoungfor Horizon22:21
morganit's either you have MFA or you don't. that may limit what you can access, but it doesn't require you to auth conditionally to get some access. it's an all or nothing22:21
morganwe already discussed about 5 ways of approaching it for horizon22:22
adriantayoung: nope, we can add support in openstack-django-auth22:22
morganeach has pros and cons22:22
ayoungOh, I didn't mean it couldn't be solved. I meant that it is going to fall to me to support it for Tripleo in Horizon, and that is going to suck22:22
morgansome are better UX, some are more "standard web-style ux"22:22
*** amoralej is now known as amoralej|off22:22
morgani think it's going to be pretty standard22:22
ayoungCan't we just do all this in Keystone via Federation?22:23
morganyou can totally support this in keystone with federation to freeipa22:23
morgan100%22:23
morganback it to freeipa with it's MFA support22:23
morgandone22:23
morganthis is allowing keystone to *also* support this, as it's a consistent request to have22:24
morganin fact, for triple-o since it is freeipa backed, i would 100% say, just do that22:24
morgan:)22:24
ayoungTell them no22:24
morgantoo late22:24
ayoungNah, I can -2 anything22:24
morganwe accepted the basic pemesis and added totp.22:24
morganwith the condition this will be added22:24
ayoungSo we lied22:24
morgandude, we have already conceeded the IDP part of keystone22:25
morganwe are an IDP.22:25
ayoungOh, I have a change to deprecate that I forgot to submit22:25
ayoungI have conceded nothing!22:25
adrianttoo many people (including my organisation) is actually using keystone without federation.22:26
adriants/is/are/22:27
openstackgerritRon De Rose proposed openstack/keystone: PCI-DSS Force users to immediately change their password upon first use  https://review.openstack.org/40391622:27
ayoungadriant, we give them 2 cycles to move to something real22:27
adriantAnd having a basic but still useful IDP as part of openstack isn't a terrible idea.22:28
ayoungoh yes it is22:28
ayoungit is the worst idea I have heard.22:28
morganayoung: we also are adding PCI-DSS support... we're a real (but limited) idp22:28
ayoungmorgan, I know.  i was against that too.22:28
ayoungand now my PM has heard about it and is all over it22:29
ayoungmeanwhile....https://review.openstack.org/#/c/391624/22:29
ayoungactually makes Keystone do something useful for a change.22:29
morganayoung: ok i'm going back to writing this spec up....22:30
morganayoung: so that i can actually review the things needed to be reviewed.22:30
*** code-R_ has joined #openstack-keystone22:33
*** code-R has quit IRC22:33
morganadriant: UGH...22:36
morganwe have to pass the user_id for *each* auth plugin22:36
morgan*sigh*22:36
morgani think i need to modify (allow for a single) auth-info bit to be supplied22:36
adriantmorgan: yeah, the need to split it out per method also always bugged/confused me but I do understand why22:37
adriantmorgan: part of me wishes this was possible: http://paste.openstack.org/show/591028/22:38
morganadriant: i can enhance that a bit and support both forms.22:38
morganyeah we can do both things22:38
morganwould not be hard.22:39
openstackgerritayoung proposed openstack/keystone: URL pattern based RBAC Management Interface  https://review.openstack.org/40180822:39
*** edtubill has quit IRC22:40
*** mnaser has quit IRC22:41
openstackgerritSamuel Pilla proposed openstack/keystone: [WIP] Add password expiration queries for PCI-DSS  https://review.openstack.org/40389822:41
*** jrist has joined #openstack-keystone22:42
*** spilla has quit IRC22:44
openstackgerritMerged openstack/keystone: Removes unused exceptions  https://review.openstack.org/40441622:45
*** mnaser has joined #openstack-keystone22:50
*** pumaranikar has joined #openstack-keystone22:50
*** dave-mcc_ has quit IRC22:53
*** masuberu has quit IRC22:54
*** masber has joined #openstack-keystone22:54
pumaranikarHi jamielennox, am working on this https://review.openstack.org/#/c/387711/ spec for nova  which is basically using service token for service to service communication..22:55
jamielennoxpumaranikar: yep, i remember22:57
pumaranikarjamielennox, Are we planning to have new release soon for keystoneauth1 so that we can make use of service token22:57
jamielennoxso we need a keystoneclient release then a keystonemiddleware release to actually enforce the expiry thing22:58
morganadriant: what is your launchpad id? adriant?22:58
adriantsec, I'll check, but I think adriant-y22:58
jamielennoxhowever there shouldn't be any reason you can't start it now, it just won't give you the expired token advantage yet22:58
jamielennoxpumaranikar: i mean, what exactly are you waiting for on keystoneauth?22:58
adriantmorgan: "adriant-y22:59
adriant"22:59
stevemar__jamielennox: want a new ksc release?22:59
pumaranikarjamielennox, we are trying to use service token wrapper which is not part of 2.15 tag22:59
*** jperry has quit IRC22:59
pumaranikarI think so23:00
openstackgerritBrant Knudson proposed openstack/keystone: More info in schema validation error  https://review.openstack.org/40500623:00
jamielennoxpumaranikar: did that merge?23:01
jamielennoxok, yea, but it hasn't been released yet23:02
pumaranikarjamielennox, yes.23:02
jamielennoxstevemar__: yea, we're going to want a new release of both - can you give me a few hours to figure out what else i need in those releases23:02
jamielennoxlike anything open that needs to go in23:02
openstackgerritMorgan Fainberg proposed openstack/keystone-specs: Specification for MFA support  https://review.openstack.org/40500723:04
*** browne has quit IRC23:04
morganadriant: ah doh23:04
morgansec23:04
stevemar__jamielennox: ack23:04
openstackgerritMorgan Fainberg proposed openstack/keystone-specs: Specification for MFA support  https://review.openstack.org/40500723:04
stevemar__jamielennox: poke me if you need something23:04
morganadriant: ^ there is the first pass on the spec23:04
jamielennoxstevemar__: you happy to do it today? not too late in the week?23:04
adriantmorgan: fantastic, will look over it later today :)23:05
pumaranikarjamielennox, thanks. I think we will have new release soon :)23:05
stevemar__jamielennox: i'll happen tomorrow, and there are only 8 changes, so the release team should be OK with it23:05
openstackgerritMorgan Fainberg proposed openstack/keystone-specs: Specification for MFA support  https://review.openstack.org/40500723:06
morganadriant: ok there we go. fixed a couple formatting bugs23:06
morganhope i didn't screw up rst too badly23:06
jamielennoxstevemar__: so only https://review.openstack.org/#/c/392442/ to review for ksa - he did all the right things but i'm concerned about the noise23:07
jamielennoxbasically i think everything around request id annoys me23:08
* jamielennox grumpy old man23:08
jamielennoxideally i think we should get rid of the curl debug statements from ksa and replace it with something useful that tells you the info you want to know23:08
jamielennoxbut i think that makes it contentious and we shouldn't put it in this release - so ksa is good to go23:09
stevemar__jamielennox: i'm not a huge fan of the request id stuff either, but its a cross-project spec23:10
stevemar__initiative*23:10
bknudsonI've found the request ID in the keystone error response to be useful.23:11
stevemar__jamielennox: i think it's mergable23:12
pumaranikarjamielennox, I have initiated service token change in nova. https://review.openstack.org/#/c/397399/. Please have quick look when you get time.23:12
*** catintheroof has quit IRC23:12
stevemar__bknudson: jamielennox: i tossed it a +223:13
stevemar__jamielennox: oh wow, been a while since a ksa release23:13
*** ravelar has quit IRC23:14
stevemar__meh, nothing major for the most part23:14
stevemar__"Add a service token wrapper" is the only major thing23:14
jamielennoxyea, it's been pretty stable23:14
jamielennoxstevemar__: so the problem with that review is that it will add a new, long, debug statement to every request made23:15
jamielennoxwhich i'm pretty sure will piss off at least the infra/devstack people23:15
jamielennoxand maybe ops in general23:15
stevemar__yes, i agree...23:15
jamielennoxi'm reluctant to add more output vs making the output we have better/more structured23:16
jamielennoxbut who knows what ops may be doing re parsing those curl statements23:16
jamielennoxon the other hand, he's already added it to novaclient and others so maybe just suck it up and do it23:17
jamielennoxwhy you add it there before ksa i'm not sure23:17
jamielennoxre ksc, https://review.openstack.org/#/c/339150/10 looks easy but not urgent for part of this release23:18
jamielennoxotherwise i think that's probably fine as well23:18
*** topol has quit IRC23:20
*** spzala has joined #openstack-keystone23:21
stevemar__jamielennox: rgr23:21
stevemar__jamielennox: and ksm?23:22
*** chlong has quit IRC23:22
stevemar__jamielennox: you've got a bunch of merge conflicts, something in WIP, and brant has something in WIP23:22
openstackgerritayoung proposed openstack/keystone-specs: Role Check Check from Middleware  https://review.openstack.org/39162423:23
jamielennoxstevemar__: i need to fixup the allow_expired thing for ksm but that's going to require the new release of ksc23:23
jamielennoxthere's nothing i see that really needs to be released until then23:24
jamielennoxpki deprecations, some small testing and doc fixes23:24
jamielennoxi think we can wait on that and see if i can fix the allow_expired thing quickly23:25
*** asettle has joined #openstack-keystone23:25
*** clsacramento_ has quit IRC23:26
*** ravelar has joined #openstack-keystone23:26
*** spzala has quit IRC23:26
*** rcernin has quit IRC23:26
*** clsacramento has joined #openstack-keystone23:28
ayoungstevemar__, jamielennox can you do a `tox doc `  in keystone-specs?  Mine breaks23:28
ayoungactually, just tox breaks there now...23:28
ayoungcomplaining about23:29
ayoungCollecting feedformatter (from yasfb>=0.5.1->-r /opt/stack/keystone-specs/requirements.txt (line 9))23:29
ayoungthis is post F25 upgrade, so I wonder if it is defaulting to python3 there...23:29
ayoungnope 2.723:29
*** asettle has quit IRC23:30
*** ravelar has quit IRC23:33
jamielennoxdid you rebuild the env after the upgrade23:36
*** spzala has joined #openstack-keystone23:36
openstackgerritMorgan Fainberg proposed openstack/keystone-specs: Specification for MFA support  https://review.openstack.org/40500723:42
*** lamt has quit IRC23:44
openstackgerritRon De Rose proposed openstack/keystone: PCI-DSS Force users to immediately change their password upon first use  https://review.openstack.org/40391623:46
*** Zer0Byte__ has joined #openstack-keystone23:53
stevemar__ayoung: tox -re docs to rebuild?23:56
stevemar__jamielennox: no harm in releasing it, i tossed up a release so your work can have a fresh slate23:57

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!