*** jamielennox|away is now known as jamielennox | 00:02 | |
*** markvoelker has quit IRC | 00:11 | |
*** thorst_afk has joined #openstack-keystone | 00:19 | |
*** thorst_afk has quit IRC | 00:24 | |
*** Shunli has joined #openstack-keystone | 00:33 | |
*** links has joined #openstack-keystone | 00:54 | |
*** thorst_afk has joined #openstack-keystone | 01:02 | |
*** thorst_afk has quit IRC | 01:04 | |
*** thorst_afk has joined #openstack-keystone | 01:58 | |
*** jamielennox is now known as jamielennox|away | 02:00 | |
*** shuyingya has joined #openstack-keystone | 02:05 | |
*** shuyingy_ has joined #openstack-keystone | 02:24 | |
openstackgerrit | zhengliuyang proposed openstack/keystone master: Add notes about revocations https://review.openstack.org/466567 | 02:26 |
---|---|---|
*** shuyingya has quit IRC | 02:28 | |
*** aojea has joined #openstack-keystone | 02:37 | |
*** aojea has quit IRC | 02:41 | |
openstackgerrit | zhengliuyang proposed openstack/keystone master: Quotation marks should be included in http url using curl https://review.openstack.org/458736 | 02:48 |
openstackgerrit | Ngo Quoc Cuong proposed openstack/keystone master: Remove the deprecated tempest.test.attr https://review.openstack.org/466574 | 02:52 |
*** thorst_afk has joined #openstack-keystone | 02:57 | |
*** jhesketh_ is now known as jhesketh | 03:08 | |
openstackgerrit | zhengliuyang proposed openstack/keystone master: Add response example in authenticate-v3.inc https://review.openstack.org/463245 | 03:17 |
*** thorst_afk has joined #openstack-keystone | 03:28 | |
*** lamt has joined #openstack-keystone | 03:46 | |
*** thorst_afk has quit IRC | 03:46 | |
*** jamielennox|away is now known as jamielennox | 03:53 | |
*** jaosorior has joined #openstack-keystone | 04:52 | |
*** lamt has quit IRC | 05:16 | |
*** stingaci has joined #openstack-keystone | 05:20 | |
*** stingaci has quit IRC | 05:25 | |
*** thorst_afk has joined #openstack-keystone | 05:43 | |
*** thorst_afk has quit IRC | 05:48 | |
*** tobberydberg has joined #openstack-keystone | 05:56 | |
*** lamt has joined #openstack-keystone | 06:07 | |
*** belmoreira has joined #openstack-keystone | 06:07 | |
*** gyee has joined #openstack-keystone | 06:08 | |
*** shuyingy_ has quit IRC | 06:13 | |
*** shuyingya has joined #openstack-keystone | 06:13 | |
*** shuyingy_ has joined #openstack-keystone | 06:19 | |
*** rcernin has joined #openstack-keystone | 06:19 | |
*** shuyingya has quit IRC | 06:22 | |
*** gyee has quit IRC | 06:31 | |
*** thorst_afk has joined #openstack-keystone | 06:44 | |
*** thorst_afk has quit IRC | 06:49 | |
*** tobberyd_ has joined #openstack-keystone | 07:03 | |
*** tobberydberg has quit IRC | 07:06 | |
*** pcaruana has joined #openstack-keystone | 07:11 | |
*** zsli_ has joined #openstack-keystone | 07:12 | |
*** pcaruana has quit IRC | 07:12 | |
*** pcaruana has joined #openstack-keystone | 07:13 | |
*** rcernin has quit IRC | 07:14 | |
*** rcernin has joined #openstack-keystone | 07:14 | |
*** Shunli has quit IRC | 07:15 | |
*** aojea has joined #openstack-keystone | 07:19 | |
*** lamt has quit IRC | 07:35 | |
*** david-lyle has quit IRC | 07:36 | |
*** hoonetorg has quit IRC | 07:39 | |
*** david-lyle has joined #openstack-keystone | 07:42 | |
*** thorst_afk has joined #openstack-keystone | 07:45 | |
*** david-lyle has quit IRC | 07:46 | |
*** thorst_afk has quit IRC | 07:50 | |
*** hoonetorg has joined #openstack-keystone | 07:54 | |
*** zzzeek has quit IRC | 08:00 | |
*** zzzeek has joined #openstack-keystone | 08:01 | |
*** david-lyle has joined #openstack-keystone | 08:03 | |
*** tobberyd_ has quit IRC | 08:14 | |
*** adriant has quit IRC | 08:28 | |
*** zian has joined #openstack-keystone | 08:30 | |
*** tuan_ has joined #openstack-keystone | 08:32 | |
zian | Hello everyone. I would like to know if login with gmail/facebook credentials is applicable to access a public openstack cloud. | 08:32 |
zian | Any inputs on this would help | 08:32 |
tuan_ | morning guys, | 08:33 |
*** tuan_ has left #openstack-keystone | 08:33 | |
openstackgerrit | zhengliuyang proposed openstack/keystone master: More messages about validating token failed https://review.openstack.org/463641 | 08:39 |
breton | zian: gmail -- probably yes, it provides openid connect | 08:42 |
zian | Thanks for your reply @breton. Any openstack document on how to proceed? | 08:45 |
*** thorst_afk has joined #openstack-keystone | 08:46 | |
*** zsli__ has joined #openstack-keystone | 08:46 | |
*** tuan__ has joined #openstack-keystone | 08:47 | |
*** zsli_ has quit IRC | 08:49 | |
*** tobberydberg has joined #openstack-keystone | 08:50 | |
zian | breton: 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 IRC | 08:54 | |
*** tobberydberg has joined #openstack-keystone | 09:02 | |
*** zian has quit IRC | 09:04 | |
*** thorst_afk has quit IRC | 09:05 | |
breton | aaand he quit | 09:06 |
*** pnavarro has joined #openstack-keystone | 09:22 | |
*** mvk has quit IRC | 09:36 | |
*** zsli__ has quit IRC | 09:38 | |
*** stingaci has joined #openstack-keystone | 09:42 | |
*** thorst_afk has joined #openstack-keystone | 10:02 | |
*** mvk has joined #openstack-keystone | 10:06 | |
*** thorst_afk has quit IRC | 10:07 | |
*** stingaci has quit IRC | 10:21 | |
*** ayoung has joined #openstack-keystone | 10:23 | |
samueldmq | morning keystone | 10:28 |
*** tobberydberg has quit IRC | 10:45 | |
*** Shunli has joined #openstack-keystone | 10:48 | |
*** Shunli has quit IRC | 10:49 | |
*** toddnni has quit IRC | 10:54 | |
*** toddnni has joined #openstack-keystone | 11:00 | |
*** thorst_afk has joined #openstack-keystone | 11:18 | |
*** toddnni has quit IRC | 11:22 | |
*** dave-mccowan has joined #openstack-keystone | 11:30 | |
*** toddnni has joined #openstack-keystone | 11:33 | |
*** mvk has quit IRC | 12:07 | |
*** edmondsw has joined #openstack-keystone | 12:15 | |
*** edmondsw has quit IRC | 12:16 | |
*** raildo has joined #openstack-keystone | 12:21 | |
*** chlong has joined #openstack-keystone | 12:29 | |
*** mvk has joined #openstack-keystone | 12:32 | |
samueldmq | cmurphy: ping - re https://review.openstack.org/#/c/451941 | 12:36 |
cmurphy | samueldmq: hi | 12:36 |
*** dikonoor has joined #openstack-keystone | 12:36 | |
samueldmq | cmurphy: just saw your comment, a byte has 8 bits, so I can't see how 16 became 256 yet :-) | 12:37 |
samueldmq | cmurphy: shouldn't it become 128 then? | 12:38 |
*** stingaci has joined #openstack-keystone | 12:38 | |
cmurphy | samueldmq: hmm maybe my +2 was too fast | 12:41 |
*** catintheroof has joined #openstack-keystone | 12:41 | |
samueldmq | cmurphy: there is a backward compatibility testing in http://paste.openstack.org/show/606401/ | 12:42 |
cmurphy | samueldmq: i saw that, also did some manual testing, but you're right that the pycrypto default block size was 16 bytes not 32 | 12:44 |
*** tuan__ has quit IRC | 12:44 | |
*** tuan has joined #openstack-keystone | 12:46 | |
samueldmq | cmurphy: it is failing for me on Python3 http://paste.openstack.org/show/610168/ | 12:49 |
*** chlong has quit IRC | 12:55 | |
*** xuhaigang has quit IRC | 12:55 | |
*** shuyingy_ has quit IRC | 13:00 | |
*** lamt has joined #openstack-keystone | 13:04 | |
*** markvoelker has joined #openstack-keystone | 13:22 | |
*** yunus has joined #openstack-keystone | 13:25 | |
yunus | I 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 helping | 13:26 |
yunus | Some geeks says that do not use SELinux with Ubuntu. https://ubuntuforums.org/showthread.php?t=2324011 | 13:27 |
*** spilla has joined #openstack-keystone | 13:28 | |
cmurphy | yunus: 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 anything | 13:31 |
yunus | cmurphy thanks for helping. I will try this. | 13:31 |
*** markvoelker has quit IRC | 13:35 | |
*** ducttape_ has joined #openstack-keystone | 13:35 | |
*** markvoelker has joined #openstack-keystone | 13:35 | |
*** shuyingya has joined #openstack-keystone | 13:40 | |
*** shuyingya has quit IRC | 13:44 | |
*** shuyingya has joined #openstack-keystone | 13:45 | |
*** yunus has quit IRC | 13:47 | |
*** catinthe_ has joined #openstack-keystone | 13:53 | |
*** catinth__ has joined #openstack-keystone | 13:53 | |
*** catintheroof has quit IRC | 13:54 | |
*** links has quit IRC | 13:57 | |
*** catinthe_ has quit IRC | 13:57 | |
*** aojea has quit IRC | 14:02 | |
*** tuan has quit IRC | 14:05 | |
*** marekd has quit IRC | 14:12 | |
*** piliman974 has joined #openstack-keystone | 14:18 | |
*** dikonoor has quit IRC | 14:25 | |
*** edmondsw has joined #openstack-keystone | 14:29 | |
*** markvoelker_ has joined #openstack-keystone | 14:29 | |
*** markvoelker has quit IRC | 14:33 | |
*** david-lyle has quit IRC | 14:34 | |
*** david-lyle has joined #openstack-keystone | 14:35 | |
*** shuyingy_ has joined #openstack-keystone | 14:41 | |
*** shuyingya has quit IRC | 14:43 | |
*** david-lyle has quit IRC | 14:52 | |
*** lucasxu has joined #openstack-keystone | 14:56 | |
*** piliman974 has quit IRC | 14:56 | |
*** mvk_ has joined #openstack-keystone | 14:57 | |
*** d0ugal has quit IRC | 14:57 | |
*** piliman974 has joined #openstack-keystone | 14:57 | |
*** shuyingy_ has quit IRC | 14:58 | |
*** aojea has joined #openstack-keystone | 15:02 | |
knikolla | o/ morning | 15:05 |
gagehugo | o/ | 15:05 |
*** d0ugal has joined #openstack-keystone | 15:06 | |
*** aojea has quit IRC | 15:07 | |
*** rderose has joined #openstack-keystone | 15:22 | |
*** ducttape_ has quit IRC | 15:29 | |
*** ducttape_ has joined #openstack-keystone | 15:30 | |
*** pnavarro has quit IRC | 15:32 | |
*** markvoelker_ has quit IRC | 15:35 | |
*** nicolasbock has joined #openstack-keystone | 15:36 | |
*** nicolasbock has quit IRC | 15:36 | |
*** nicolasbock has joined #openstack-keystone | 15:37 | |
openstackgerrit | Tin Lam proposed openstack/keystonemiddleware master: Replace pycrypto with cryptography https://review.openstack.org/451941 | 15:37 |
*** chlong has joined #openstack-keystone | 15:39 | |
*** shuyingya has joined #openstack-keystone | 15:39 | |
*** piliman974 has quit IRC | 15:42 | |
*** gyee has joined #openstack-keystone | 15:42 | |
*** shuyingya has quit IRC | 15:43 | |
*** piliman974 has joined #openstack-keystone | 15:43 | |
*** belmoreira has quit IRC | 15:45 | |
*** enriquetaso has joined #openstack-keystone | 15:56 | |
*** lbragstad has joined #openstack-keystone | 15:58 | |
*** ChanServ sets mode: +o lbragstad | 15:58 | |
*** pcaruana has quit IRC | 15:59 | |
*** david-lyle has joined #openstack-keystone | 16:03 | |
ayoung | gagehugo, what is being done with the paths in your latest https://review.openstack.org/#/c/384148/ | 16:03 |
*** mvk_ has quit IRC | 16:03 | |
*** lucasxu has quit IRC | 16:04 | |
gagehugo | ayoung which paths? | 16:05 |
ayoung | gagehugo, the onese that are stored in the rule-defaults like... | 16:06 |
ayoung | https://review.openstack.org/#/c/384148/17/nova/policies/used_limits.py limits in that one (line 31) | 16:07 |
*** mvk has quit IRC | 16:07 | |
ayoung | gagehugo, I don't think you introduced this, just it shows up in your changes when diffed against the last one I submitted | 16:07 |
gagehugo | oh | 16:07 |
ayoung | https://review.openstack.org/#/c/384148/13..17/nova/policies/base.py its added in line 43 | 16:08 |
gagehugo | ayoung I think that was added when I rebased | 16:09 |
ayoung | gagehugo, yeah, looks like it. I was just wondering if you know what it is being used for? | 16:09 |
gagehugo | I thought it was part of the policy in code changes | 16:09 |
*** rderose has quit IRC | 16:10 | |
ayoung | gagehugo, 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 APIs | 16:11 |
gagehugo | ayoung https://github.com/openstack/nova/commit/e48e002264fca2ea44f282edcfac4f7e4655f410 | 16:11 |
gagehugo | ayoung ok | 16:12 |
ayoung | gagehugo, wonderful. Another place for things to get out of sync. | 16:12 |
ayoung | Another Nova specific solution | 16:12 |
gagehugo | hmm | 16:13 |
*** rcernin has quit IRC | 16:14 | |
gagehugo | ayoung so do we need to change anything for https://review.openstack.org/#/c/384148 ? | 16:15 |
ayoung | gagehugo, not that I can see. | 16:15 |
ayoung | I was just looking at it, and that part caught me by surprise. | 16:15 |
gagehugo | ayoung ah ok | 16:16 |
*** lucasxu has joined #openstack-keystone | 16:18 | |
openstackgerrit | Boris Kudryavtsev proposed openstack/keystone master: Add user_id_attribute support to _dn_to_id https://review.openstack.org/466389 | 16:21 |
*** rcernin has joined #openstack-keystone | 16:31 | |
*** aojea has joined #openstack-keystone | 16:32 | |
*** jaosorior is now known as jaosorior_away | 16:45 | |
knikolla | ayoung: 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 |
knikolla | https://review.openstack.org/#/c/450415/ | 16:55 |
ayoung | knikolla, sure. | 16:55 |
ayoung | knikolla, I just hate the term API key | 16:56 |
ayoung | it is worse than meaningless. It actively means something different to me. | 16:56 |
ayoung | Does that term have prior art? | 16:56 |
* knikolla shrugs | 16:58 | |
*** chlong has quit IRC | 16:59 | |
ayoung | knikolla, there is a stub Wikipedia article. I am going to assume it was written by mordred | 17:00 |
mordred | ayoung: 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 term | 17:01 |
mordred | ayoung: that said- as a person who does not like it, I'd be more than happy to help sell people on a better term | 17:01 |
knikolla | mordred: ayoung: my main concern is with limiting authorization based on the api_access_list rather than through roles | 17:02 |
mordred | knikolla: ah - that's much more fundamental :) | 17:02 |
mordred | from an end-user perspective, roles are opaque, too complex and also not granular enough | 17:03 |
ayoung | mordred, I want my RBAC in middleware spec to go through. Will make this it easier to do both trusts and API keys | 17:03 |
mordred | they're a great tool for a cloud admin | 17:03 |
ayoung | mordred, did you go to my talk? | 17:03 |
ayoung | I should say OUR talk | 17:03 |
mordred | ayoung: sadly, I did not | 17:03 |
ayoung | mordred, I challenge you, then, to view the video first and then come back and talk...I'll link | 17:04 |
mordred | ayoung: k. it'll be a bit before I can video - can you tl;dr me so I can know context? | 17:04 |
ayoung | https://www.openstack.org/summit/boston-2017/summit-schedule/events/17462/per-api-role-based-access-control | 17:04 |
mordred | awesome | 17:04 |
ayoung | mordred, We want to do RBAC in middleware. THat requires a mapping from ROUte to Key] | 17:05 |
ayoung | Route being | 17:05 |
ayoung | VERB + PATH (Pre substitution) | 17:05 |
*** mvk has joined #openstack-keystone | 17:05 | |
knikolla | mordred: ayoung: be back in 1 hour. getting lunch | 17:05 |
ayoung | mordred, 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-control | 17:05 |
mordred | yah. that's a very similar language being discussed here- so that part is good :) | 17:05 |
ayoung | mordred, 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 roles | 17:06 |
ayoung | mordred, I think we would ideally be able to say that somethihng line compute:create_server IS_A role | 17:06 |
ayoung | the problem, of course, is that we still need to map that to the URL that the user wants to call | 17:07 |
mordred | ayoung: so - it's entirely possible that we're actually descibing the same things but just using different words then | 17:07 |
ayoung | mordred, related, but different | 17:07 |
ayoung | you are talking about a lightweight way to make users to consume delegations | 17:07 |
ayoung | I am talking about a way to expose what is required for delegations | 17:07 |
ayoung | so, complementary | 17:08 |
ayoung | mordred, seriously, watch the video when you have time. We tried to lay it out as best we could | 17:08 |
mordred | right- 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 route | 17:08 |
mordred | but ... clearly I need to a) watch your video and also b) write the second spec so you can read it | 17:09 |
mordred | otherwise the chances we'll figure out the overlaps and the conflicts is pretty low ;) | 17:09 |
ayoung | mordred, We need a way to enforce what you want in the API Key approach | 17:10 |
ayoung | If 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 RBAC | 17:10 |
mordred | yah - so the short version is very similar to what you were saying above ... | 17:11 |
mordred | [service-type, interface, version, path] | 17:11 |
mordred | gah | 17:12 |
mordred | [service-type, interface, version, verb, path] | 17:12 |
mordred | or ['compute', 'public', 'v2', 'GET', '/servers'] | 17:12 |
mordred | which are concepts that all rest api users can be expected to understand | 17:12 |
ayoung | mordred, than you | 17:12 |
mordred | but 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 that | 17:13 |
ayoung | our separate conclusions are the same. | 17:13 |
mordred | it's only intended to be about the initial thing the user knows about, not sub-actions that only an operator wouldknow about | 17:13 |
*** piliman974 has quit IRC | 17:13 | |
mordred | ayoung: yay! it's almost like we've been thinking about hte same problem space fora number of years! :) | 17:14 |
ayoung | mordred, I left out the first part of the quote | 17:14 |
*** lucasxu has quit IRC | 17:14 | |
ayoung | "for all our mutual experience our separate conclusions are the same" --Billy Joel, "Summer, Highland Falls." | 17:15 |
*** chlong has joined #openstack-keystone | 17:15 | |
mordred | :) | 17:15 |
*** mvk_ has joined #openstack-keystone | 17:15 | |
*** chlong has quit IRC | 17:15 | |
ayoung | mordred, so here is where I was going with this. | 17:16 |
ayoung | I 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 cloud | 17:16 |
ayoung | in order to do that, she needs to know what role is required to perform the actions. No way to do that today | 17:17 |
ayoung | so, make it possible to introspect, but also make a new token type that can record just that role | 17:17 |
ayoung | and so https://review.openstack.org/#/c/310074/ | 17:17 |
ayoung | use 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 jmccrory | 17:18 | |
ayoung | so, the most fine-grained case would be one ROLE per operation | 17:18 |
ayoung | but...I suspect that we don't need to jump right to that state | 17:19 |
ayoung | I suspect that, actually, we only want one-role-per-operation for a very limited subset of operations | 17:19 |
ayoung | so, lets get the mechanism in place, and see what people actually end up breaking out into their own roles | 17:19 |
ayoung | with the oauth1 implementation we have now, we can, in essence, do the API key thing | 17:20 |
ayoung | but we need the other half, the "here's the role you need" in order to implement it. | 17:20 |
ayoung | mordred, once we have both those pieces, we can put together your API-Key as syntatic sugar. MMmm. Sugar, | 17:21 |
*** piliman974 has joined #openstack-keystone | 17:25 | |
mordred | ayoung: sugar is nice | 17:27 |
mordred | ayoung: however, fwiw, there was a strong sense in the room about not tying it to existing oauth implementations | 17:27 |
mordred | ayoung: because that involves the operator doing a thing and setting up something new | 17:27 |
ayoung | mordred, yeah, well my point is the mechanisms are there already. We can reuse them | 17:28 |
ayoung | essentailly, the "a consumer is a lightweight user" part | 17:28 |
mordred | k. we might be meaning differnet things by 'consume' and 'reuse' then :) | 17:28 |
mordred | nod | 17:28 |
ayoung | In other words, I'm ok with different APIs, but not with different internal representations. | 17:29 |
mordred | but also -yes. ... this is one of the reason that v1 of the api-key spec leaves limited scoping to a follow up | 17:29 |
mordred | yah - 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 already | 17:30 |
mordred | it'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 everyone | 17:30 |
mordred | but 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 folks | 17:31 |
morgan | mordred: i don't think it's going to be too hard to do the subset thing... really | 17:31 |
morgan | but i mean... it's about the same as any of those concerns. generally ++ on everything you just said | 17:31 |
mordred | morgan: I agree - but getting _agreement_ on it might take until next cycle :) | 17:31 |
morgan | sure | 17:31 |
ayoung | mordred, 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 afternoon | 17:31 |
mordred | ayoung: you said too many implementation details | 17:32 |
* morgan grumps about neck pain post sleeping on a plane... but Fishing with dynamite was worth it... | 17:32 | |
mordred | morgan: ++ | 17:32 |
ayoung | mordred, that is because I actually understand delegation in Keystone. I just have crap social skills | 17:32 |
mordred | ayoung: 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 get | 17:33 |
mordred | it's like teamwork | 17:33 |
mordred | ayoung: 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 enough | 17:34 |
mordred | but if the implementation winds up meaning that LDAP/AD users in that situation can't create api-keys, then we've done something wrong | 17:35 |
ayoung | mordred, 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 |
mordred | ayoung: yah - it's used from other rest apis | 17:36 |
ayoung | mordred, I found the wikipedia stub, but Citation very needed | 17:36 |
ayoung | Is this a googlism? | 17:36 |
mordred | but 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 |
mordred | ayoung: 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 openstack | 17:37 |
mordred | I've been trying to avoid that particular bikeshed | 17:37 |
ayoung | we've used the term service users for years | 17:37 |
ayoung | mordred, and that is also what Kubernetes calls them. Uses them all over the place. | 17:39 |
*** aojea has quit IRC | 17:41 | |
*** aojea has joined #openstack-keystone | 17:41 | |
mordred | yah - 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 Service | 17:41 |
mordred | the 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 too | 17:42 |
mordred | so - 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 |
mordred | AND - 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 |
bkudryavtsev | o/ Attempting to write a test for bug 1692090. How would I go about creating a fake LDAP database? | 17:44 |
openstack | bug 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-keystone | 17:45 | |
*** aojea has quit IRC | 17:45 | |
ayoung | bkudryavtsev, you would not | 17:46 |
ayoung | bkudryavtsev, you can only create real ldap database. Fake ldap database don't exist. They are fake. | 17:47 |
ayoung | mordred, which is why I suggest, instead, that we build on top of the oauth abstractions, which calls them "consumers" instead. | 17:48 |
ayoung | and we will hide the fact that, ujnder the covers, they are all just entries in a user table. | 17:48 |
sjain | Hi, 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 comment | 17:51 |
mordred | ayoung: yes - totally agree on the just entries in the user table part ... | 17:51 |
sjain | can anyone please explain me what is the missing here | 17:51 |
ayoung | mordred, so help me push the RBAC in middleware vision and you get your API-Keys | 17:52 |
mordred | ayoung: are you suggesting we call the end-user manifestation a "consumer"? like POST /consumers ? | 17:52 |
knikolla | bkudryavtsev: see my wip patch here https://review.openstack.org/#/c/466406/ where i directly modify the directory in fakeldap | 17:52 |
mordred | or is the api-key word concern more from teh internal conceptual place? | 17:52 |
ayoung | mordred, I really don't care what we call it, so long as we use the existing mechanisms | 17:52 |
ayoung | we can call it API keys for all I care | 17:52 |
ayoung | I care about getting a unified delegation model | 17:53 |
ayoung | so that, when tomorrow they are some XACML abstraction we don't need to write something for that, too. | 17:53 |
mordred | ok. cool | 17:53 |
* knikolla lurks on the discussion | 17:53 | |
mordred | I believe I understand what your concerns are and at what level they sit - and it doesn't sound like there are any intractable concerns | 17:54 |
mordred | I'll be doing another rev ont he spec tomorrow - I'll try to wordsmith some of this in there a bit | 17:54 |
*** mvk_ has quit IRC | 17:54 | |
ayoung | mordred, 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 spec | 17:55 |
*** chlong has joined #openstack-keystone | 17:55 | |
ayoung | mordred, I really just want my damn spec merged | 17:58 |
ayoung | weigh in on that, and we can base your approach on it. https://review.openstack.org/#/c/452198/ | 17:59 |
ayoung | mordred, write your spec in terms of that one and you will have an avid supporter from me | 18:00 |
ayoung | mordred, and to be honest, without that one, I don;'t think we have a way to enforce what you want from API keys | 18:01 |
mordred | well - that's the basis for the second spec - not the first one. implementation details of rbac and limited access is explicitly not in this one | 18:01 |
mordred | but 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 things | 18:01 |
mordred | s/but yet/but yes/ | 18:01 |
ayoung | mordred, actually, all I really want from the first spec is a justification for the term API-Key | 18:02 |
mordred | :) | 18:02 |
mordred | I'll do my best | 18:02 |
ayoung | and perhaps an indication that it can be implemented useing new APIs but existing mechanisms. | 18:02 |
ayoung | add in the users vs consumers discussion as to why we want this term | 18:02 |
mordred | ayoung: 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 |
mordred | I believe its use commonly across REST API things is why people like it | 18:04 |
ayoung | mordred, awesome. Stick it in the "references section" of the spec. | 18:04 |
mordred | it's tough to argue more strongly for it since I'm proxy-arguing on their behalf in the first place | 18:04 |
mordred | kk | 18:04 |
*** r-daneel has joined #openstack-keystone | 18:09 | |
ayoung | mordred, 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 lost | 18:09 |
ayoung | those lessons learned. | 18:09 |
*** lucasxu has joined #openstack-keystone | 18:12 | |
*** stingaci has quit IRC | 18:17 | |
raildo | gagehugo, ping :) | 18:17 |
*** stingaci has joined #openstack-keystone | 18:18 | |
gagehugo | raildo pong | 18:18 |
raildo | gagehugo, hey sir, everything ok? | 18:18 |
raildo | gagehugo, Do you have some free time to talk about our plan for oslo.config? | 18:18 |
gagehugo | raildo I have an hour now if that works | 18:19 |
raildo | gagehugo, it will be just a few minutes :) | 18:20 |
gagehugo | sure | 18:20 |
raildo | gagehugo, 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 great | 18:21 |
gagehugo | raildo sure | 18:21 |
raildo | gagehugo, #latchset | 18:21 |
ayoung | raildo, bring them here | 18:21 |
ayoung | raildo, I know they all *get it*, less convinced that the Keystone folks do | 18:21 |
ayoung | and that is where we need to convince people. | 18:21 |
raildo | ayoung, I think will be easier to discuss this there, since is more related to oslo than keystone at this point | 18:21 |
raildo | ayoung, yeap, makes sense too | 18:21 |
ayoung | raildo, but Keystoners are the people in OpenStack that understand security. But I can check in there, if you would prefer | 18:22 |
mordred | ayoung: 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 |
raildo | ayoung, I'm ok with either way | 18:22 |
gagehugo | lamt #latchset | 18:23 |
ayoung | raildo, also, is #latchset logged yet? | 18:24 |
ayoung | Cuz this room is evesdropped | 18:24 |
raildo | ayoung, yeap | 18:24 |
ayoung | Excellent | 18:24 |
raildo | I just need to remember where, but I'll take a look on it | 18:24 |
*** catinth__ has quit IRC | 18:28 | |
*** catintheroof has joined #openstack-keystone | 18:30 | |
*** harlowja has joined #openstack-keystone | 18:37 | |
*** masuberu has quit IRC | 18:39 | |
*** dave-mccowan has quit IRC | 18:41 | |
*** lucasxu has quit IRC | 18:41 | |
*** lucasxu has joined #openstack-keystone | 18:43 | |
*** harlowja has quit IRC | 18:43 | |
*** lucasxu has quit IRC | 18:58 | |
*** lucasxu has joined #openstack-keystone | 19:03 | |
*** aojea has joined #openstack-keystone | 19:11 | |
*** nicolasbock has quit IRC | 19:13 | |
*** pnavarro has joined #openstack-keystone | 19:23 | |
*** stingaci has quit IRC | 19:44 | |
*** sjain has quit IRC | 19:48 | |
*** aojea has quit IRC | 19:56 | |
*** aojea has joined #openstack-keystone | 19:56 | |
*** aojea_ has joined #openstack-keystone | 20:00 | |
*** aojea has quit IRC | 20:01 | |
*** stingaci has joined #openstack-keystone | 20:04 | |
*** nicolasbock has joined #openstack-keystone | 20:06 | |
*** chlong has quit IRC | 20:07 | |
ayoung | stevemar, how do I bring something up before the technical committee? | 20:08 |
*** stingaci has quit IRC | 20:08 | |
openstackgerrit | Boris Kudryavtsev proposed openstack/keystone master: Add user_id_attribute support to _dn_to_id https://review.openstack.org/466389 | 20:11 |
morgan | ayoung: usually you send an email and ask the chair/someone on the TC to add it to the agenda | 20:12 |
morgan | email to -dev list... this may have changed since I last paid attention | 20:12 |
*** arunkant_ has quit IRC | 20:13 | |
*** stingaci has joined #openstack-keystone | 20:14 | |
*** stingaci has quit IRC | 20:14 | |
*** stingaci has joined #openstack-keystone | 20:14 | |
*** lbragstad has quit IRC | 20:26 | |
*** stingaci has quit IRC | 20:29 | |
*** chlong has joined #openstack-keystone | 20:31 | |
*** ducttape_ has quit IRC | 20:39 | |
*** ducttape_ has joined #openstack-keystone | 20:40 | |
*** chlong has quit IRC | 20:41 | |
*** thorst_afk has quit IRC | 20:58 | |
*** thorst_afk has joined #openstack-keystone | 20:59 | |
*** thorst_afk has quit IRC | 21:03 | |
*** dave-mccowan has joined #openstack-keystone | 21:05 | |
*** ducttape_ has quit IRC | 21:08 | |
*** ducttape_ has joined #openstack-keystone | 21:09 | |
*** spilla has quit IRC | 21:10 | |
*** davechen has quit IRC | 21:22 | |
*** catintheroof has quit IRC | 21:22 | |
*** davechen has joined #openstack-keystone | 21:23 | |
*** catintheroof has joined #openstack-keystone | 21:29 | |
*** stingaci has joined #openstack-keystone | 21:30 | |
*** stingaci has quit IRC | 21:35 | |
*** thorst_afk has joined #openstack-keystone | 21:36 | |
*** thorst_afk has quit IRC | 21:40 | |
openstackgerrit | Merged openstack/oslo.policy master: Check reStructuredText documents for common style issues. https://review.openstack.org/449410 | 21:55 |
*** lucasxu has quit IRC | 21:58 | |
*** ducttape_ has quit IRC | 22:12 | |
*** ducttape_ has joined #openstack-keystone | 22:12 | |
*** aojea_ has quit IRC | 22:14 | |
*** aojea has joined #openstack-keystone | 22:14 | |
*** aojea has quit IRC | 22:18 | |
*** adriant has joined #openstack-keystone | 22:19 | |
openstackgerrit | Tin Lam proposed openstack/keystonemiddleware master: Replace pycrypto with cryptography https://review.openstack.org/451941 | 22:25 |
*** jdennis has quit IRC | 22:41 | |
*** jdennis has joined #openstack-keystone | 22:45 | |
*** r-daneel has quit IRC | 22:47 | |
*** ducttape_ has quit IRC | 22:49 | |
*** ducttape_ has joined #openstack-keystone | 22:50 | |
*** ducttap__ has joined #openstack-keystone | 22:54 | |
*** ducttape_ has quit IRC | 22:54 | |
*** thorst_afk has joined #openstack-keystone | 23:00 | |
*** thorst_afk has quit IRC | 23:04 | |
*** thorst_afk has joined #openstack-keystone | 23:05 | |
*** lamt has quit IRC | 23:06 | |
*** ducttap__ has quit IRC | 23:08 | |
*** thorst_afk has quit IRC | 23:09 | |
*** piliman974 has quit IRC | 23:23 | |
*** piliman974 has joined #openstack-keystone | 23:24 | |
*** catintheroof has quit IRC | 23:40 | |
*** nicolasbock has quit IRC | 23:40 | |
openstackgerrit | Colleen Murphy proposed openstack/keystonemiddleware master: Test migration from pycrypto to cryptography https://review.openstack.org/466938 | 23:44 |
*** catintheroof has joined #openstack-keystone | 23:48 | |
*** catintheroof has quit IRC | 23:59 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!