Monday, 2016-12-05

*** masber has joined #openstack-keystone00:02
*** xiaoyang has joined #openstack-keystone00:12
*** masber has quit IRC00:22
openstackgerritJamie Lennox proposed openstack/keystoneauth: Don't issue deprecation warning when nesting adapters  https://review.openstack.org/40664700:29
*** hoangcx has joined #openstack-keystone00:55
openstackgerritJamie Lennox proposed openstack/keystonemiddleware: Pass ?allow_expired  https://review.openstack.org/38210001:01
jamielennoxhey all, i'm looking for some feedback on how we should enforce policy on ^01:04
*** akshilv has joined #openstack-keystone01:12
akshilvHi01:12
akshilvI'm new to openstack contributions. Can anyone help me with how to work on a minor bug so that I understand the whole process?01:13
*** zhangjl has joined #openstack-keystone01:21
*** liujiong has joined #openstack-keystone01:26
*** akshilv has quit IRC01:40
*** catintheroof has joined #openstack-keystone01:58
*** catintheroof has quit IRC02:06
*** nkinder has quit IRC02:23
*** annp has joined #openstack-keystone02:29
*** nkinder has joined #openstack-keystone02:39
*** shuquan_ has joined #openstack-keystone02:56
*** guoshan has joined #openstack-keystone02:57
*** udesale has joined #openstack-keystone03:30
*** adrian_otto has joined #openstack-keystone03:40
*** adrian_otto has quit IRC03:43
*** adrian_otto has joined #openstack-keystone03:45
*** code-R has quit IRC03:51
*** guoshan has quit IRC03:56
openstackgerritSteve Martinelli proposed openstack/keystone: api-ref update for roles assignments with names  https://review.openstack.org/40636604:06
*** adrian_otto has quit IRC04:11
*** udesale has quit IRC04:18
*** udesale has joined #openstack-keystone04:18
*** udesale_ has joined #openstack-keystone04:18
*** udesale_ has quit IRC04:18
*** udesale has quit IRC04:18
*** udesale has joined #openstack-keystone04:19
*** zhangjl1 has joined #openstack-keystone04:21
*** zhangjl has quit IRC04:22
*** code-R has joined #openstack-keystone04:40
*** code-R_ has joined #openstack-keystone04:41
*** code-R has quit IRC04:44
*** adrian_otto has joined #openstack-keystone04:50
*** guoshan has joined #openstack-keystone04:57
*** guoshan has quit IRC05:01
*** adrian_otto has quit IRC05:02
*** voelzmo has quit IRC05:04
*** adrian_otto has joined #openstack-keystone05:04
*** voelzmo has joined #openstack-keystone05:04
*** voelzmo has quit IRC05:09
*** adrian_otto has quit IRC05:12
*** adriant has quit IRC05:22
openstackgerritGage Hugo proposed openstack/keystone: WIP: remove LDAP write support  https://review.openstack.org/37448205:30
*** chrisplo has quit IRC05:37
*** GB21 has joined #openstack-keystone05:42
*** chrisplo has joined #openstack-keystone05:48
*** chrisplo has quit IRC05:52
*** mgagne has quit IRC05:53
*** mgagne has joined #openstack-keystone05:55
*** mgagne is now known as Guest5173705:55
*** narasimha_SV has joined #openstack-keystone05:57
*** guoshan has joined #openstack-keystone05:57
*** guoshan has quit IRC06:02
*** chrisplo has joined #openstack-keystone06:03
narasimha_SVhttp://paste.openstack.org/show/591383/ are these variables sufficient for LDAP backend for keystone06:06
narasimha_SVplease correct me if any other values or any wrong confs are kept in the above06:06
*** shuquan_ has quit IRC06:06
*** chrisplo has quit IRC06:08
*** shuquan has joined #openstack-keystone06:08
*** shuquan has quit IRC06:13
*** shuquan has joined #openstack-keystone06:15
*** adrian_otto has joined #openstack-keystone06:17
*** adrian_otto has quit IRC06:21
*** guoshan has joined #openstack-keystone06:33
*** udesale has quit IRC06:36
*** udesale has joined #openstack-keystone06:38
*** rcernin has quit IRC06:39
*** martinus- has joined #openstack-keystone06:46
*** zzzeek_ has joined #openstack-keystone06:47
*** tsufiev has quit IRC06:48
*** tsufiev_ has joined #openstack-keystone06:48
*** htruta` has joined #openstack-keystone06:48
*** mfisch has quit IRC06:49
*** dancn` has joined #openstack-keystone06:52
*** zzzeek has quit IRC06:52
*** chrome0_ has joined #openstack-keystone06:52
*** sileht_ has joined #openstack-keystone06:52
*** mfisch has joined #openstack-keystone06:53
*** dhellmann_ has joined #openstack-keystone06:53
*** mfisch has quit IRC06:53
*** mfisch has joined #openstack-keystone06:53
*** rha has quit IRC06:53
*** martinus__ has quit IRC06:53
*** chrome0 has quit IRC06:53
*** dancn has quit IRC06:53
*** htruta has quit IRC06:53
*** sileht has quit IRC06:53
*** dhellmann has quit IRC06:53
*** dhellmann_ is now known as dhellmann06:56
*** rha has joined #openstack-keystone06:56
*** sileht_ is now known as sileht06:58
*** Dinesh_Bhor has joined #openstack-keystone06:59
*** masber has joined #openstack-keystone07:02
*** shuquan has quit IRC07:06
*** code-R_ has quit IRC07:13
*** code-R has joined #openstack-keystone07:13
*** shuquan_ has joined #openstack-keystone07:14
*** mkoderer___ is now known as mkoderer__07:23
*** rcernin has joined #openstack-keystone07:28
*** rcernin has quit IRC07:29
*** voelzmo has joined #openstack-keystone07:29
*** voelzmo has quit IRC07:30
*** voelzmo has joined #openstack-keystone07:30
*** rcernin has joined #openstack-keystone07:32
*** faizy has joined #openstack-keystone07:48
*** mvk has quit IRC07:51
*** d0ugal has joined #openstack-keystone07:51
*** rcernin has quit IRC07:52
*** rcernin has joined #openstack-keystone07:59
*** rcernin has quit IRC08:01
*** aloga_ has joined #openstack-keystone08:01
*** openstackgerrit has quit IRC08:03
*** rcernin has joined #openstack-keystone08:03
*** chrisplo has joined #openstack-keystone08:04
*** chrisplo has quit IRC08:09
*** hoonetorg has quit IRC08:12
*** pnavarro has joined #openstack-keystone08:19
*** mvk has joined #openstack-keystone08:22
*** zzzeek_ has quit IRC08:25
*** hoonetorg has joined #openstack-keystone08:28
*** afazekas has quit IRC08:29
*** zzzeek has joined #openstack-keystone08:33
*** afazekas has joined #openstack-keystone08:34
*** hoonetorg has quit IRC08:36
*** jistr is now known as jistr|mtgs08:36
*** faizy_ has joined #openstack-keystone08:37
*** faizy has quit IRC08:37
*** openstackgerrit has joined #openstack-keystone08:39
openstackgerritJulia Varlamova proposed openstack/keystone: Change DevStack plugin to setup multi-Keystone  https://review.openstack.org/39947208:39
*** jamielennox is now known as jamielennox|away08:40
*** faizy has joined #openstack-keystone08:41
*** amoralej|off is now known as amoralej08:43
*** faizy_ has quit IRC08:44
*** hoonetorg has joined #openstack-keystone08:49
*** zzzeek has quit IRC09:00
*** zzzeek has joined #openstack-keystone09:00
*** magic has joined #openstack-keystone09:01
*** xiaoyang has quit IRC09:05
*** xiaoyang has joined #openstack-keystone09:05
*** magic has quit IRC09:06
*** annp_ has joined #openstack-keystone09:06
*** annp has quit IRC09:07
*** asettle has joined #openstack-keystone09:08
*** g2 is now known as g2away09:14
*** hoonetorg has quit IRC09:16
*** markd_ has quit IRC09:20
*** narasimha_SV has quit IRC09:29
*** chrisplo has joined #openstack-keystone10:05
*** chrisplo has quit IRC10:09
shuquan_hi guys, i see current devstack support10:17
shuquan_federate with testshib.org10:17
shuquan_anyone used it before?10:17
shuquan_https://review.openstack.org/#/c/393932/10:18
shuquan_Devstack plugin to federate with testshib.org10:18
shuquan_this one10:18
*** liujiong has quit IRC10:21
*** hoangcx has quit IRC10:26
*** guoshan has quit IRC10:27
*** annp_ has quit IRC10:32
*** mdavidson has joined #openstack-keystone10:39
*** zhangjl1 has quit IRC10:41
*** shuquan_ has quit IRC10:44
*** code-R_ has joined #openstack-keystone10:56
*** code-R has quit IRC11:00
*** tesseract has joined #openstack-keystone11:05
*** tesseract is now known as Guest1725911:05
*** daemontool has joined #openstack-keystone11:11
*** GB21 has quit IRC11:15
*** udesale has quit IRC11:15
*** GB21 has joined #openstack-keystone11:17
*** Guest17259 has quit IRC11:21
*** masber has quit IRC11:23
*** tesseract- has joined #openstack-keystone11:24
*** faizy_ has joined #openstack-keystone11:26
*** faizy has quit IRC11:30
*** code-R has joined #openstack-keystone11:31
*** code-R_ has quit IRC11:34
*** nicolasbock has joined #openstack-keystone11:40
*** Daviey has quit IRC11:43
*** Daviey has joined #openstack-keystone11:43
*** chrisplo has joined #openstack-keystone12:05
*** GB21 has quit IRC12:07
*** code-R has quit IRC12:07
*** code-R has joined #openstack-keystone12:09
*** chrisplo has quit IRC12:10
*** code-R_ has joined #openstack-keystone12:14
*** code-R has quit IRC12:14
*** raildo has joined #openstack-keystone12:23
*** pnavarro has quit IRC12:25
*** faizy_ has quit IRC12:30
*** pnavarro has joined #openstack-keystone12:36
*** code-R has joined #openstack-keystone12:36
*** code-R_ has quit IRC12:39
*** pnavarro has quit IRC12:41
*** edmondsw has joined #openstack-keystone13:11
*** nishaYadav has joined #openstack-keystone13:20
nishaYadavhey all!13:21
stevemaro/13:22
*** amoralej is now known as amoralej|lunch13:26
*** tesseract- has quit IRC13:27
nishaYadavhi stevemar :D13:30
stevemarnishaYadav: hiya ;)13:30
*** narasimha_SV has joined #openstack-keystone13:33
narasimha_SVhttp://paste.openstack.org/show/591383/ are these configurations proper to have backend LDAP ?13:34
*** clenimar has joined #openstack-keystone13:35
*** catintheroof has joined #openstack-keystone13:38
*** dave-mccowan has joined #openstack-keystone13:41
*** pnavarro has joined #openstack-keystone13:41
*** shuquan has joined #openstack-keystone13:41
*** shuquan has quit IRC13:46
*** ayoung has quit IRC13:53
*** lamt has joined #openstack-keystone14:01
*** catinthe_ has joined #openstack-keystone14:02
*** catintheroof has quit IRC14:04
*** amoralej|lunch is now known as amoralej14:04
*** shuquan has joined #openstack-keystone14:04
*** chrisplo has joined #openstack-keystone14:06
*** chrisplo has quit IRC14:10
*** code-R has quit IRC14:12
dstaneko/14:26
*** nishaYadav_ has joined #openstack-keystone14:26
stevemaro\14:26
openstackgerritArthur Miranda proposed openstack/python-keystoneclient: Prevent attempts to "filter" find() calls by globally unique IDs  https://review.openstack.org/37573014:26
*** spzala has joined #openstack-keystone14:27
openstackgerritSamuel Pilla proposed openstack/keystone: api-ref update for roles assignments with names  https://review.openstack.org/40636614:27
openstackgerritSamuel Pilla proposed openstack/keystone: api-ref update for roles assignments with names  https://review.openstack.org/40636614:28
*** nishaYadav has quit IRC14:29
*** narasimha_SV has quit IRC14:30
*** udesale has joined #openstack-keystone14:38
*** code-R has joined #openstack-keystone14:38
*** code-R_ has joined #openstack-keystone14:40
*** code-R has quit IRC14:43
*** aloga_ has quit IRC14:43
*** lamt has quit IRC14:46
*** g2away is now known as g214:46
*** edtubill has joined #openstack-keystone15:02
*** daemontool has quit IRC15:08
*** ayoung has joined #openstack-keystone15:12
*** ChanServ sets mode: +v ayoung15:12
*** GB21 has joined #openstack-keystone15:14
*** shuquan has quit IRC15:15
*** nishaYadav_ has quit IRC15:21
*** nishaYadav_ has joined #openstack-keystone15:25
*** chris_hultin|AWA is now known as chris_hultin15:34
*** chrisplo has joined #openstack-keystone15:37
openstackgerritLance Bragstad proposed openstack/keystone-specs: Expose password requirements through API  https://review.openstack.org/40703615:38
*** ravelar has joined #openstack-keystone15:38
lbragstadrderose ^15:38
stevemarlbragstad: nice15:39
*** adrian_otto has joined #openstack-keystone15:40
rderoselbragstad: cool15:41
lbragstadi wanted to get that proposed last week but i ran out of time.15:41
*** chrisplo has quit IRC15:41
lbragstadi'd like to get it reviewed before the keystone/horizon meeting this week15:42
lbragstadso - any reviews would be awesome :)15:42
*** phalmos has joined #openstack-keystone15:44
stevemarlbragstad: reviewed15:46
dstaneklbragstad: that's a good idea for all our schemas15:51
lbragstaddstanek what's that?15:52
robcresswelllbragstad: Looks like a nice change from a Horizon view. Anything that lets us cut down on config is great.15:54
robcresswellprobably 3/4 of our config is just duplicated service config :(15:54
lbragstadrobcresswell yeah - that feels like a pain to manage15:54
*** briancline has quit IRC15:55
dstaneklbragstad: it would be nice to publish our schemas15:56
lbragstadah - i see what you mean15:58
*** voelzmo has quit IRC16:01
*** GB21 has quit IRC16:01
*** spligak has quit IRC16:04
*** rcernin has quit IRC16:05
*** ayoung has quit IRC16:06
*** ayoung has joined #openstack-keystone16:07
*** ChanServ sets mode: +v ayoung16:07
*** GB21 has joined #openstack-keystone16:10
*** catintheroof has joined #openstack-keystone16:13
*** catinthe_ has quit IRC16:16
*** arunkant has quit IRC16:19
*** jaugustine has joined #openstack-keystone16:27
*** nishaYadav_ has quit IRC16:30
*** oomichi has quit IRC16:31
*** faizy_ has joined #openstack-keystone16:32
*** nishaYadav_ has joined #openstack-keystone16:33
*** nishaYadav_ has quit IRC16:34
*** faizy__ has joined #openstack-keystone16:34
*** agrebennikov has joined #openstack-keystone16:35
*** alex_xu has quit IRC16:35
openstackgerritLance Bragstad proposed openstack/keystone-specs: Expose password requirements through API  https://review.openstack.org/40703616:35
openstackgerritRichard Avelar proposed openstack/keystone: Add unit tests for doctor's database symptoms  https://review.openstack.org/40706216:35
*** erhudy has joined #openstack-keystone16:36
*** faizy_ has quit IRC16:36
*** mvk has quit IRC16:37
*** lamt has joined #openstack-keystone16:38
*** code-R_ has quit IRC16:41
*** code-R has joined #openstack-keystone16:41
*** antwash_ has joined #openstack-keystone16:43
*** antwash_ has quit IRC16:43
*** antwash_ has joined #openstack-keystone16:43
openstackgerritLance Bragstad proposed openstack/keystone-specs: Expose password requirements through API  https://review.openstack.org/40703616:44
*** antwash_ has quit IRC16:46
*** antwash_ has joined #openstack-keystone16:47
*** antwash_ has quit IRC16:48
*** antwash_ has joined #openstack-keystone16:48
*** antwash_ has quit IRC16:49
*** adrian_otto has quit IRC16:52
lbragstadstevemar rderose dstanek hmm - i like the domain configuration route, because it would probably save us some work.. but i think it would require some dangerous policy changes16:58
lbragstadwe currently suggest that only admins can interact with the domain config via the API16:59
*** adrian_otto has joined #openstack-keystone16:59
lbragstadwhich would have to change so that horizon can use non-admin tokens to get password requirements for non-admin users.16:59
lbragstadi'm documenting this in another iteration of the spec17:00
rderoselbragstad: hmm... and security compliance is global; not domain specific17:01
lbragstadrderose well - right now it is17:01
rderose:)17:01
rderosetrue17:01
lbragstadrderose but that could change in the future, right?17:01
rderoseyes17:01
*** antwash_ has joined #openstack-keystone17:02
*** catinthe_ has joined #openstack-keystone17:02
lbragstadso - the security concern is loosening the policy around retrieving domain configuration17:03
lbragstadthen non-admin users would be able to look at other options for their specific domain17:03
*** catintheroof has quit IRC17:04
lbragstad(i.e. things in the [ldap] or [identity] sections)17:04
lbragstadat the same time, the [security_compliance] section and the [ldap] sections seem mutually exclusive for a domain17:04
*** browne has joined #openstack-keystone17:05
*** d0ugal has quit IRC17:07
*** antwash_ has quit IRC17:07
*** udesale has quit IRC17:08
*** tqtran has joined #openstack-keystone17:09
*** asettle has quit IRC17:09
*** iurygregory has joined #openstack-keystone17:11
openstackgerritLance Bragstad proposed openstack/keystone-specs: Expose password requirements through API  https://review.openstack.org/40703617:20
*** chrisplo has joined #openstack-keystone17:21
*** adrian_otto1 has joined #openstack-keystone17:26
*** mvk has joined #openstack-keystone17:26
*** Guest51737 is now known as mgagne17:26
*** mgagne has quit IRC17:27
*** mgagne has joined #openstack-keystone17:27
morganmorning.17:28
*** adrian_otto has quit IRC17:28
*** gyee has joined #openstack-keystone17:30
*** oomichi has joined #openstack-keystone17:30
*** GB21 has quit IRC17:42
*** code-R has quit IRC17:42
*** code-R has joined #openstack-keystone17:43
*** richm has joined #openstack-keystone17:44
*** shuquan has joined #openstack-keystone17:47
*** harlowja has joined #openstack-keystone17:50
samueldmqmorgan: morning17:50
samueldmqcrinkle: hey, are you around ?17:50
samueldmqcrinkle: what does it take to make https://review.openstack.org/#/c/390948 work with anonymous binds ?17:51
*** shuquan has quit IRC17:52
*** faizy_ has joined #openstack-keystone17:58
*** faizy__ has quit IRC18:01
crinklesamueldmq: just conn.simple_bind_s() with no arguments I think18:01
crinklei don't have that env up right this moment18:02
samueldmqcrinkle: and how do we check if anonymous binds are supported ? is there a config option for it18:02
samueldmqcrinkle: or we should just try and see?18:02
*** spligak has joined #openstack-keystone18:03
crinklesamueldmq: I think if user and password aren't set that implies the operator intends to bind anonymously18:04
samueldmqcrinkle: and allowing it or not depends on their LDAP server, right?18:04
crinklesamueldmq: yes I believe so18:05
*** adrian_otto1 has quit IRC18:06
*** adrian_otto has joined #openstack-keystone18:07
samueldmqcrinkle: kk. it would make sense for me to open another bug and say : keystone should attemp an anonymous LDAP bind if no credentials are provided18:07
samueldmqcrinkle: it does not do that today, and that patch fixes "Set network connection timeout on Keystone Identity's LDAP backend to prevent stall on bind"18:07
samueldmqwhich can be related, but seems to be a separate thing18:07
samueldmqcrinkle: not sure you agree and/or are okay with that18:08
crinklesamueldmq: okay, that is fine with me18:08
samueldmqcrinkle: cool, do you want to submit the followup yourself ?18:09
samueldmqcrinkle: it'd be fine to test it locally when you have that env up again, if possible18:09
crinklesamueldmq: sure I can submit it18:09
samueldmqcrinkle: awesome, thanks!18:10
samueldmqrderose: hi18:19
rderosesamueldmq: hi18:20
samueldmqrderose: hye, hope you're doing great18:20
samueldmqrderose: is there any consensus on "Federated attributes for users" vs  "enhancing the mapping engine" ?18:20
rderosesamueldmq: I don't know about versus, but we discussed in the last keystone meeting and there was support for this spec18:21
samueldmqrderose: they are different solution to the same problem, right ?18:22
rderosesamueldmq: partly... extending the API, allows operators to query federated users in other to get their local user ID18:23
samueldmqrderose: and then assign roles, etc18:23
ayoungagrebennikov, so...I know I owe you an explanation18:23
rderosesamueldmq: that part, yes18:23
rderosesamueldmq: or delegation18:23
ayoungjust adding the project BY ID as you requested is actually neither necesaary nor sufficient18:23
samueldmqrderose: it's also possible to create a user and know its ID even before it first connects18:24
samueldmqrderose: so it's possible to do that setup, which is why I understand it as covering what 'enhanced engine' proposes18:24
rderosesamueldmq: currently no, you would need to create the user to get the user ID18:25
rderosesamueldmq: I like the idea of giving operators the flexibility to provision in mass by utilizing shadow mapping or by utilizing the API18:25
rderosesamueldmq: extending the user API also allows for de-provisioning18:26
samueldmqrderose: which is not covered with improving the engine (which is only provisioning)18:27
rderosesamueldmq: correct18:27
ayoungagrebennikov, understand what I mean?  You need the role assignments, too18:28
samueldmqrderose: so, operators  have 2 options to provision resources to their federation users (create users with the extended user api OR use the extended map engine)18:28
ayoungand the roles18:28
samueldmqrderose: and to de-provision use the extended user api, filter on whatever federation fields you want, and clean it up18:28
ayoungand if those are not the same on both systems...well...who really cares.18:29
rderosesamueldmq: yes, and there may be different use cases as to why you would want one over the other18:29
samueldmqrderose: agreed18:29
rderosesamueldmq: yes18:29
ayoungIts only an issue if people are trying to do things by ID, but then the Keystone server AUth URL is different...so everything is different18:29
*** faizy_ has quit IRC18:30
ayoungagrebennikov,  you will not want to honor the tokens issued by one Keystone server in another server where the IDs are different18:30
samueldmqrderose: I wonder if, in the future, it would be nice to know what projects were created to serve only federated users (with the extended mapping engine)18:30
samueldmqrderose: so that it is easier to make de-provisioning happen on that too18:30
ayoungsamueldmq, there is no such thing18:30
ayounga project can serve any user, from any domain18:30
ayoungfederated or not18:31
samueldmqayoung: yeah, I don't want ot overcomplicate things18:31
samueldmqnvm18:31
rderosesamueldmq: the projects would be under the IdP's domain, so you could find them that way18:31
ayoungyou could query active role assignments when you decomission, but there are deamons there18:31
ayoungrderose, no18:31
rderose:)18:31
ayoungrderose, we don't have a direct correspondance between IdP and domain, should not thinkg of things that way18:32
ayoungwe have double-booked the term domain18:32
ayoungif we were smart back when we did this, we would have a different term for the top level of projects versus the top level ofidentiy18:32
ayoungbut the split had not happened yet18:32
ayoungextended Map engine sounds like the right tool for the main set of uses18:33
ayoungthe goal should be to make it so IdP managers can set up and amanage their own mappings18:33
ayoungand in order to do that we need restrictions18:33
rderoseayoung: hmm... ah, right18:33
ayoungrderose, which is where I suspect you were headed18:34
ayounglets say we have domain DF1  (for federation) and IdP I118:34
ayoungwe make a link, outside of mapping, that says the mapping for I1 can only map to DF118:34
ayoungthen the IdP admin can set up whatever they want18:34
ayoungbu their users only ever go into DF118:35
ayoungmight need to make it slightly more complex for groups:18:35
ayoungthey can map users into DF1 and into groups in DF1 plus Default or something18:35
rderoseayoung: right and they could have access to projects outside of DF118:35
ayounggroups can be in a separate domain from the users they contain, and figuring out the mapping restrictions will let us scale the Human side18:35
ayoungBut if We start by saying IdP to domain access is a distinct entity, outside (and preceding) the Federations mapping table we can then let IdP admins do their job18:36
*** amoralej is now known as amoralej|off18:37
ayoungAnd...to do that, it probably makes sense to say that a domain owns an IdP18:37
ayoungWe can default the existing ones to the Admin domain18:37
rderoseayoung: why not create a new domain for the IdP?18:38
rderoseinstead of default to Admin18:39
ayoungrderose, we cn do that for the future, but we need backwards compat, too18:39
ayoungwho owns it, and who they can map to are possibly two different things18:39
ayoungbut maybe no18:39
ayoungI think not...18:40
ayoungOK,  lets say that each IdP is owned by a domain18:40
ayoungwe createa new role "idp_admin"  that lets a user create and define the Idp, mapping, (and protocols ?)  for that domain18:41
samueldmqrderose: I've +2ed, the concept looks solid and the spec is clear18:41
rderosesamueldmq: ++18:41
samueldmqrderose: impl details coming in implementation patches18:41
ayoungI think not on the protocols today, but that is due to how we implement (in HTTPD)18:41
ayoungBut the mapping certainly18:41
*** code-R has quit IRC18:42
*** code-R has joined #openstack-keystone18:43
*** narasimha_SV has joined #openstack-keystone18:43
narasimha_SVI am trying to integrate keystone to use LDAP as backend18:43
narasimha_SVhttp://paste.openstack.org/show/591463/18:43
narasimha_SVthis is the error I am getting18:43
narasimha_SVhttp://paste.openstack.org/show/591383/18:43
narasimha_SVthese are my LDAP confs in keysonte.conf18:44
rderoseayoung: interesting, I was only thinking that IdP -> Domain relationship would just mean that the users and groups belonged to that domain18:44
rderoseayoung: currently, only admins can register new IdPs I imagine18:44
ayoungrderose, that is all true18:44
ayoungbut the mapping is the part that is hard to get right18:45
ayoungif the protocol cold be done all inside Keystone, it would be possible to let an admin create the IdP, and then give the rest of the control to the idp_admin, but the HTTPD config is pretty much web server, multisite configruation changes18:46
ayoungwe don't want non-admins messing with that18:46
rderoseayoung: true, but...  if you extend the API, it's not hard. admins create the IdP and domain_admins manage the rest18:47
ayoungand, we don't want to pull it into Keystone (despite what dstanek thinks) because it is heavy lifting crypto that is probably not right to do in python18:47
dstaneknarasimha_SV: are you actually using example.com domains or did you sanitize that?18:47
rderoseayoung: (probably not that easy :) )18:48
narasimha_SV+dstanek: i created a local LDAP server in my environment to work with18:48
ayoungrderose, not code that we are quialified to maintain...SAML itself is a nasty beast, and add in the other forms of Federation, it is yuck...18:48
dstaneknarasimha_SV: are all those dn settings correct? have you been able to query from the command line?18:48
narasimha_SVyes i am able to query from command line18:49
rderoseayoung: good point18:49
dstaneknarasimha_SV: can you increase the logging so you can see the exact query being performed?18:50
rderoseayoung: what do you mean by the protocol being done inside of keystone?18:50
stevemarravelar: o/18:50
rderoseayoung: you mean all of the configuration stuff?18:50
ayoungrderose, when you create an IdP and a protocol, you create new suburls under OS-FEDERATION, but those need to be configurated per protocol in the APache server18:50
narasimha_SVldapsearch -x -h localhost -p 1389 -b dc=example,dc=com "(uid=admin)" mail18:50
ravelarstevemar: o/18:50
ayoungdstanek, is working on making SAML work 100% inside Keystone18:50
agrebennikovayoung, I see your point. But there is other side of this. It's up to the administrator how to use it. I don't understand why anybody want to Block it if it is just the functionality extension. Does it Break anything? Does it have any security issue?18:51
ayoungI'm not certain it is the right approach18:51
stevemarravelar: do you have any questions about my comments on the duplicate entry patch?18:51
ayoungagrebennikov, it is a support nightmare18:51
narasimha_SVthis is the command fow which i am getting output18:51
agrebennikovwhat exactly?18:51
agrebennikovthe option?18:51
ayoungagrebennikov, you are looking to do multisite sync at the API level.  Lets define it that way and see what we need to do to make it happen18:51
ravelarstevemar: no it was clear, thanks for the feedback :) I made the changes and am just working on unit tests for all objects18:52
agrebennikovayoung, exactly18:52
agrebennikovmoreover18:52
ayoungagrebennikov, a token issues by one Keystone server will have garbage in it according to a non-synced keystone server if we go the way you are proposing18:52
*** asettle has joined #openstack-keystone18:53
agrebennikovas I was always saying - my very first usecase was to allow syncing up groups in LDAP with keystone, since there is no other way to do it for now18:53
ayoungit breaks trusts and the single-role tokens I was proposing18:53
openstackgerritKen'ichi Ohmichi proposed openstack/keystone: Remove CONF.os_inherit.enabled  https://review.openstack.org/40567918:53
ayoungagrebennikov, there is a way.  You do it at the MySQL level.  The rest of the world has come to peace with this.18:53
agrebennikovayoung, examples?18:54
*** d0ugal has joined #openstack-keystone18:54
ayoungOr you Do full blown Keystone to Keystone federation18:54
*** openstackstatus has joined #openstack-keystone18:54
*** ChanServ sets mode: +v openstackstatus18:54
ayoungexamples on Gallera multi-site?18:54
agrebennikovwhich is 15 times slower than just issuing the tokens?18:54
ayoungagrebennikov, So what18:55
ayoungagrebennikov, that should be a one time cost when a user goes to a different region18:55
ayoungbut...I am not here to solve your problem18:55
ayounguse the Database layer.  Was not my call to set things up this way, but I've had to live with it18:56
stevemarrodrigods: Ken'ichi  should be ready to merge18:56
ayoungwe can't start breaking the internal referntial integrity assumptions of Keyston18:56
dstanekayoung: i thought you were assigned to solve all the problems :-)18:56
ayoungstevemar, who can we get that can help agrebennikov with the multisite Gallera stuff?  It is beyond me18:56
ayoungdstanek, I am solveing the strategeric problems, making Keystone actually do what everything thinks it is doing  but don't realize how broken it is18:57
agrebennikovwait please. I'm not asking to solve technical stuff. I'm bringing the usecases and the solution for them18:57
agrebennikovthat's it18:57
ayoungagrebennikov, your use case is multi-site sync18:57
ayoungright?18:58
stevemarravelar: thanks for working on it18:58
agrebennikovas well as I'm even bginging customers18:58
ayoungWe can't do multisite at the API level18:58
*** code-R has quit IRC18:58
ayoungI understand that you liked LDAP as it works well with "Eventual consistency"18:58
*** code-R has joined #openstack-keystone18:59
ayoungBUt Gallera can do that as well, and that is the tool that we have18:59
dstanek...or a custom driver? right? either way it's a data layer problem18:59
ayoungdstanek, I had proposed a notifications layer tool, but there are too many data consistency problems there19:02
ayoungwhat if you miss a notification because Keystone is down19:02
ayoungdstanek, this is what Gallera is supposed to do19:03
dstanekonce there is a way to create projects for a federated user then federation would be a great solution19:05
bretonmy comment still stands. With the change there some tokens will be verifiable in 2 regions and some on only 119:05
agrebennikovayoung, instead of allowing me to write 3-lines script for making it consistent you suggested me to create half-keyston-server stuff on top of private vpn connection between mamagement networks of the DCs.19:06
ayoungagrebennikov, it will not be a 3 line script19:06
agrebennikovbreton, it is still Up To Admin how to maintain it. Nobody removes the role of the admin and his/her communication with the users19:06
ayoungagrebennikov, you are breaking so many assumptions of how Keystone is defined.19:07
agrebennikovdo I?19:07
ayoungNo way to confirm consistency19:07
ayoungyes, yes you are.19:07
agrebennikovbut then how you allowd it to work for 5 years while the project could be stored in ldap?19:08
agrebennikovwhen IDs Were coming from ldap as well19:08
ayoungbreton, I wonder, though, if this is an issue with Fernet tokens in general19:08
ayoungdo we really need the Keystone servers to be able to confirm the keys they use with each other?19:08
ayoungI mean, you could make the same nightmare scenario now19:08
ayoung2 keysones, distinct databases, share a key, and now...kablooey19:09
agrebennikovthat's again up to the admin. If you use same keys actoss global cloud - you are all set19:09
bretonayoung: that would be a complete kablooey19:09
bretonayoung: nothing will work19:09
ayoungsharing 1/2 the data makes it only kablooey sometimes, fun to debug19:09
bretonayoung: because all ids are different19:09
ayoungbreton, so agrebennikov wants to introduce a case where the IDs are the same 80% of the time...how often will that fail?>19:10
ayoungagrebennikov, if the role assignements are different, it all breaks19:10
bretonayoung: 20%? :)19:10
ayoungYou need the Ids to be identical19:10
ayoungand that is for roles, role assignments, users, groups, and projects19:11
ayoungYou need to be able to sync *everything* by ID or it will break19:11
ayoungnot just projects19:11
bretonayoung: will there be a test making sure that it's only 20% so that when we add some new cool auth method it doesn't become 21%? :)19:11
ayoungbreton, 20 == 21 for very large values of 2019:11
agrebennikovplease tell me guys why the hell you alow Roles to be the same?19:12
agrebennikovaccording to keystone concept Everything should be unoque19:12
ayoungagrebennikov, that story requires alcohol19:12
agrebennikovsame with user IDs19:12
agrebennikovplease, come19:12
agrebennikovliquor store is right next to my house, same as bbq19:13
ayoungagrebennikov, I feel your pain.  But what you are asking for is a keystone to keystone sync at the API level.  Not a trivial thing to implement19:13
agrebennikovayoung, I'm completely pissed off telling the truth.... I'm Not asking You to implement the sync19:14
*** adrian_otto has quit IRC19:14
agrebennikovas an administrator >"I"< will do it19:14
ayoungagrebennikov, yes, but without it, what you proposed will break19:14
agrebennikovjust let me do it19:14
ayoungNo.19:14
ayoungagrebennikov, you are asking Me to support it19:15
agrebennikovnope19:15
agrebennikovI'll support my schema19:15
agrebennikovyou only support an option19:15
ayoungyou are asking Me, and the rest of the team, to build this mechanism into the supported version of Keystone that gets shipped to everython19:15
ayoungand it breaks a lot of stuff19:15
agrebennikovwhy same user's ID doesn't break stuff? Why same Domain IDs don't break stuff????? only projects for some reason19:16
ayoungagrebennikov, tell you waht...I am going to assign that question to you for Homework19:16
bretondomain ids break stuff.19:16
ayoungI don't havethe time to walk you through it, but it has to do with the token validation  repopulating the data for the role assignment.19:16
ayoungand now I need to shift gears19:17
*** ayoung is now known as ayoung-afk19:17
agrebennikovI already did that19:17
agrebennikovI actually Started with it19:17
*** pnavarro has quit IRC19:17
*** asettle__ has joined #openstack-keystone19:18
*** adrian_otto has joined #openstack-keystone19:19
*** faizy has joined #openstack-keystone19:22
*** baffle_ has joined #openstack-keystone19:23
*** adrian_otto has quit IRC19:24
*** diazjf has joined #openstack-keystone19:25
*** odyssey4me_ has joined #openstack-keystone19:26
*** bapalm_ has joined #openstack-keystone19:26
*** gagehugo_ has joined #openstack-keystone19:27
*** voelzmo has joined #openstack-keystone19:27
*** voelzmo has quit IRC19:27
*** voelzmo has joined #openstack-keystone19:27
*** gagehugo has quit IRC19:28
*** asettle has quit IRC19:28
*** mvk has quit IRC19:28
*** agrebennikov has quit IRC19:28
*** clenimar has quit IRC19:28
*** rm_work has quit IRC19:28
*** bapalm has quit IRC19:28
*** jefrite has quit IRC19:28
*** odyssey4me has quit IRC19:28
*** baffle has quit IRC19:28
*** asettle__ is now known as asettle19:28
*** jefrite has joined #openstack-keystone19:30
*** rm_work has joined #openstack-keystone19:30
*** rm_work has quit IRC19:30
*** rm_work has joined #openstack-keystone19:30
*** gagehugo_ has quit IRC19:34
*** mvk has joined #openstack-keystone19:34
*** faizy has quit IRC19:34
*** clenimar has joined #openstack-keystone19:34
*** adrian_otto has joined #openstack-keystone19:35
*** gagehugo has joined #openstack-keystone19:35
*** agrebennikov has joined #openstack-keystone19:37
*** voelzmo has quit IRC19:43
*** code-R has quit IRC19:48
*** adrian_otto has quit IRC19:50
*** woodster_ has joined #openstack-keystone19:51
*** cbits has joined #openstack-keystone19:51
*** nkinder has quit IRC19:53
*** adrian_otto has joined #openstack-keystone19:54
*** voelzmo has joined #openstack-keystone20:01
*** arunkant has joined #openstack-keystone20:01
*** nkinder has joined #openstack-keystone20:06
*** gus has quit IRC20:08
*** gus has joined #openstack-keystone20:10
*** voelzmo has quit IRC20:13
openstackgerritRichard Avelar proposed openstack/keystone: Add unit tests for doctor federation file  https://review.openstack.org/40718820:16
*** shuquan_ has joined #openstack-keystone20:25
*** diazjf has quit IRC20:25
*** adrian_otto has quit IRC20:29
*** adrian_otto has joined #openstack-keystone20:29
*** shuquan_ has quit IRC20:29
*** pnavarro has joined #openstack-keystone20:31
*** d0ugal has quit IRC20:32
*** edtubill has quit IRC20:34
*** adrian_otto has quit IRC20:39
*** adrian_otto has joined #openstack-keystone20:39
*** edmondsw has quit IRC20:41
*** asettle has quit IRC20:41
*** diazjf has joined #openstack-keystone20:45
*** edmondsw has joined #openstack-keystone20:47
*** edmondsw has quit IRC20:52
*** catinthe_ has quit IRC20:53
*** adrian_otto has quit IRC20:53
*** edmondsw has joined #openstack-keystone20:53
*** edmondsw has quit IRC20:58
*** Ephur has joined #openstack-keystone20:58
*** lamt has quit IRC21:03
*** voelzmo has joined #openstack-keystone21:05
*** voelzmo has quit IRC21:06
*** voelzmo has joined #openstack-keystone21:07
*** voelzmo_ has joined #openstack-keystone21:10
*** voelzmo has quit IRC21:10
*** jamielennox|away is now known as jamielennox21:13
*** spzala has quit IRC21:14
*** voelzmo_ has quit IRC21:18
*** edmondsw has joined #openstack-keystone21:25
*** Marcellin__ has joined #openstack-keystone21:25
openstackgerritRichard Avelar proposed openstack/keystone: Rename doctor symptom in security_compliance  https://review.openstack.org/40720621:26
*** edtubill has joined #openstack-keystone21:28
*** edmondsw has quit IRC21:29
openstackgerritRichard Avelar proposed openstack/keystone: Add unit tests for doctor federation file  https://review.openstack.org/40718821:34
*** edmondsw has joined #openstack-keystone21:34
*** gyee has quit IRC21:37
openstackgerritRichard Avelar proposed openstack/keystone: Add unit tests for doctor's database symptoms  https://review.openstack.org/40706221:38
*** catintheroof has joined #openstack-keystone21:39
*** edtubill has quit IRC21:39
*** adriant has joined #openstack-keystone21:41
ayoung-afkkeystone-manage db_version lies21:46
ayoung-afkversion 66 is not "blank database with not tables in it"21:46
*** lamt has joined #openstack-keystone21:50
*** gyee has joined #openstack-keystone21:50
*** diazjf has quit IRC22:00
*** ayoung-afk has quit IRC22:00
*** adrian_otto has joined #openstack-keystone22:02
openstackgerritRichard Avelar proposed openstack/keystone: Print name with duplicate error on user creation  https://review.openstack.org/40510422:04
*** jaugustine has quit IRC22:08
openstackgerritRodrigo Duarte proposed openstack/python-keystoneclient: WIP: Do not skip test_acess  https://review.openstack.org/40722122:08
*** ravelar has quit IRC22:10
openstackgerritJamie Lennox proposed openstack/keystoneauth: Don't issue deprecation warning when nesting adapters  https://review.openstack.org/40664722:14
*** diazjf has joined #openstack-keystone22:18
*** diazjf has quit IRC22:21
*** pnavarro has quit IRC22:23
*** phalmos has quit IRC22:25
*** ravelar has joined #openstack-keystone22:29
*** chris_hultin is now known as chris_hultin|AWA22:31
openstackgerritRichard Avelar proposed openstack/keystone: Rename doctor symptom in security_compliance  https://review.openstack.org/40720622:33
*** masber has joined #openstack-keystone22:37
*** rcernin has joined #openstack-keystone22:40
openstackgerritRon De Rose proposed openstack/keystone: WIP - Require domain_id when registering Identity Providers  https://review.openstack.org/39968422:45
openstackgerritRon De Rose proposed openstack/keystone: Update docs to require domain_id when registering Identity Providers  https://review.openstack.org/39915722:46
openstackgerritRon De Rose proposed openstack/keystone: Update docs to require domain_id when registering Identity Providers  https://review.openstack.org/39915722:46
openstackgerritRon De Rose proposed openstack/keystone: WIP - Require domain_id when registering Identity Providers  https://review.openstack.org/39968422:52
openstackgerritRon De Rose proposed openstack/keystone: Update docs to require domain_id when registering Identity Providers  https://review.openstack.org/39915722:56
openstackgerritRon De Rose proposed openstack/keystone: WIP - Require domain_id when registering Identity Providers  https://review.openstack.org/39968422:59
openstackgerritRon De Rose proposed openstack/keystone: Update docs to require domain_id when registering Identity Providers  https://review.openstack.org/39915723:00
*** adrian_otto has quit IRC23:03
*** cbits has quit IRC23:03
jamielennoxstevemar, dolphm, lbragstad, others: i'd like some opinions on how we transition to a service token policy on https://review.openstack.org/#/c/382100/23:10
lbragstadjamielennox sure thing - i'll add it to the queue23:10
jamielennoxa) do we go full on oslo.policy or just say the service token must have these roles as a list23:10
jamielennoxb) how do we turn on a sensible default in a backwards compat way23:10
*** diazjf has joined #openstack-keystone23:14
*** spzala has joined #openstack-keystone23:15
*** ravelar has quit IRC23:19
*** ayoung-afk has joined #openstack-keystone23:19
*** spzala has quit IRC23:20
*** diazjf has quit IRC23:20
openstackgerritBrant Knudson proposed openstack/keystone: Correct minor issues in test schema  https://review.openstack.org/40723423:24
*** masber has quit IRC23:33
*** cbits has joined #openstack-keystone23:34
*** cbits has quit IRC23:44
*** lamt has quit IRC23:44
*** spzala has joined #openstack-keystone23:47

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