Monday, 2017-05-22

*** jamielennox|away is now known as jamielennox00:02
*** markvoelker has quit IRC00:11
*** thorst_afk has joined #openstack-keystone00:19
*** thorst_afk has quit IRC00:24
*** Shunli has joined #openstack-keystone00:33
*** links has joined #openstack-keystone00:54
*** thorst_afk has joined #openstack-keystone01:02
*** thorst_afk has quit IRC01:04
*** thorst_afk has joined #openstack-keystone01:58
*** jamielennox is now known as jamielennox|away02:00
*** shuyingya has joined #openstack-keystone02:05
*** shuyingy_ has joined #openstack-keystone02:24
openstackgerritzhengliuyang proposed openstack/keystone master: Add notes about revocations  https://review.openstack.org/46656702:26
*** shuyingya has quit IRC02:28
*** aojea has joined #openstack-keystone02:37
*** aojea has quit IRC02:41
openstackgerritzhengliuyang proposed openstack/keystone master: Quotation marks should be included in http url using curl  https://review.openstack.org/45873602:48
openstackgerritNgo Quoc Cuong proposed openstack/keystone master: Remove the deprecated tempest.test.attr  https://review.openstack.org/46657402:52
*** thorst_afk has joined #openstack-keystone02:57
*** jhesketh_ is now known as jhesketh03:08
openstackgerritzhengliuyang proposed openstack/keystone master: Add response example in authenticate-v3.inc  https://review.openstack.org/46324503:17
*** thorst_afk has joined #openstack-keystone03:28
*** lamt has joined #openstack-keystone03:46
*** thorst_afk has quit IRC03:46
*** jamielennox|away is now known as jamielennox03:53
*** jaosorior has joined #openstack-keystone04:52
*** lamt has quit IRC05:16
*** stingaci has joined #openstack-keystone05:20
*** stingaci has quit IRC05:25
*** thorst_afk has joined #openstack-keystone05:43
*** thorst_afk has quit IRC05:48
*** tobberydberg has joined #openstack-keystone05:56
*** lamt has joined #openstack-keystone06:07
*** belmoreira has joined #openstack-keystone06:07
*** gyee has joined #openstack-keystone06:08
*** shuyingy_ has quit IRC06:13
*** shuyingya has joined #openstack-keystone06:13
*** shuyingy_ has joined #openstack-keystone06:19
*** rcernin has joined #openstack-keystone06:19
*** shuyingya has quit IRC06:22
*** gyee has quit IRC06:31
*** thorst_afk has joined #openstack-keystone06:44
*** thorst_afk has quit IRC06:49
*** tobberyd_ has joined #openstack-keystone07:03
*** tobberydberg has quit IRC07:06
*** pcaruana has joined #openstack-keystone07:11
*** zsli_ has joined #openstack-keystone07:12
*** pcaruana has quit IRC07:12
*** pcaruana has joined #openstack-keystone07:13
*** rcernin has quit IRC07:14
*** rcernin has joined #openstack-keystone07:14
*** Shunli has quit IRC07:15
*** aojea has joined #openstack-keystone07:19
*** lamt has quit IRC07:35
*** david-lyle has quit IRC07:36
*** hoonetorg has quit IRC07:39
*** david-lyle has joined #openstack-keystone07:42
*** thorst_afk has joined #openstack-keystone07:45
*** david-lyle has quit IRC07:46
*** thorst_afk has quit IRC07:50
*** hoonetorg has joined #openstack-keystone07:54
*** zzzeek has quit IRC08:00
*** zzzeek has joined #openstack-keystone08:01
*** david-lyle has joined #openstack-keystone08:03
*** tobberyd_ has quit IRC08:14
*** adriant has quit IRC08:28
*** zian has joined #openstack-keystone08:30
*** tuan_ has joined #openstack-keystone08:32
zianHello everyone. I would like to know if login with gmail/facebook credentials is applicable to access a public openstack cloud.08:32
zianAny inputs on this would help08:32
tuan_morning guys,08:33
*** tuan_ has left #openstack-keystone08:33
openstackgerritzhengliuyang proposed openstack/keystone master: More messages about validating token failed  https://review.openstack.org/46364108:39
bretonzian: gmail -- probably yes, it provides openid connect08:42
zianThanks for your reply @breton. Any openstack document on how to proceed?08:45
*** thorst_afk has joined #openstack-keystone08:46
*** zsli__ has joined #openstack-keystone08:46
*** tuan__ has joined #openstack-keystone08:47
*** zsli_ has quit IRC08:49
*** tobberydberg has joined #openstack-keystone08:50
zianbreton: It would be of great help to me if you could tell me Where in keystone, i have to make the changes to include external authentication.08:50
*** tobberydberg has quit IRC08:54
*** tobberydberg has joined #openstack-keystone09:02
*** zian has quit IRC09:04
*** thorst_afk has quit IRC09:05
bretonaaand he quit09:06
*** pnavarro has joined #openstack-keystone09:22
*** mvk has quit IRC09:36
*** zsli__ has quit IRC09:38
*** stingaci has joined #openstack-keystone09:42
*** thorst_afk has joined #openstack-keystone10:02
*** mvk has joined #openstack-keystone10:06
*** thorst_afk has quit IRC10:07
*** stingaci has quit IRC10:21
*** ayoung has joined #openstack-keystone10:23
samueldmqmorning keystone10:28
*** tobberydberg has quit IRC10:45
*** Shunli has joined #openstack-keystone10:48
*** Shunli has quit IRC10:49
*** toddnni has quit IRC10:54
*** toddnni has joined #openstack-keystone11:00
*** thorst_afk has joined #openstack-keystone11:18
*** toddnni has quit IRC11:22
*** dave-mccowan has joined #openstack-keystone11:30
*** toddnni has joined #openstack-keystone11:33
*** mvk has quit IRC12:07
*** edmondsw has joined #openstack-keystone12:15
*** edmondsw has quit IRC12:16
*** raildo has joined #openstack-keystone12:21
*** chlong has joined #openstack-keystone12:29
*** mvk has joined #openstack-keystone12:32
samueldmqcmurphy: ping - re https://review.openstack.org/#/c/45194112:36
cmurphysamueldmq: hi12:36
*** dikonoor has joined #openstack-keystone12:36
samueldmqcmurphy: just saw your comment, a byte has 8 bits, so I can't see how 16 became 256 yet :-)12:37
samueldmqcmurphy: shouldn't it become 128 then?12:38
*** stingaci has joined #openstack-keystone12:38
cmurphysamueldmq: hmm maybe my +2 was too fast12:41
*** catintheroof has joined #openstack-keystone12:41
samueldmqcmurphy: there is a backward compatibility testing in http://paste.openstack.org/show/606401/12:42
cmurphysamueldmq: i saw that, also did some manual testing, but you're right that the pycrypto default block size was 16 bytes not 3212:44
*** tuan__ has quit IRC12:44
*** tuan has joined #openstack-keystone12:46
samueldmqcmurphy: it is failing for me on Python3 http://paste.openstack.org/show/610168/12:49
*** chlong has quit IRC12:55
*** xuhaigang has quit IRC12:55
*** shuyingy_ has quit IRC13:00
*** lamt has joined #openstack-keystone13:04
*** markvoelker has joined #openstack-keystone13:22
*** yunus has joined #openstack-keystone13:25
yunusI want to integrate LDAP with keystone. According to the https://docs.openstack.org/admin-guide/identity-integrate-with-ldap.html, you must enable the authlogin_nsswitch_use_ldap boolean value for SELinux on the server running the OpenStack Identity service. But our OS is Ubuntu, then I could not enable SELinux. How can I handle this situation? Thanks for helping13:26
yunusSome geeks says that do not use SELinux with Ubuntu. https://ubuntuforums.org/showthread.php?t=232401113:27
*** spilla has joined #openstack-keystone13:28
cmurphyyunus: that instruction only applies if you are running selinux, since selinux doesn't run on ubuntu by default then you don't need to change anything13:31
yunuscmurphy thanks for helping. I will try this.13:31
*** markvoelker has quit IRC13:35
*** ducttape_ has joined #openstack-keystone13:35
*** markvoelker has joined #openstack-keystone13:35
*** shuyingya has joined #openstack-keystone13:40
*** shuyingya has quit IRC13:44
*** shuyingya has joined #openstack-keystone13:45
*** yunus has quit IRC13:47
*** catinthe_ has joined #openstack-keystone13:53
*** catinth__ has joined #openstack-keystone13:53
*** catintheroof has quit IRC13:54
*** links has quit IRC13:57
*** catinthe_ has quit IRC13:57
*** aojea has quit IRC14:02
*** tuan has quit IRC14:05
*** marekd has quit IRC14:12
*** piliman974 has joined #openstack-keystone14:18
*** dikonoor has quit IRC14:25
*** edmondsw has joined #openstack-keystone14:29
*** markvoelker_ has joined #openstack-keystone14:29
*** markvoelker has quit IRC14:33
*** david-lyle has quit IRC14:34
*** david-lyle has joined #openstack-keystone14:35
*** shuyingy_ has joined #openstack-keystone14:41
*** shuyingya has quit IRC14:43
*** david-lyle has quit IRC14:52
*** lucasxu has joined #openstack-keystone14:56
*** piliman974 has quit IRC14:56
*** mvk_ has joined #openstack-keystone14:57
*** d0ugal has quit IRC14:57
*** piliman974 has joined #openstack-keystone14:57
*** shuyingy_ has quit IRC14:58
*** aojea has joined #openstack-keystone15:02
knikollao/ morning15:05
gagehugoo/15:05
*** d0ugal has joined #openstack-keystone15:06
*** aojea has quit IRC15:07
*** rderose has joined #openstack-keystone15:22
*** ducttape_ has quit IRC15:29
*** ducttape_ has joined #openstack-keystone15:30
*** pnavarro has quit IRC15:32
*** markvoelker_ has quit IRC15:35
*** nicolasbock has joined #openstack-keystone15:36
*** nicolasbock has quit IRC15:36
*** nicolasbock has joined #openstack-keystone15:37
openstackgerritTin Lam proposed openstack/keystonemiddleware master: Replace pycrypto with cryptography  https://review.openstack.org/45194115:37
*** chlong has joined #openstack-keystone15:39
*** shuyingya has joined #openstack-keystone15:39
*** piliman974 has quit IRC15:42
*** gyee has joined #openstack-keystone15:42
*** shuyingya has quit IRC15:43
*** piliman974 has joined #openstack-keystone15:43
*** belmoreira has quit IRC15:45
*** enriquetaso has joined #openstack-keystone15:56
*** lbragstad has joined #openstack-keystone15:58
*** ChanServ sets mode: +o lbragstad15:58
*** pcaruana has quit IRC15:59
*** david-lyle has joined #openstack-keystone16:03
ayounggagehugo, what is being done with the paths in your latest https://review.openstack.org/#/c/384148/16:03
*** mvk_ has quit IRC16:03
*** lucasxu has quit IRC16:04
gagehugoayoung which paths?16:05
ayounggagehugo, the onese that are stored in the rule-defaults like...16:06
ayounghttps://review.openstack.org/#/c/384148/17/nova/policies/used_limits.py  limits in that one (line 31)16:07
*** mvk has quit IRC16:07
ayounggagehugo, I don't think you introduced this, just it shows up in your changes when diffed against the last one I submitted16:07
gagehugooh16:07
ayounghttps://review.openstack.org/#/c/384148/13..17/nova/policies/base.py  its added in line 4316:08
gagehugoayoung I think that was added when I rebased16:09
ayounggagehugo, yeah, looks like it. I was just wondering if you know what it is being used for?16:09
gagehugoI thought it was part of the policy in code changes16:09
*** rderose has quit IRC16:10
ayounggagehugo, it looks like it, but that code does not need the path.  It is something new.  Isuspect it is just documenation for now, but It smells a lot like linking the policy to the APIs16:11
gagehugoayoung https://github.com/openstack/nova/commit/e48e002264fca2ea44f282edcfac4f7e4655f41016:11
gagehugoayoung ok16:12
ayounggagehugo, wonderful.  Another place for things to get out of sync.16:12
ayoungAnother Nova specific solution16:12
gagehugohmm16:13
*** rcernin has quit IRC16:14
gagehugoayoung so do we need to change anything for https://review.openstack.org/#/c/384148 ?16:15
ayounggagehugo, not that I can see.16:15
ayoungI was just looking at it, and that part caught me by surprise.16:15
gagehugoayoung ah ok16:16
*** lucasxu has joined #openstack-keystone16:18
openstackgerritBoris Kudryavtsev proposed openstack/keystone master: Add user_id_attribute support to _dn_to_id  https://review.openstack.org/46638916:21
*** rcernin has joined #openstack-keystone16:31
*** aojea has joined #openstack-keystone16:32
*** jaosorior is now known as jaosorior_away16:45
knikollaayoung: if you have time, can you have a look at the api keys spec? especially the mechanism for reducing the permission of an api key through a list of api operations permitted.16:54
knikollahttps://review.openstack.org/#/c/450415/16:55
ayoungknikolla, sure.16:55
ayoungknikolla, I just hate the term API key16:56
ayoungit is worse than meaningless. It actively means something different to me.16:56
ayoungDoes that term have prior art?16:56
* knikolla shrugs16:58
*** chlong has quit IRC16:59
ayoungknikolla, there is a stub Wikipedia article.  I am going to assume it was written by mordred17:00
mordredayoung: we chatted about it a little at the summit - I also don't like the term - but there were some decent arguments made in favor of the term17:01
mordredayoung: that said- as a person who does not like it, I'd be more than happy to help sell people on a better term17:01
knikollamordred: ayoung: my main concern is with limiting authorization based on the api_access_list rather than through roles17:02
mordredknikolla: ah - that's much more fundamental :)17:02
mordredfrom an end-user perspective, roles are opaque, too complex and also not granular enough17:03
ayoungmordred, I want my RBAC in middleware spec to go through.  Will make this it easier to do both trusts and API keys17:03
mordredthey're a great tool for a cloud admin17:03
ayoungmordred, did you go to my talk?17:03
ayoungI should say OUR talk17:03
mordredayoung: sadly, I did not17:03
ayoungmordred, I challenge you, then, to view the video first and then come back and talk...I'll link17:04
mordredayoung: k. it'll be a bit before I can video - can you tl;dr me so I can know context?17:04
ayounghttps://www.openstack.org/summit/boston-2017/summit-schedule/events/17462/per-api-role-based-access-control17:04
mordredawesome17:04
ayoungmordred, We want to do RBAC in middleware. THat requires a mapping from ROUte to Key]17:05
ayoungRoute being17:05
ayoungVERB + PATH (Pre substitution)17:05
*** mvk has joined #openstack-keystone17:05
knikollamordred: ayoung: be back in 1 hour. getting lunch17:05
ayoungmordred, there is a view vidow link from the one I posted above which resolve\s to here: https://www.openstack.org/videos/boston-2017/per-api-role-based-access-control17:05
mordredyah. that's a very similar language being discussed here- so that part is good :)17:05
ayoungmordred, right, so, if we get that in, we do API keys based on ROles, but provide a follow on way to better manage the explosion of roles17:06
ayoungmordred, I think we would ideally be able to say that somethihng line compute:create_server IS_A role17:06
ayoungthe problem, of course, is that we still need to map that to the URL that the user wants to call17:07
mordredayoung: so - it's entirely possible that we're actually descibing the same things but just using different words then17:07
ayoungmordred, related, but different17:07
ayoungyou are talking about a lightweight way to make users to consume delegations17:07
ayoungI am talking about a way to expose what is required for delegations17:07
ayoungso, complementary17:08
ayoungmordred, seriously, watch the video when you have time. We tried to lay it out as best we could17:08
mordredright- except the (not yet written) proposal for the users expressing what they want doesn't need anything to expose what is required for an action - since the action is the entry point to the url route17:08
mordredbut ... clearly I need to a) watch your video and also b) write the second spec so you can read it17:09
mordredotherwise the chances we'll figure out the overlaps and the conflicts is pretty low ;)17:09
ayoungmordred, We need a way to enforce what you want in the API Key approach17:10
ayoungIf the delegation is on a resource basis, either that Resource is specified by an URL or something else. If something else, we need to map it.  If an URL...we need to match what we are given when enforcing RBAC17:10
mordredyah - so the short version is very similar to what you were saying above ...17:11
mordred[service-type, interface, version, path]17:11
mordredgah17:12
mordred[service-type, interface, version, verb, path]17:12
mordredor ['compute', 'public', 'v2', 'GET', '/servers']17:12
mordredwhich are concepts that all rest api users can be expected to understand17:12
ayoungmordred, than you17:12
mordredbut explicitly intended to be filtered/enforced at the entry - so if POST /servers needs to then have nova call glance, this has no effect on that17:13
ayoungour separate conclusions are the same.17:13
mordredit's only intended to be about the initial thing the user knows about, not sub-actions that only an operator wouldknow about17:13
*** piliman974 has quit IRC17:13
mordredayoung: yay! it's almost like we've been thinking about hte same problem space fora number of years! :)17:14
ayoungmordred, I left out the first part of the quote17:14
*** lucasxu has quit IRC17:14
ayoung"for all our mutual experience our separate conclusions are the same"  --Billy Joel, "Summer, Highland Falls."17:15
*** chlong has joined #openstack-keystone17:15
mordred:)17:15
*** mvk_ has joined #openstack-keystone17:15
*** chlong has quit IRC17:15
ayoungmordred, so here is where I was going with this.17:16
ayoungI want a user herself to be able to request a token that can only perform the action they want.  Say an admin user talks to some 3rd part servcie, they don't want to give up full admin when that service calls back into her home cloud17:16
ayoungin order to do that, she needs to know what role is required to perform the actions.  No way to do that today17:17
ayoungso, make it possible to introspect, but also make a new token type that can record just that role17:17
ayoungand so https://review.openstack.org/#/c/310074/17:17
ayounguse the implied roles mechanism to say "this role here has to perform two operations, but we want to be able to also split out those two operations"17:18
*** jmccrory_away is now known as jmccrory17:18
ayoungso, the most fine-grained case would be one ROLE per operation17:18
ayoungbut...I suspect that we don't need to jump right to that state17:19
ayoungI suspect that, actually, we only want one-role-per-operation for a very limited subset of operations17:19
ayoungso, lets get the mechanism in place, and see what people actually end up breaking out into their own roles17:19
ayoungwith the oauth1 implementation we have now, we can, in essence, do the API key thing17:20
ayoungbut we need the other half, the "here's the role you need" in order to implement it.17:20
ayoungmordred, once we have both those pieces, we can put together your API-Key as syntatic sugar.  MMmm. Sugar,17:21
*** piliman974 has joined #openstack-keystone17:25
mordredayoung: sugar is nice17:27
mordredayoung: however, fwiw, there was a strong sense in the room about not tying it to existing oauth implementations17:27
mordredayoung: because that involves the operator doing a thing and setting up something new17:27
ayoungmordred, yeah, well my point is the mechanisms are there already.  We can reuse them17:28
ayoungessentailly, the "a consumer is a lightweight user" part17:28
mordredk. we might be meaning differnet things by 'consume' and 'reuse' then :)17:28
mordrednod17:28
ayoungIn other words, I'm ok with different APIs, but not with different internal representations.17:29
mordredbut also -yes. ... this is one of the reason that v1 of the api-key spec leaves limited scoping to a follow up17:29
mordredyah - and the internal representations are all the same to me - I want the user-api to be _essentially_ the same as password auth consumption is today - since all the libs out there have that implemented already17:30
mordredit'll take a bit to sort out the things related to roles and expressing the subset of operations thing in a way that'll please everyone17:30
mordredbut even just getting the lightweight user that has the same privs as the existing user but can be key rotated is a big win for some folks17:31
morganmordred: i don't think it's going to be too hard to do the subset thing... really17:31
morganbut i mean... it's about the same as any of those concerns. generally ++ on everything you just said17:31
mordredmorgan: I agree - but getting _agreement_ on it might take until next cycle :)17:31
morgansure17:31
ayoungmordred, essentially "Allow a user to create a user in a different domain, but don't let them specify the username or provider them any roles.  Then, via adelegation mechanism, let them use a subset of the users roles."   oh, and laso "Make it easy to map the roles to the resources they actually reflect"17:31
mordred_implementing_ is gonna be like na afternoon17:31
mordredayoung: you said too many implementation details17:32
* morgan grumps about neck pain post sleeping on a plane... but Fishing with dynamite was worth it...17:32
mordredmorgan: ++17:32
ayoungmordred, that is because I actually understand delegation in Keystone.  I just have crap social skills17:32
mordredayoung: yes. I'm the translation layer between full understanding of keystone internals and no understanding ... I know just enough to understand you -and still little enough to know which bits people don't get17:33
mordredit's like teamwork17:33
mordredayoung: so - my concern when we talk about _actually_ creating a User object somewhere is the folks who are using LDAP/AD and don't want OpenStack creating users. it's possible that's not a problem beause my knjowledge of the internals is not good enough17:34
mordredbut if the implementation winds up meaning that LDAP/AD users in that situation can't create api-keys, then we've done something wrong17:35
ayoungmordred, right.  So we have a slew of different terms that people use in different technologies for just such a reason.  IN Kerberos, they say principals, in X509, Subjest, in OAuth Consumers, and I am guessign the api-key comes from somewhere, too.17:35
mordredayoung: yah - it's used from other rest apis17:36
ayoungmordred, I found the wikipedia stub, but Citation very needed17:36
ayoungIs this a googlism?17:36
mordredbut I guess I meant: s/can't create api-keys/can't create api-keys without the deployer configuring some sort of new local storage in which to put non-federated local lightweight users/17:36
mordredayoung: I honestly don't know - it wasn't my term. I complained originally but people generally preferred api-key to what felt like inventing a new term in openstack17:37
mordredI've been trying to avoid that particular bikeshed17:37
ayoungwe've used the term service users for years17:37
ayoungmordred, and that is also what Kubernetes calls them.  Uses them all over the place.17:39
*** aojea has quit IRC17:41
*** aojea has joined #openstack-keystone17:41
mordredyah - but that term has a specific meaning in openstack operator land - the "service user" is the User one uses for one Service to talk to another Service17:41
mordredthe thing we're talking about here is "a thing that allows any 'application' to talk to the API" (although I also hate the word application in this context since _it_ has connotations too17:42
mordredso - we could TOTALLY call it a Service User - but then what does the operator call the User account they create which which to create the new ServiceUser thing?17:43
mordredAND - does the presence of the word "User" in word ServiceUser freat out any corporate compliance people?17:43
mordred(both real questions, non-rhetorical)17:43
bkudryavtsevo/ Attempting to write a test for bug 1692090. How would I go about creating a fake LDAP database?17:44
openstackbug 1692090 in OpenStack Identity (keystone) "_dn_to_id ignores user_id_attribute" [Undecided,In progress] https://launchpad.net/bugs/1692090 - Assigned to Boris Kudryavtsev (bkudryavtsev)17:44
*** sjain has joined #openstack-keystone17:45
*** aojea has quit IRC17:45
ayoungbkudryavtsev, you would not17:46
ayoungbkudryavtsev, you can only create real ldap database.  Fake ldap database don't exist.  They are fake.17:47
ayoungmordred, which is why I suggest, instead, that we build on top of the oauth abstractions, which calls them "consumers" instead.17:48
ayoungand we will hide the fact that, ujnder the covers, they are all just entries in a user table.17:48
sjainHi, I made some changes in keystone docs theme, the link is here https://review.openstack.org/#/c/466066/, I'm not clear about the last comment17:51
mordredayoung: yes - totally agree on the just entries in the user table part ...17:51
sjaincan anyone please explain me what is the missing here17:51
ayoungmordred, so help me push the RBAC in middleware vision and you get your API-Keys17:52
mordredayoung: are you suggesting we call the end-user manifestation a "consumer"? like POST /consumers ?17:52
knikollabkudryavtsev: see my wip patch here https://review.openstack.org/#/c/466406/ where i directly modify the directory in fakeldap17:52
mordredor is the api-key word concern more from teh internal conceptual place?17:52
ayoungmordred, I really don't care what we call it, so long as we use the existing mechanisms17:52
ayoungwe can call it API keys for all I care17:52
ayoungI care about getting a unified delegation model17:53
ayoungso that, when tomorrow they are some XACML abstraction we don't need to write something for that, too.17:53
mordredok. cool17:53
* knikolla lurks on the discussion17:53
mordredI believe I understand what your concerns are and at what level they sit - and it doesn't sound like there are any intractable concerns17:54
mordredI'll be doing another rev ont he spec tomorrow - I'll try to wordsmith some of this in there a bit17:54
*** mvk_ has quit IRC17:54
ayoungmordred, to be clear, this is a battle I've been fighting and losing for year.  https://review.openstack.org/#/q/Unified+Delegation  Amakarov was working from my spec17:55
*** chlong has joined #openstack-keystone17:55
ayoungmordred, I really just want my damn spec merged17:58
ayoungweigh in on that, and we can base your approach on it.  https://review.openstack.org/#/c/452198/17:59
ayoungmordred, write your spec in terms of that one and you will have an avid supporter from me18:00
ayoungmordred, and to be honest, without that one, I don;'t think we have a way to enforce what you want from API keys18:01
mordredwell - that's the basis for the second spec - not the first one. implementation details of rbac and limited access is explicitly not in this one18:01
mordredbut yet- the follow up spec to api-keys that explains how to request ones that do less things is where we get into the rbac related things18:01
mordreds/but yet/but yes/18:01
ayoungmordred, actually, all I really want from the first spec is a justification for the term API-Key18:02
mordred:)18:02
mordredI'll do my best18:02
ayoungand perhaps an indication that it can be implemented useing new APIs but existing mechanisms.18:02
ayoungadd in the users vs consumers discussion as to why we want this term18:02
mordredayoung: https://developers.google.com/maps/documentation/javascript/get-api-key http://kb.mailchimp.com/integrations/api-integrations/about-api-keys https://stormpath.com/blog/top-six-reasons-use-api-keys-and-how https://secure.meetup.com/meetup_api/key/18:04
mordredI believe its use commonly across REST API things is why people like it18:04
ayoungmordred, awesome.  Stick it in the "references section"  of the spec.18:04
mordredit's tough to argue more strongly for it since I'm proxy-arguing on their behalf in the first place18:04
mordredkk18:04
*** r-daneel has joined #openstack-keystone18:09
ayoungmordred, sorry to be a stickler here, but it seems that if I turn my back on these kinds of extensions, we end up with a new mechanism, instead of reworking the existing ones to cover the wider use cases.  I had a lot of pains in getting trusts merged, mostly due to dolphm being very detailed oriented in how delegations should work, but he was right, and I want to make sure any additional delegation mechanisms don't lost18:09
ayoung those lessons learned.18:09
*** lucasxu has joined #openstack-keystone18:12
*** stingaci has quit IRC18:17
raildogagehugo, ping :)18:17
*** stingaci has joined #openstack-keystone18:18
gagehugoraildo pong18:18
raildogagehugo, hey sir, everything ok?18:18
raildogagehugo, Do you have some free time to talk about our plan for oslo.config?18:18
gagehugoraildo I have an hour now if that works18:19
raildogagehugo, it will be just a few minutes :)18:20
gagehugosure18:20
raildogagehugo, actually, I would like to mention that we have a public irc channel with the entire Custodia team, so, if you could be there too, this would be great18:21
gagehugoraildo sure18:21
raildogagehugo, #latchset18:21
ayoungraildo, bring them here18:21
ayoungraildo, I know they all *get it*,  less convinced that the Keystone folks do18:21
ayoungand that is where we need to convince people.18:21
raildoayoung, I think will be easier to discuss this there, since is more related to oslo than keystone at this point18:21
raildoayoung, yeap, makes sense too18:21
ayoungraildo, but Keystoners are the people in OpenStack that understand security.  But I can check in there, if you would prefer18:22
mordredayoung: totally understand and appreciated ... I'm mostly writing this at the moment from a "this is how it needs to operate from a user perspective" place and not from a "this use case means this implementation detail"18:22
raildoayoung, I'm ok with either way18:22
gagehugolamt #latchset18:23
ayoungraildo, also, is #latchset logged yet?18:24
ayoungCuz this room is evesdropped18:24
raildoayoung, yeap18:24
ayoungExcellent18:24
raildoI just need to remember where, but I'll take a look on it18:24
*** catinth__ has quit IRC18:28
*** catintheroof has joined #openstack-keystone18:30
*** harlowja has joined #openstack-keystone18:37
*** masuberu has quit IRC18:39
*** dave-mccowan has quit IRC18:41
*** lucasxu has quit IRC18:41
*** lucasxu has joined #openstack-keystone18:43
*** harlowja has quit IRC18:43
*** lucasxu has quit IRC18:58
*** lucasxu has joined #openstack-keystone19:03
*** aojea has joined #openstack-keystone19:11
*** nicolasbock has quit IRC19:13
*** pnavarro has joined #openstack-keystone19:23
*** stingaci has quit IRC19:44
*** sjain has quit IRC19:48
*** aojea has quit IRC19:56
*** aojea has joined #openstack-keystone19:56
*** aojea_ has joined #openstack-keystone20:00
*** aojea has quit IRC20:01
*** stingaci has joined #openstack-keystone20:04
*** nicolasbock has joined #openstack-keystone20:06
*** chlong has quit IRC20:07
ayoungstevemar, how do I bring something up before the technical committee?20:08
*** stingaci has quit IRC20:08
openstackgerritBoris Kudryavtsev proposed openstack/keystone master: Add user_id_attribute support to _dn_to_id  https://review.openstack.org/46638920:11
morganayoung: usually you send an email and ask the chair/someone on the TC to add it to the agenda20:12
morganemail to -dev list... this may have changed since I last paid attention20:12
*** arunkant_ has quit IRC20:13
*** stingaci has joined #openstack-keystone20:14
*** stingaci has quit IRC20:14
*** stingaci has joined #openstack-keystone20:14
*** lbragstad has quit IRC20:26
*** stingaci has quit IRC20:29
*** chlong has joined #openstack-keystone20:31
*** ducttape_ has quit IRC20:39
*** ducttape_ has joined #openstack-keystone20:40
*** chlong has quit IRC20:41
*** thorst_afk has quit IRC20:58
*** thorst_afk has joined #openstack-keystone20:59
*** thorst_afk has quit IRC21:03
*** dave-mccowan has joined #openstack-keystone21:05
*** ducttape_ has quit IRC21:08
*** ducttape_ has joined #openstack-keystone21:09
*** spilla has quit IRC21:10
*** davechen has quit IRC21:22
*** catintheroof has quit IRC21:22
*** davechen has joined #openstack-keystone21:23
*** catintheroof has joined #openstack-keystone21:29
*** stingaci has joined #openstack-keystone21:30
*** stingaci has quit IRC21:35
*** thorst_afk has joined #openstack-keystone21:36
*** thorst_afk has quit IRC21:40
openstackgerritMerged openstack/oslo.policy master: Check reStructuredText documents for common style issues.  https://review.openstack.org/44941021:55
*** lucasxu has quit IRC21:58
*** ducttape_ has quit IRC22:12
*** ducttape_ has joined #openstack-keystone22:12
*** aojea_ has quit IRC22:14
*** aojea has joined #openstack-keystone22:14
*** aojea has quit IRC22:18
*** adriant has joined #openstack-keystone22:19
openstackgerritTin Lam proposed openstack/keystonemiddleware master: Replace pycrypto with cryptography  https://review.openstack.org/45194122:25
*** jdennis has quit IRC22:41
*** jdennis has joined #openstack-keystone22:45
*** r-daneel has quit IRC22:47
*** ducttape_ has quit IRC22:49
*** ducttape_ has joined #openstack-keystone22:50
*** ducttap__ has joined #openstack-keystone22:54
*** ducttape_ has quit IRC22:54
*** thorst_afk has joined #openstack-keystone23:00
*** thorst_afk has quit IRC23:04
*** thorst_afk has joined #openstack-keystone23:05
*** lamt has quit IRC23:06
*** ducttap__ has quit IRC23:08
*** thorst_afk has quit IRC23:09
*** piliman974 has quit IRC23:23
*** piliman974 has joined #openstack-keystone23:24
*** catintheroof has quit IRC23:40
*** nicolasbock has quit IRC23:40
openstackgerritColleen Murphy proposed openstack/keystonemiddleware master: Test migration from pycrypto to cryptography  https://review.openstack.org/46693823:44
*** catintheroof has joined #openstack-keystone23:48
*** catintheroof has quit IRC23:59

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