Thursday, 2016-12-15

*** ngupta has quit IRC00:02
*** ngupta has joined #openstack-keystone00:03
*** ngupta has quit IRC00:07
*** asettle has joined #openstack-keystone00:08
*** asettle has quit IRC00:08
*** stingaci_ has quit IRC00:08
*** asettle has joined #openstack-keystone00:08
*** asettle has quit IRC00:09
openstackgerritRon De Rose proposed openstack/keystone: PCI-DSS Force users to immediately change their password upon first use  https://review.openstack.org/40391600:10
*** asettle has joined #openstack-keystone00:19
*** asettle has quit IRC00:23
*** lamt has quit IRC00:35
stevemarjamielennox: py35 error is legit00:51
jamielennoxdamin00:51
*** stingaci has joined #openstack-keystone00:55
openstackgerritJamie Lennox proposed openstack/keystonemiddleware: Pass ?allow_expired  https://review.openstack.org/38210000:55
jamielennoxi didn't even know log.warn was being deprecated, doesn't seem fair00:56
*** jamielennox is now known as jamielennox|away00:58
*** tqtran has quit IRC00:58
*** Marcellin__ has quit IRC00:59
*** jamielennox|away is now known as jamielennox01:00
stevemarjamielennox: rel note clean up, looks good otherwise01:02
stevemarjamielennox: also dooooooooooooooooocs01:02
stevemar:)01:02
stevemarjamielennox: but they can be done later01:02
* jamielennox grumbles01:03
*** chrisplo_ has quit IRC01:05
*** guoshan has joined #openstack-keystone01:22
openstackgerritJamie Lennox proposed openstack/keystonemiddleware: Pass ?allow_expired  https://review.openstack.org/38210001:22
jamielennoxnot sure what's going on with my releasenotes job, i can't see the difference01:22
*** guoshan has quit IRC01:26
*** stingaci_ has joined #openstack-keystone01:26
*** zhangjl has joined #openstack-keystone01:28
*** stingaci has quit IRC01:29
*** stingaci_ has quit IRC01:36
*** guoshan has joined #openstack-keystone01:36
*** liujiong has joined #openstack-keystone01:44
*** stingaci has joined #openstack-keystone01:50
*** stingaci has quit IRC01:51
*** stingaci has joined #openstack-keystone01:51
*** adrian_otto has quit IRC01:54
*** pleia2 has left #openstack-keystone01:56
*** masuberu has joined #openstack-keystone02:00
*** masber has quit IRC02:03
*** masber has joined #openstack-keystone02:04
*** diazjf has joined #openstack-keystone02:05
*** masuberu has quit IRC02:05
*** nicolasbock has quit IRC02:05
*** nicolasbock has joined #openstack-keystone02:06
*** diazjf has quit IRC02:19
*** browne has quit IRC02:19
*** stingaci has quit IRC02:21
*** stingaci has joined #openstack-keystone02:21
*** stingaci_ has joined #openstack-keystone02:22
*** Matias has quit IRC02:22
*** diazjf has joined #openstack-keystone02:25
*** Matias has joined #openstack-keystone02:25
*** stingaci has quit IRC02:25
*** stingaci_ has quit IRC02:27
stevemarjamielennox: relnotes look good02:30
stevemarjamielennox: the dang docs job has been weird02:30
*** ngupta has joined #openstack-keystone02:30
*** diazjf has quit IRC02:31
stevemarjamielennox: looks recent02:32
*** jamielennox is now known as jamielennox|away02:36
*** jamielennox|away is now known as jamielennox02:51
*** dave-mccowan has joined #openstack-keystone02:54
*** tqtran has joined #openstack-keystone02:59
*** harlowja has quit IRC03:03
*** tqtran has quit IRC03:03
*** browne has joined #openstack-keystone03:09
*** browne has quit IRC03:11
*** asettle has joined #openstack-keystone03:12
*** zhangjl has left #openstack-keystone03:13
*** chrisplo_ has joined #openstack-keystone03:14
*** asettle has quit IRC03:17
*** chrisplo_ has quit IRC03:18
*** Zer0Byte__ has quit IRC03:19
openstackgerritLance Bragstad proposed openstack/keystone: WIP implementation for password requirements API  https://review.openstack.org/41051603:32
*** dave-mccowan has quit IRC03:34
*** r-daneel has quit IRC03:38
*** markvoelker has quit IRC03:49
openstackgerritOpenStack Proposal Bot proposed openstack/python-keystoneclient: Updated from global requirements  https://review.openstack.org/41108103:55
openstackgerritOpenStack Proposal Bot proposed openstack/python-keystoneclient-kerberos: Updated from global requirements  https://review.openstack.org/37368603:55
*** ngupta has quit IRC03:57
*** ngupta has joined #openstack-keystone03:57
*** adrian_otto has joined #openstack-keystone04:01
*** ngupta has quit IRC04:02
*** links has joined #openstack-keystone04:06
*** adrian_otto has quit IRC04:13
*** dikonoor has joined #openstack-keystone04:13
*** nicolasbock has quit IRC04:17
openstackgerritSteve Martinelli proposed openstack/keystonemiddleware: clean up a few doc building warnings  https://review.openstack.org/41106104:31
stevemarjamielennox: i have no idea whats going on with the doc build for ksm04:33
openstackgerritLance Bragstad proposed openstack/keystone: Make _option_dict() a method for domain_config_api  https://review.openstack.org/41110004:33
openstackgerritLance Bragstad proposed openstack/keystone: Remove impossible case from _option_dict method  https://review.openstack.org/41110104:33
openstackgerritSteve Martinelli proposed openstack/keystonemiddleware: clean up a few doc building warnings  https://review.openstack.org/41106104:33
openstackgerritMerged openstack/keystone: Add unit tests for doctor tokens symptoms  https://review.openstack.org/41096404:34
openstackgerritSteve Martinelli proposed openstack/keystonemiddleware: clean up a few doc building warnings  https://review.openstack.org/41106104:35
*** markvoelker has joined #openstack-keystone04:51
*** markvoelker has quit IRC04:55
*** adrian_otto has joined #openstack-keystone04:56
*** tqtran has joined #openstack-keystone05:00
openstackgerritLance Bragstad proposed openstack/keystone: Implement password requirements API  https://review.openstack.org/41051505:00
*** tqtran has quit IRC05:04
rderoselbragstad ^ ++05:06
lbragstadrderose o/05:07
*** diazjf has joined #openstack-keystone05:07
rderoselbragstad: nice suite of tests for this :)05:07
lbragstadrderose thanks!05:07
lbragstad70 lines of implementation and 478 lines of tests ;)05:07
lbragstadthat's my kinda change05:07
rderoselbragstad: haha, oh yeah!05:08
stevemarlbragstad: make sure you reference https://blueprints.launchpad.net/keystone/+spec/pci-dss-password-requirements-api ;)05:09
*** diazjf has quit IRC05:09
lbragstadstevemar didn't i? https://review.openstack.org/#/c/410515/4//COMMIT_MSG05:10
stevemarlbragstad: you did! my bad05:10
openstackgerritLance Bragstad proposed openstack/keystone: Implement password requirements API  https://review.openstack.org/41051505:12
stevemarhey breton_ whats up with https://blueprints.launchpad.net/keystone/+spec/fernet-key-store -- is it happening?05:12
lbragstadalrighty - signing off for a bit05:17
lbragstadcatch all you cool cats tomorrow05:17
*** guoshan has quit IRC05:19
*** dhellmann has quit IRC05:39
*** dhellmann has joined #openstack-keystone05:39
openstackgerritRichard Avelar proposed openstack/keystone: Fix a typo in comment  https://review.openstack.org/41111905:50
openstackgerritRichard Avelar proposed openstack/keystone: Add unit tests for doctor token_fernet symptoms  https://review.openstack.org/41092605:53
openstackgerritMerged openstack/python-keystoneclient: Updated from global requirements  https://review.openstack.org/41108105:56
*** udesale has joined #openstack-keystone06:00
*** guoshan has joined #openstack-keystone06:01
*** trananhkma has joined #openstack-keystone06:06
*** jaosorior has joined #openstack-keystone06:16
*** liujiong has quit IRC06:25
*** liujiong has joined #openstack-keystone06:26
*** adrian_otto has quit IRC06:39
*** richm has quit IRC06:41
*** narasimha_SV has joined #openstack-keystone06:41
*** adrian_otto has joined #openstack-keystone06:42
*** namnh has joined #openstack-keystone06:43
*** adriant has quit IRC06:50
*** markvoelker has joined #openstack-keystone06:51
*** markvoelker has quit IRC06:56
*** ngupta has joined #openstack-keystone06:58
*** adrian_otto has quit IRC06:58
*** AJaeger has joined #openstack-keystone07:01
*** tqtran has joined #openstack-keystone07:02
AJaegerkeystone cores, stevemar pointed out to me that keystonemiddleware fails to build.07:02
AJaegerI suggest to use constraints for it in tox.ini, see http://lists.openstack.org/pipermail/openstack-dev/2016-December/108742.html07:02
*** ngupta has quit IRC07:02
*** tqtran has quit IRC07:06
*** rcernin has joined #openstack-keystone07:13
*** tobberydberg has joined #openstack-keystone07:15
gagehugostevemar: can confirm that setting docutils =! 0.13.1 fixes the issue with keystonemiddleware07:19
openstackgerritGage Hugo proposed openstack/keystonemiddleware: Add docutils contraint on 0.13.1 to fix building  https://review.openstack.org/41114207:22
AJaegergagehugo: best would be to use constraints completely to avoid such situations in the future07:26
gagehugoAJaeger: yeah that would probably be a good idea, thanks for the link07:35
*** liujiong_66 has joined #openstack-keystone07:36
AJaegergagehugo: keystone has constraints already enabled07:36
*** jaosorior has quit IRC07:37
*** jaosorior has joined #openstack-keystone07:37
gagehugoyeah it looks like the issue is exclusive to keystonemiddleware?07:38
*** liujiong has quit IRC07:39
*** zhugaoxiao has quit IRC07:39
*** zhugaoxiao has joined #openstack-keystone07:39
*** gagehugo_ has joined #openstack-keystone07:42
openstackgerritDirk Mueller proposed openstack/keystoneauth: Remove discover from test-requirements  https://review.openstack.org/41115307:48
*** gagehugo_ has joined #openstack-keystone07:53
*** gagehugo_ has quit IRC07:53
AJaegergagehugo: might be exclusive to keystonemiddleware for keystone team ;) But it's more widespread, see the linked email07:53
*** jaosorior has quit IRC07:55
breton_stevemar: hi, yes. I need to brush up https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:bp/fernet-key-store (including -2 from ayoung_dadmode)08:02
*** AJaeger has left #openstack-keystone08:07
*** oomichi has quit IRC08:23
*** oomichi has joined #openstack-keystone08:23
*** aloga has quit IRC08:25
*** aloga has joined #openstack-keystone08:25
*** zhangqiankun has joined #openstack-keystone08:26
*** jaosorior has joined #openstack-keystone08:30
*** pcaruana has joined #openstack-keystone08:37
*** GB21 has joined #openstack-keystone08:42
*** amoralej|off is now known as amoralej08:51
*** markvoelker has joined #openstack-keystone08:52
*** markvoelker has quit IRC08:58
*** zzzeek has quit IRC09:00
*** zzzeek has joined #openstack-keystone09:00
*** tqtran has joined #openstack-keystone09:03
*** tqtran has quit IRC09:07
*** masber has quit IRC09:07
*** masber has joined #openstack-keystone09:08
*** __zouyee has joined #openstack-keystone09:08
*** __zouyee has quit IRC09:09
*** asettle has joined #openstack-keystone09:14
*** asettle has quit IRC09:19
*** masuberu has joined #openstack-keystone09:23
*** masber has quit IRC09:27
*** masber has joined #openstack-keystone09:33
*** masuberu has quit IRC09:36
*** masuberu has joined #openstack-keystone09:43
*** masber has quit IRC09:43
*** guoshan has quit IRC09:45
*** masber has joined #openstack-keystone09:46
*** masuberu has quit IRC09:49
*** zhugaoxiao has quit IRC09:50
*** zhugaoxiao has joined #openstack-keystone09:51
*** asettle has joined #openstack-keystone10:10
*** asettle has quit IRC10:10
*** asettle has joined #openstack-keystone10:11
jamielennoxgagehugo: thanks for fixing that, we had been discussing it earlier and hadnt seen that email10:12
jamielennoxstevemar: i could probably just merge https://review.openstack.org/#/c/411142/ but i'll leave it for you tomorrow, can you recheck everything afterwards please?10:13
*** jvarlamova has joined #openstack-keystone10:13
*** jvarlamova___ has quit IRC10:16
*** GB21 has quit IRC10:17
*** openstackgerrit has quit IRC10:18
*** liujiong_66 has quit IRC10:21
*** asettle__ has joined #openstack-keystone10:22
*** asettle has quit IRC10:25
*** edmondsw has joined #openstack-keystone10:48
*** GB21 has joined #openstack-keystone10:48
*** asettle__ is now known as asettle10:48
*** edmondsw has quit IRC10:52
*** markvoelker has joined #openstack-keystone10:54
*** zhangqiankun has quit IRC10:55
*** zhangqiankun has joined #openstack-keystone10:55
*** markvoelker has quit IRC10:59
*** narasimha_SV has quit IRC11:05
*** richm has joined #openstack-keystone11:09
*** mvk has quit IRC11:22
*** namnh has quit IRC11:36
*** mvk has joined #openstack-keystone11:50
*** nicolasbock has joined #openstack-keystone12:04
*** masuberu has joined #openstack-keystone12:05
*** masber has quit IRC12:05
*** david-lyle has quit IRC12:05
*** david-lyle has joined #openstack-keystone12:05
*** BlackDex has quit IRC12:07
*** evrardjp has quit IRC12:08
*** BlackDex has joined #openstack-keystone12:09
*** evrardjp has joined #openstack-keystone12:13
*** udesale has quit IRC12:19
stevemarjamielennox: https://review.openstack.org/#/c/411153/112:30
stevemarjamielennox: you could have solo-approved it, but it's cool12:31
*** GB21 has quit IRC12:40
*** GB21 has joined #openstack-keystone12:41
*** Raildo has joined #openstack-keystone12:47
*** Raildo_ has joined #openstack-keystone12:47
*** Raildo_ is now known as raildo_12:48
*** chlong has joined #openstack-keystone12:51
*** Raildo has quit IRC12:53
*** markvoelker has joined #openstack-keystone12:55
*** catintheroof has joined #openstack-keystone13:00
*** markvoelker has quit IRC13:00
*** catintheroof has quit IRC13:01
*** catintheroof has joined #openstack-keystone13:01
*** dave-mccowan has joined #openstack-keystone13:07
*** amoralej is now known as amoralej|lunch13:10
*** GB21 has quit IRC13:10
*** openstackgerrit has joined #openstack-keystone13:11
openstackgerritMerged openstack/keystone: Make _option_dict() a method for domain_config_api  https://review.openstack.org/41110013:11
openstackgerritMerged openstack/keystone: Remove impossible case from _option_dict method  https://review.openstack.org/41110113:11
stevemarsamueldmq: want to check https://review.openstack.org/#/c/410926/ too?13:13
*** edmondsw has joined #openstack-keystone13:15
openstackgerritSteve Martinelli proposed openstack/keystonemiddleware: clean up a few doc building warnings  https://review.openstack.org/41106113:17
*** edmondsw has quit IRC13:17
*** edmondsw has joined #openstack-keystone13:17
*** GB21 has joined #openstack-keystone13:17
openstackgerritSteve Martinelli proposed openstack/keystone: Fix a typo in comment  https://review.openstack.org/41111913:19
*** SamYaple has quit IRC13:22
*** SamYaple has joined #openstack-keystone13:22
*** GB21 has quit IRC13:23
*** guoshan has joined #openstack-keystone13:25
*** links has quit IRC13:31
*** ayoung_dadmode is now known as ayoung13:32
ayoungbreton_, you understand my comments there?13:32
openstackgerritMerged openstack/keystonemiddleware: Add docutils contraint on 0.13.1 to fix building  https://review.openstack.org/41114213:38
*** GB21 has joined #openstack-keystone13:38
openstackgerritSteve Martinelli proposed openstack/keystonemiddleware: clean up a few doc building warnings  https://review.openstack.org/41106113:42
openstackgerritSteve Martinelli proposed openstack/keystonemiddleware: Updated from global requirements  https://review.openstack.org/41106213:42
openstackgerritSteve Martinelli proposed openstack/keystonemiddleware: Pass ?allow_expired  https://review.openstack.org/38210013:42
breton_ayoung: yes, but lets talk about them a little later this week or next13:42
breton_ayoung: i am not sure why it is -2 and not -1 though, because we still need the manager for keystone to read keys13:42
ayoungbreton_, not the right abstraction.13:43
stevemaranyone want to look at https://review.openstack.org/#/c/382100/ it's the last patch for allowing expired tokens to validate for services13:43
breton_ayoung: what would be the right abstraction then?13:43
ayoungbreton_, you want to discuss this now?  I am game.13:43
ayoungWith fernet, we defer a lot to python-cryptography13:44
breton_ayoung: i have 15 minutes, so lets try13:44
ayoungwe don't want to be in the business of defining things like keystore etc13:44
ayoungthese are security sensitive areas, cross cutting concernts etc13:44
ayoungso We could have implemented even Fernet strictly in Keystone, but chose to work with the python-cryptography team instead13:45
ayoungits mostly the Barbican folks13:45
ayoungfor a Keystore, it is the same kind of issue:13:45
ayoungideally, it would be stored in some form of Hardened container13:45
ayoungbut we don;t want to be defining that in Keystone, anymore than we would be writing a database13:46
ayoungso, lets assume that there is a keystore abstraction in python-cryptography, and we just need to have the configuration options in Keystone to say how to fine it, what type it is etc13:47
ayoungand then the rest goes into python-cryptography.13:47
ayoungbreton_, we actually are addressing this issue at the platform level in my group:13:47
ayoungthere is a system tool called custodia that we are developing for use cases like this.  And remember, we are going to be talking containers and all that , so it is a pretty tricky omne to deal with13:48
ayoungbreton_, https://github.com/latchset/custodia13:48
ayoungbreton_, this is more than just Fernet and Credential encryption keys.  It is all all the database passwords, MessageQ password, and any other sensitive values.13:49
*** zhangqiankun has quit IRC13:50
ayoungbreton_, and we have lots of people that can help us with this, we don't have to do it all ourselves.13:50
ayoungSo, we don't need the Manager abstraction inside Keystone, although the end state will look similar to an outsider, just it will use the python-cryptography abstraction, and keystone will only hold the configuration option for it.13:50
ayoungbreton_, one other place this came up is for multi-keystone Fernet key exchange13:51
ayoungthe fact that we built out own actually goes against one of the workflow constraints of Tripleo/Fuel/Kolla, which is that all the provisioning happens on the configuration nodes, and then gets pushed to all of the controllers equally13:52
ayoungthere are lots of examples of prior art for how to do key exchanges in a secure manner and all that, but again, we don't want to write that into Keystone13:52
ayoungbreton_, OK?13:53
dstanekayoung: rolling your own is the best part of being a developer :-D13:53
breton_ayoung: how ready is it?13:53
ayoungbreton_, Custodia?13:54
breton_ayoung: it and and its datastores13:54
ayoungbreton_, Good question. It has been focused on other use cases, and makes some assumptions that may not hold true for us.13:54
ayoungThere is also the whole "it was developed by Red Hat" aspect that means it is less tested on Debian based platforms13:55
breton_ayoung: i pursue only 1 use case in the patches: rotation for keystone in docker containers13:55
breton_*for fernet keys in docker containers13:55
ayoungbreton_, I hope at least 2, as we need exactly that for Credentials as well13:56
ayoungwhich is the exact same mechanism for signing13:56
breton_ayoung: well, actually no. dolphm had an idea to store fernet keys in the credentials database13:56
ayoung"One key to bind them all..."13:57
breton_i understand that it's, hm, suboptimal13:58
breton_but the keys for credentials are rotated not so often13:58
ayoungbreton_, so, before I lift any -2, do your due dilligence.  Go talk with the python cryptography folks.  Look into Custodia, and also how docker/Kubernetes does secrets13:58
ayoungAnsible, too13:59
ayoungIf it turns out that this is absolutly the only way, I will back off13:59
ayoungHowever, I suspect that the right approach is actually using some form of Key exchange protocol and a hardened datastore for the keys14:00
ayoungwhen you call the fernet function in python-cryptography, you should be passing in  keystore.14:01
breton_i don't need hardened datastore and i don't do the backends for security or distributing reasons14:01
breton_but i got your point14:03
breton_keystone should not do this job14:03
breton_i know how k8s does secrets and there was a reason why i couldn't do it, let me check14:05
*** tqtran has joined #openstack-keystone14:07
*** amoralej|lunch is now known as amoralej14:09
*** lamt has joined #openstack-keystone14:10
*** tqtran has quit IRC14:11
*** GB21 has quit IRC14:14
samueldmqmorning keystone14:14
samueldmqstevemar: hey, done14:14
*** stingaci has joined #openstack-keystone14:14
*** stingaci has quit IRC14:19
*** chlong has quit IRC14:20
kukaczhi, I would like to ask a implementation design question - we're running Kilo OpenStack with LDAP as the only Keystone backend14:22
dstanekhi samueldmq14:22
dstanekkukacz: fire away. hopefully someone here will know the answer14:22
kukaczdstanek: thanks :-)14:22
kukacznow it seems we'll need to move to use federation only, via SAML14:22
*** chlong has joined #openstack-keystone14:22
kukaczi do know nothing about that14:22
kukaczdo I understand it so, that SAML is not only a SSO solution for web frontends, but it can also be used by API accesses?14:23
samueldmqdstanek: o/14:23
kukaczI mean - does Keystone take the username+password from API call and attempt to authenticate it via SAML against the IDP?14:23
dstanekkukacz: what is your motivation to use fedeation of LDAP auth?14:24
dstanekkukacz: no, keystone doesn't touch a user's password during a SAML flow14:24
dstanekkukacz: you could still have your service users use username/password and have your users federate14:24
dstanekour commandline support for federation is a bit rough14:25
kukaczdstanek: thanks. motivation is to integrate tenants with their own identity sources14:26
kukaczkukacz: I wonder, how it works with CLI or direct API calls14:26
*** chlong has quit IRC14:26
dstanekkukacz: direct API calls to keystone?14:27
kukaczin LDAP I understand it takes the password and username and attempts to bind14:27
kukaczand maybe I'm wrong but am trying to compare the process to SAML14:27
*** chlong has joined #openstack-keystone14:28
kukaczdstanek: no, I mean when user sends whatever - eg. a nova boot command14:28
dstanekkukacz: the short, semi-technically accurate version of the flow is that when you want to get token you hit a special URL - it tells you where you IdP is - you go there to auth - upon success it give you an assertion to give to keystone14:28
kukaczdstanek: in the backend, it takes the username and password from some environment variables and passess them with the request to keystone14:28
dstanekkukacz: nova has no idea that the user authed via fedeation. it just get a token like normal14:29
*** ngupta has joined #openstack-keystone14:29
kukaczdstanek: sure, that part about nova and keystone tokens I understand. I just wished to give real life example14:29
kukaczwhat I don't understand is if there's still some password flow from the client to keystone14:30
dstanekkukacz: cli or horizon?14:30
kukaczCLI14:31
rderoserodrigods: any chance you can push this one through: https://review.openstack.org/#/c/409946/14:32
rderosesamueldmq: you around?14:32
samueldmqrderose: yes14:32
dstanekkukacz: i think i have a working example somewhere...let me look14:33
rderosesamueldmq: I'm not following your "user.local_user.last_auth_at" *equals to* "user.password_ref.created_at" comment14:33
rderosesamueldmq,14:33
kukaczdstanek: that would be great. thank you14:33
samueldmqrderose: why do we do 'user.local_user.last_auth_at > user.password_ref.created_at' ?14:33
openstackgerritMerged openstack/keystone: Add checks for doctor credential symptoms  https://review.openstack.org/40928914:33
rderosesamueldmq: lets say the user last_auth_at before a password admin reset14:34
ayoungECP14:34
rderoseso we're checking if they last authenticated after the password reset (first use)14:34
samueldmqrderose: admin reset == not user.password_ref.self_service14:34
samueldmqrderose: correct?14:35
rderoseno14:35
ayoungkukacz, when doing saml for command line, make sure your IdP is set up for ECP14:35
rderosesamueldmq: sorry, yes14:35
samueldmqrderose: kk14:35
samueldmqrderose: does "admin reset" reset user.password_ref.created_at ?14:36
openstackgerritLance Bragstad proposed openstack/keystone: Implement password requirements API  https://review.openstack.org/41051514:36
rderosesamueldmq: yes14:36
samueldmqrderose: and when the user first authenticates self_service becomes true14:37
rderosesamueldmq: no14:37
rderosesamueldmq: becomes self service when user change_password API14:38
kukaczayoung: is it a difference for the user experience, to switch from SQL/LDAP backend to the federation like SAML?14:38
ayoungkukacz, should not be14:38
ayoungkukacz, the difference is in the configuration options you use when calling keystone. I have a sample file...14:39
samueldmqrderose: kk. so, if password was reset by admin and this is the first auth after that, require passwd change14:39
samueldmqrderose: makes sense14:39
kukaczayoung: just for my understanding / practically - does anything change in the typical openrc/keystonerc file?14:39
samueldmqrderose: and by setting user_ref.password_ref.expires_at = now , the current flow will still return a valid token, right ?14:40
ayoungkukacz, the proof of concept we did last year had this http://paste.openstack.org/show/592490/14:40
rderosesamueldmq: yes, because it happens after auth14:40
ayoungthe auth plugin might have a differenct value14:40
samueldmqrderose: that's not the token's expires, but the password that is expiring after now (single validation)14:40
rderosesamueldmq: correct14:40
samueldmqrderose: perfect14:40
samueldmqrderose: neat, I just think that needs a release note then14:41
samueldmqrderose: makese sense to you ?14:41
rderosesamueldmq: cool, on it14:41
rderose:)14:41
samueldmqrderose: perfect14:41
kukaczayoung: great, these examples help me lot to move out of the fog14:41
rderosesamueldmq: thanks14:41
dstanekkukacz: http://paste.openstack.org/show/592491/ i think works on a new sp using testshib14:41
*** guoshan has quit IRC14:41
samueldmqrderose: anytime :)14:41
ayoungkukacz, the pain points seems to be getting ECP set up on the SAML side14:41
ayoungwhat server software are you running there?14:41
kukaczdstanek: thanks!14:42
dstanekkukacz: ayoung: i actually don't know if it's possible to do that in a openrc or cloud.yaml file - that would be a good experiment14:42
kukaczayoung: should be Dell One14:42
kukaczayoung: that should do kind of concentration of multiple tenants' IDPs if I understand it correctly14:43
ayoungkukacz, I am unfamiliar with it, but see if it supports ECP.14:43
kukaczayoung: I'll do14:43
*** edtubill has joined #openstack-keystone14:44
kukaczayoung: it's a multitenant environment. theoretically we could accept diferent tenants with their identity sources14:44
kukaczkukacz: but to me it's really a very new area I just start exploring14:44
*** markvoelker has joined #openstack-keystone14:45
*** edtubill has joined #openstack-keystone14:45
kukacz^^ayoung14:45
*** ngupta has quit IRC14:46
dstanekkukacz: are you doing a private cloud implemenation where everyone uses the same IdP?14:46
*** ngupta has joined #openstack-keystone14:47
kukaczdstanek: no. it's more kind of public cloud for multiple customers. just not exposed so publicly to call it "public cloud"14:47
dstanekkukacz: and each customer would potentially use a separate IdP?14:47
kukaczdstanek: yes. usually the customers are large organizations with own IdPs14:48
dstanekkukacz: one issue you may have is that we don't tie users from one IdP into a domain that is separate from another IdP. that work is happening in this cycle14:50
dstanekbut depending on your needs that may not matter anyway14:50
kukaczdstanek: hmm, is it then correct to think we can bind each customer to a keystone domain having their own IdP?14:50
dstanekkukacz: you can certainly have multiple IdPs. The users all map back to the same domain. In general I don't think this is a big deal, but I wanted to mention it so you can keep it in mind as you experiment.14:52
kukaczdstanek: is it wrong to think of domain=IdP pairing?14:54
ayoungkukacz, it is not wrong...it is what I wanted from the start14:55
ayoungdo we allow setting the domain ID from the mapping rderose ?14:55
ayoungthat would be the first step, I think14:55
openstackgerritRon De Rose proposed openstack/keystone: PCI-DSS Force users to immediately change their password upon first use  https://review.openstack.org/40391614:56
rderoseayoung: no, not through the mapping14:56
rderoseayoung: if we did through the mapping, an idp could be associated to multiple domains14:57
*** udesale has joined #openstack-keystone14:57
rderoseayoung: because idp:protocols (1:many)14:57
ayoungrderose, yeah, I was pretty sure we couldn't today14:57
dstanekayoung: nope, domain in the mapping is ignored14:59
kukaczayoung: dstanek: ok, if I assume the customers' IdPs are concentrated on that Dell tool (is that even possible in SAML?) - then I would use 1 IdP = multiple domains, is that feasible?15:00
openstackgerritRon De Rose proposed openstack/keystone: PCI-DSS Force users to immediately change their password upon first use  https://review.openstack.org/40391615:00
dstanekrderose's work to fix the model would fix this issue15:00
dstanekkukacz: no, all federated users are in the same domain15:00
*** links has joined #openstack-keystone15:01
rderosekukacz: but you could create multiple IdPs with different endpoints15:02
*** chlong has quit IRC15:03
*** phalmos has joined #openstack-keystone15:03
kukaczrderose: what endpoints you mean?15:03
dstanekkukacz: basically you can have multiple IdPs15:04
openstackgerritMerged openstack/keystone: Add unit tests for doctor token_fernet symptoms  https://review.openstack.org/41092615:05
rderosekukacz: exactly and you set the idp_sso_endpoint15:06
rderosekukacz: not sure if that solves your use case15:07
kukaczwell, for some customers I also have the motivation to use an extra domain - I wonder what impact it has to identity protocol options15:08
rderosekukacz: so yeah, if you need multiple domains, you would setup multiple idps15:09
kukaczif all federated customers must use same domain, does it mean I'd need to use non-federated method (LDAP?) for those?15:09
kukaczrderose: ahh, ok then15:09
kukaczif I think of Mitaka release for such implementation - can I utilize the features we're discussing?15:10
dstanekkukacz: idp mapped to a particular domain?15:11
kukaczdstanek: yes15:11
openstackgerritMerged openstack/keystone: Fix a typo in comment  https://review.openstack.org/41111915:11
dstanekkukacz: that's in development now - will be released this cycle15:12
kukaczand what's available in Mitaka then - 1 IDP to 1 domain?15:13
kukacz... altogether15:13
dstanekkukacz: all IdPs map to one domain. rderose is working on fixing this.15:14
kukaczok15:14
kukaczby IdPs you mean just SAML backends or everything, including LDAP?15:15
dstanekkukacz: if you are using LDAP as an identity backend we don't consider that federation. just the SAML stuff in your case.15:15
kukacz... cause now I'm thinking of using SAML for single domain, and various LDAPs for other domains, where needed15:16
kukaczdstanek: so should be possible to use SAML and LDAP in such setup in Mitaka ?15:16
*** mdavidson has quit IRC15:18
dstanekkukacz: i would imagine in mitaka that you could have a bunch of domains using their own LDAP backend and use federation where you can group users together in a single domain15:18
dstanekyou'll have to experiment a little15:18
kukaczdstanek: perfect15:18
kukacznow back to the user experience: do the API library openstack clients like Ansible (shade), or those Ruby based work smoothly with the SAML setups?15:21
kukaczI mean if there are some constraints I should take into account15:22
dstanekkukacz: last i looked support was rough at best15:23
openstackgerritGage Hugo proposed openstack/keystone: Add reason to notifications for PCI-DSS  https://review.openstack.org/39675215:24
*** jaugustine has joined #openstack-keystone15:24
*** jaugustine has quit IRC15:24
*** jaugustine_ has joined #openstack-keystone15:24
*** jaugustine_ is now known as jaugustine15:25
kukaczdstanek: any particular library on mind?15:25
dstanekkukacz: all of our official stuff. it was hard to get anything working15:25
kukaczdstanek: that sounds like I would rather avoid SAML when the customers request interoperability (between cloud provs.) and easy integration with various PaaS framewords15:28
kukaczframeworks15:28
dstanekkukacz: so addtionally we don't have a way to create projects/assignments at auth time. so you can auth to a cloud, but all that stuff has to be setup ahead of time15:32
kukaczdstanek: we can perhaps afford handle this kind of setup in customer onboarding process15:34
kukaczdstanek: the client side support seems to be the major concern for us now15:35
openstackgerritLance Bragstad proposed openstack/keystone: Implement password requirements API  https://review.openstack.org/41051515:36
stevemarsomeone want to push https://review.openstack.org/#/c/411061/ through?15:37
kukaczdstanek: ayoung: rderose: thanks for your great support!15:37
rderosekukacz: ++15:39
lbragstadstevemar https://review.openstack.org/#/c/410515/ was failing with pep8 stuff last night (shame on me for not running it locally)15:40
lbragstadbut - that passes everything for me locally now15:40
lbragstadlet me know if you want it broken up a bit more?15:40
dstanekkukacz: yw15:41
openstackgerritDavid Stanek proposed openstack/keystone-specs: Versioned federation mappings  https://review.openstack.org/41139215:41
*** GB21 has joined #openstack-keystone15:43
*** phalmos has quit IRC15:44
openstackgerritSteve Martinelli proposed openstack/keystonemiddleware: Pass ?allow_expired  https://review.openstack.org/38210015:46
*** tobberyd_ has joined #openstack-keystone15:47
*** tobberydberg has quit IRC15:50
*** tobberyd_ has quit IRC15:51
rderosesamueldmq: you still around?15:52
stevemarlbragstad: let me check it today15:53
*** chris_hultin|AWA is now known as chris_hultin15:58
openstackgerritMerged openstack/keystonemiddleware: Updated from global requirements  https://review.openstack.org/41106216:01
*** links has quit IRC16:04
openstackgerritRichard Avelar proposed openstack/keystone: Add doctor checks for ldap symptoms  https://review.openstack.org/40929216:04
*** udesale has quit IRC16:05
*** dikonoor has quit IRC16:08
*** tqtran has joined #openstack-keystone16:08
*** chris_hultin is now known as chris_hultin|AWA16:10
*** chris_hultin|AWA is now known as chris_hultin16:10
*** tqtran has quit IRC16:12
*** dave-mccowan has quit IRC16:13
samueldmqrderose: yes16:14
openstackgerritSteve Martinelli proposed openstack/keystonemiddleware: Pass ?allow_expired  https://review.openstack.org/38210016:15
samueldmqbrb16:15
*** ayoung has quit IRC16:17
stevemaredmondsw: thanks ^16:17
rderosesamueldmq: looks like I'll need a new patch for https://review.openstack.org/#/c/399684/16:17
edmondswstevemar np... looks good now16:19
stevemarwe need another core to look at jamielennox's patch -- any takers for https://review.openstack.org/382100 ? breton_ ?16:20
stevemaredmondsw: we need docs for it16:21
*** ravelar has joined #openstack-keystone16:22
*** Zer0Byte__ has joined #openstack-keystone16:25
*** Zer0Byte__ has quit IRC16:26
*** adrian_otto has joined #openstack-keystone16:28
*** dave-mccowan has joined #openstack-keystone16:29
*** phalmos has joined #openstack-keystone16:29
*** jaosorior has quit IRC16:30
*** jaosorior has joined #openstack-keystone16:31
*** itisha has joined #openstack-keystone16:31
stevemardolphm: ^16:32
dolphmlbragstad: dstanek: ^^^16:32
dolphmrderose: ravelar: ^^^^^ (that's on the OSIC roadmap)16:32
dolphmfor nova live migrations16:33
lbragstaddolphm stevemar i'll look - stevemar i assume we'll cut a release for ksm after that?16:34
rderosedolphm: ?16:34
rderosein standup16:34
*** rcernin has quit IRC16:34
lbragstaddstanek rderose sounds like we have a todo to review - https://review.openstack.org/#/c/382100/16:34
stevemarlbragstad: yes, it'll need a ksm release16:34
lbragstadstevemar are we waiting for anything else after the ?allow_expired stuff is merged?16:35
stevemarlbragstad: nope16:35
stevemarlbragstad: no rush, i would like to release today, but it can wait til monday *shrugs*16:35
lbragstadstevemar sweet - i'll get to that today then16:35
stevemarno releases on friday16:35
lbragstadstevemar i'll review it next then, and then review dstanek's spec16:36
openstackgerritMerged openstack/keystonemiddleware: clean up a few doc building warnings  https://review.openstack.org/41106116:36
*** GB21 has quit IRC16:38
*** jaosorior has quit IRC16:39
*** jaosorior has joined #openstack-keystone16:40
*** edmondsw has quit IRC16:40
*** edmondsw has joined #openstack-keystone16:41
*** pcaruana has quit IRC16:42
*** edmondsw has quit IRC16:45
*** edmondsw has joined #openstack-keystone16:47
*** diazjf has joined #openstack-keystone16:49
*** GB21 has joined #openstack-keystone16:51
*** edmondsw has quit IRC16:51
*** rcernin has joined #openstack-keystone16:54
samueldmqrderose: why? because of 'that_you' ?16:57
*** edmondsw has joined #openstack-keystone16:59
rderosesamueldmq: during the migration, I'm auto creating a new domain for each idp; using the idp_id as the name for the domain17:00
rderosesamueldmq: problem is the name should be unique and there is a chance (unlikely, but possible) that an admin has already created a domain with that same name (idp_id)17:00
samueldmqrderose: "Federated domain for Identity Provider: " + idp_id ?17:01
rderosesamueldmq: not the description, but the domain.name17:01
samueldmqrderose: which is just idp_id.17:02
rderosesamueldmq: correct, but there may already be a domain with that name17:02
rderoselike I said, unlikely, but possible17:02
rderosesamueldmq: so for the domain name, I'll just use the domain id17:03
rderosesamueldmq: the domain name needs to be unique17:03
*** edmondsw has quit IRC17:03
rderosesamueldmq: make sense?17:03
samueldmqrderose: and how will you find the idp_id when binding that domain to federated users (in the followup patch)?17:04
rderosesamueldmq: we capture the idp when the federated user auth, so if we have the idp_id, we'll have the domain_id17:05
*** browne has joined #openstack-keystone17:05
rderosesamueldmq: I won't look in the domain table for the idp, I'll have the idp and just get the domain17:06
samueldmqrderose: kk17:06
samueldmqrderose: that makes sense to me.17:07
rderosesamueldmq: and the description will still say something like "Auto generated Federated domain for IdP: idp_id"17:07
rderosesamueldmq: cool17:07
samueldmqrderose: that works for me to do id == name17:07
rderosealright, thx17:07
samueldmqrderose: yes I like auto generated17:07
samueldmqsure17:07
*** raildo_ has quit IRC17:11
*** edmondsw has joined #openstack-keystone17:13
dstanek1/b 2417:16
*** GB21 has quit IRC17:16
openstackgerritSamuel Pilla proposed openstack/keystone: Add password expiration queries for PCI-DSS  https://review.openstack.org/40389817:17
*** edmondsw has quit IRC17:18
*** Zer0Byte__ has joined #openstack-keystone17:22
*** edmondsw has joined #openstack-keystone17:25
*** asettle has quit IRC17:27
*** raildo_ has joined #openstack-keystone17:29
openstackgerritRon De Rose proposed openstack/keystone: Require domain_id when registering Identity Providers  https://review.openstack.org/39968417:29
*** edmondsw has quit IRC17:30
*** tqtran has joined #openstack-keystone17:30
lbragstaddstanek looks good - https://review.openstack.org/#/c/411392/117:34
lbragstaddstanek i had one grammar comment, but that was really it17:34
*** catinthe_ has joined #openstack-keystone17:36
*** edmondsw has joined #openstack-keystone17:38
*** catintheroof has quit IRC17:38
*** edmondsw has quit IRC17:42
*** jaosorior has quit IRC17:44
*** edmondsw has joined #openstack-keystone17:44
*** mvk has quit IRC17:45
*** asettle__ has joined #openstack-keystone17:49
dstaneklbragstad: cool. wanted to make sure it was inline with what we have been talking about17:56
*** asettle__ has quit IRC17:56
lbragstaddstanek yeah - it works for me17:56
lbragstaddstanek well written, too17:56
lbragstaddstanek i don't think it should collide at all with the stuff i'm working on17:56
dstaneklbragstad: thx. yeah, i don't either17:57
lbragstadjamielennox nice work on https://review.openstack.org/#/c/382100/917:58
dstaneklbragstad: jamielennox: ++17:58
*** dikonoor has joined #openstack-keystone18:06
openstackgerritLance Bragstad proposed openstack/keystone: Implement password requirements API  https://review.openstack.org/41051518:08
lbragstaddolphm looks like https://review.openstack.org/#/c/408837/4 and https://review.openstack.org/#/c/408838/5 are both passing stable/mitaka18:11
*** ngupta has quit IRC18:11
*** ngupta has joined #openstack-keystone18:12
*** ngupta_ has joined #openstack-keystone18:13
*** chlong has joined #openstack-keystone18:14
*** ngupta has quit IRC18:16
*** asettle__ has joined #openstack-keystone18:17
*** diazjf has quit IRC18:23
openstackgerritLance Bragstad proposed openstack/keystone: Implement password requirements API  https://review.openstack.org/41051518:27
*** amoralej is now known as amoralej|off18:27
*** asettle__ has quit IRC18:27
*** pabelanger has joined #openstack-keystone18:28
pabelangergreetings, noob question. Is keystone smart enough to start, if keystone.conf is missing? Eg: are their sane defaults that get applied?18:29
pabelangerthere*18:29
*** harlowja has joined #openstack-keystone18:31
openstackgerritDavid Stanek proposed openstack/keystone: Adds role mapping to the mapping engine  https://review.openstack.org/41094918:32
lbragstadstevemar does the install guide not recommend using apache?18:33
dstaneklbragstad: rderose: i think that's working now, but i want to wait until you get further in your implementation where it's needed to work on getting it merged ^18:33
dstanekpabelanger: i've never tried, but i can't imagine it will work without setting up a db or ldap connection at a minimum18:34
rderosedstanek: okay, cool18:35
dstanekrderose: you can probably build your patch on top of it to make sure it all works18:36
*** asettle__ has joined #openstack-keystone18:36
lbragstaddstanek i'll probably start by putting my stuff on there, too18:36
lbragstadstevemar i'm reading up on https://etherpad.openstack.org/p/community-goals and noticed your comment18:37
openstackgerritSamuel Pilla proposed openstack/keystone: Add password expiration queries for PCI-DSS  https://review.openstack.org/40389818:38
openstackgerritDavid Stanek proposed openstack/keystone: Adds role mapping to the mapping engine  https://review.openstack.org/41094918:41
rderosedstanek: reading the mapping version spec now, I see the need for this, but it makes me somewhat uncomfortable.18:44
rderosedstanek: I don't like the idea of having to support multiple version and I don't want to require the version in the API.18:44
rderosedstanek: but not sure how you make significant changes without it :)18:44
rderosedstanek: is it just to be backwards compatible?18:44
rderosethe changes we're planning will break existing mapping rules?18:45
*** stingaci has joined #openstack-keystone18:48
dstanekrderose: quite possibly yes18:48
rderosedstanek: but if we keep this in the scope of shadow mapping, we may not break existing rules; thus, may not need this?18:48
dstanekwhy do you not like being explicit about the version?18:49
dstanekrderose: you don't need this. that's why it has it's own spec18:49
dstanekthe changes i've made to support you are backward compatibe18:49
rderosedstanek: ah, right18:49
rderosedstanek: being explicit about the version, means operators need to understand the different version; makes it more complicated18:50
rderosehaving to document the multiple versions...18:51
rderoseas opposed to having a single mapping engine design18:51
rderosedstanek: but understand your reasoning...18:51
*** itisha has quit IRC18:52
*** harlowja has quit IRC18:52
dstanekrderose: yeah, unfortunately we always have to support what we are doing for some amount of time18:52
rderosedstanek: true, it's just this feels little like the cart in front of the horse :)18:53
stevemarlbragstad: oh? which comment, i had many18:55
lbragstadstevemar line 29 - https://etherpad.openstack.org/p/community-goals18:55
stevemarlbragstad: yeah, def a change to install guide18:56
lbragstadhttp://docs.openstack.org/newton/install-guide-ubuntu/keystone-install.html#configure-the-apache-http-server ?18:58
lbragstadstevemar are you saying all projects need to double check that the install guide includes instructions for using apache?18:58
lbragstadlooks like we use apache for the keystone bits (obvisouly - since we don't support eventlet)18:59
lbragstadstevemar also - did you happen to see line 132? https://etherpad.openstack.org/p/community-goals19:01
dstanekrderose: getting ready for version changes before we need them?19:01
rderosedstanek: I think we should only version the mapping if we are adding changes that break the existing implementation. If not, then this is not needed and not worth the overhead of having to support multiple versions and for operators to have to understand them.19:02
lbragstaddstanek I don't know about you, but I almost always find a way to get the cart in front of the horse ;)19:02
rderose:)19:02
lbragstaddstanek versioning won't be required, will it?19:02
dstanekrderose: we are not proposing a new version. just the mechanism by which we can19:02
dstaneklbragstad: not at all19:02
*** catintheroof has joined #openstack-keystone19:02
stevemarlbragstad: what about line 13219:02
lbragstaddstanek if a mapping is created without a version, everything should just work19:03
stevemarwe'll need to produce 2 samples with that, or finally decide on one19:03
dstaneklbragstad: yep, it's just version 1. with version 2 coming sometime in the future19:03
lbragstadstevemar what's the new style?19:03
rderoselbragstad dstanek: I see19:03
lbragstadstevemar the section doesn't really say what the difference is19:03
lbragstadstevemar or what the new style is and explicitly why we should move to it19:04
rderosedstanek lbragstad: and we may not ever get version 219:04
samueldmqdstanek: https://review.openstack.org/#/c/410949 just allows roles in the mapping19:04
samueldmqdstanek: there will be other patches for projects and groups19:04
*** asettle__ has quit IRC19:04
samueldmqdstanek: then followup with creating the resources19:04
samueldmqdstanek: is that the plan?19:05
dstanekrderose: that why i said in the meeting that i would be OK pushing it if people are uncomfortable for any reason. sometime in the first quarter next year i'll be looking to see what Rackspace features we need to add19:05
rderosedstanek: okay19:05
lbragstadstevemar by new style do they mean move all policy defaults into oslo.policy, following the pattern nova has established?19:05
dstaneksamueldmq: yes. that was a real quick proof of concept19:05
stevemarlbragstad: they mean to follow nova's pattern, because everyone knows nova does no wrong :P19:06
dstaneksamueldmq: i told lbragstad something was possible and when i write a test to verify i found out it wasn't19:06
stevemarlbragstad: nova stores the defaults in code, have you seen their code?19:06
lbragstadstevemar ah - the section does a great job of *not* explaining that19:06
dstaneksamueldmq: so i "fixed the glitch"19:06
stevemarlbragstad: for example: https://github.com/openstack/nova/tree/master/nova/policies19:06
lbragstadstevemar gotcha - right19:06
*** catinthe_ has quit IRC19:06
*** pabelanger has left #openstack-keystone19:07
samueldmqdstanek: but we do want to merge that, right ? (tiny start, but yes, part of the solution)19:08
stevemaryeah, so we would have something like 'keystone/policies/users' and in there list the various user policies19:08
lbragstadstevemar i was having a conversation with someone (probably dstanek or edmondsw) recently about starting an effort to document policy19:08
stevemarlbragstad: the tricky part is doing this for the 'standard' one and v3 domain aware one19:08
lbragstadstevemar right - that's a monkey wrench on our part19:09
stevemarlbragstad: this would be one less thing for packagers to package19:09
stevemarand if someone wanted to do it, they simply run "tox -e genpolicy"19:09
lbragstadstevemar but the documentation would be detailed towards explaining how policy works, what is supports, what it doesn't, and how to set it up19:09
lbragstadright dstanek and edmondsw ^19:09
samueldmqdstanek: hmm not really, roles should be under a project in the mapping (according to the spec)19:10
stevemarlbragstad: sounds good to me19:10
lbragstad?19:10
lbragstadstevemar do you think that'd be something better suited for a x-project goal?19:10
lbragstadstevemar because I think the end result would be some sort of document that projects could use to compare against their existing defaults, and something for new projects to start using right away to get policy right from the get go19:11
edmondswhaving trouble parsing some of the above...19:13
dstaneksamueldmq: not until i know it works for what they need19:13
samueldmqdstanek: kk19:13
dstaneklbragstad: yep19:14
lbragstaddstanek you were in that conversation?19:14
* lbragstad has been talking about policy so much lately it's hard to keep track of everything 19:15
edmondswstevemar, I think the general consensus (from a conversation at the Austin midcycle, I believe) was that we shouldn't really have 2 policy files anyway, and should merge those19:15
edmondswif we're moving the policy into code (which I think we should), that merging of the 2 policies could happen as part of that, right?19:15
edmondswyou'd be moving things a bit at a time, not try to do it all in one massive patch19:16
lbragstadedmondsw yeah - i would think we be able to combine those efforts19:16
lbragstadedmondsw and i'm all for doing it in bit-sized pieces.19:16
edmondsw++19:16
lbragstadpolicy currently is confusing/hard to understand, and getting people to review confusing stuff in *large* patches is impossible19:17
lbragstads/impossible/impossible to do without increasing the likelihood for more mistakes/19:17
openstackgerritMerged openstack/keystonemiddleware: Pass ?allow_expired  https://review.openstack.org/38210019:18
lbragstadstevemar we can release! ^19:18
stevemarlbragstad: propose a new release ;)19:18
dstaneklbragstad: we talked about it during our Hangout i think19:18
lbragstaddstanek ah19:18
edmondswlbragstad see my latest comment in https://review.openstack.org/#/c/384148 for another example of how complicated policy stuff can get19:19
edmondswand what we should be laying out guidelines for the different projects to avoid19:19
dstaneklbragstad: to measure up each policy impl against a "best practices" and give new projects a place to go officially instead of copy off of "project X"19:19
*** narasimha_SV has joined #openstack-keystone19:20
lbragstadstevemar 4.12.0 ?19:20
narasimha_SVhttp://paste.openstack.org/show/592535/ can anyon please explain me this code in LDAP core.py file19:20
*** asettle has joined #openstack-keystone19:20
narasimha_SVI am using oracle identity service  for LDAP in which user enable attribute is a string value19:21
narasimha_SVI am getting issue in this funtion 258 line19:21
*** chris_hultin is now known as chris_hultin|AWA19:21
edmondswnarasimha_SV fyi, this would be an easier/better way to link that: https://github.com/openstack/keystone/blob/master/keystone/identity/backends/ldap/core.py#L255-L27119:22
narasimha_SVok19:23
* lbragstad stevemar done https://review.openstack.org/#/c/411468/19:23
stevemarty!19:23
lbragstadstevemar 4.12.0 works, right?19:24
narasimha_SVhttps://github.com/openstack/keystone/blob/master/keystone/identity/backends/ldap/core.py#L258 as per logic code execution is moving to this line19:24
narasimha_SVwhich cannot convert a string value to int19:24
stevemarlbragstad: was there a requirements change?19:24
narasimha_SVand my LDAP integration is failing19:24
edmondswnarasimha_SV I'm not sure I can answer your question off the top of my head, though19:24
stevemarlbragstad: https://github.com/openstack/keystonemiddleware/compare/4.11.0...master19:24
stevemaryep19:24
dstaneknarasimha_SV: i would guess by looking at that line that it expects enabled to be 0 or 1. what is it in your case?19:25
narasimha_SVdastanek: its active19:25
samueldmqlbragstad: couple of comments in https://review.openstack.org/#/c/41051519:26
samueldmqlbragstad: code and tests are very well written19:26
edmondswnarasimha_SV are you setting user_enabled_default in your conf, and if so to what value?19:26
lbragstadstevemar http://cdn.pasteraw.com/cmjva1lihnsm320315zsku2jr8t18bi19:26
narasimha_SVbut if you check the code in elif block it is written for taking boolean or string value19:26
lbragstadsamueldmq thanks@19:26
dstaneknarasimha_SV: the string "active"?19:26
narasimha_SVyes19:27
narasimha_SVuser_enabled_default = 5119:27
narasimha_SVthis is the value which I kept19:27
dstaneknarasimha_SV: i don't know how to get that to work. you may have to see if one of the ldap people in here know if there is a standard for what that value should be19:28
*** itisha has joined #openstack-keystone19:28
narasimha_SVif I bypass the code and make the enabled attribute to true LDAP integration is successful19:28
edmondswnarasimha_SV have you read over the descriptions of these conf settings? https://github.com/openstack/keystone/blob/master/keystone/conf/ldap.py#L202-L24519:30
edmondswand how are you setting them?19:30
edmondswuser_enabled_default = 51 doesn't sound right... did you mean 512?19:31
*** gyee has joined #openstack-keystone19:31
openstackgerritDavid Stanek proposed openstack/keystone-specs: Versioned federation mappings  https://review.openstack.org/41139219:33
narasimha_SVyes i just added these confs as I see in the documentation to work with LDAP19:34
*** phalmos_ has joined #openstack-keystone19:34
narasimha_SVhttp://docs.openstack.org/admin-guide/identity-integrate-with-ldap.html19:34
*** Zer0Byte__ has quit IRC19:36
*** asettle has quit IRC19:36
edmondswnarasimha_SV: ah, I think that documentation is wrong... try 512 instead of 51 and see if that helps19:37
narasimha_SVok19:37
edmondswand are you using Active Directory or what type of LDAP?19:37
*** asettle has joined #openstack-keystone19:37
*** phalmos has quit IRC19:37
edmondswnarasimha_SV: also, the values you see in the docs there are for Active Directory, so if you're using a different type of LDAP they would probably need to be different19:38
narasimha_SVok may be you are right19:38
edmondswedmondsw: I've just always left those unset, so they used the defaults19:39
edmondswnarasimha_SV19:39
*** asettle has quit IRC19:41
*** dikonoor has quit IRC19:43
edmondswstevemar, do you know which git project has the admin_guide in it?19:45
stevemaredmondsw: yes sir19:45
stevemaredmondsw: one sec19:45
openstackgerritGage Hugo proposed openstack/keystone: Add reason to notifications for PCI-DSS  https://review.openstack.org/39675219:46
stevemaredmondsw: https://github.com/openstack/openstack-manuals/tree/master/doc/admin-guide/source19:46
edmondswstevemar, ty sir19:46
stevemarnp!19:46
edmondswthey couldn't just call it docs...19:47
stevemar:)19:47
stevemareveryone's a critic!19:47
*** hyakuhei has joined #openstack-keystone19:48
dstanekedmondsw: they are wordsmiths...manuals sounds much more professional than docs19:49
edmondswlol19:49
edmondswnarasimha_SV, see also http://docs.openstack.org/developer/keystone/configuration.html#using-an-ldap-server19:50
edmondswand I'll try to throw up a quick change to fix the admin guide19:50
*** diazjf has joined #openstack-keystone19:50
openstackgerritLance Bragstad proposed openstack/keystone: Implement password requirements API  https://review.openstack.org/41051519:52
lbragstadsamueldmq fixed ^19:52
*** Zer0Byte__ has joined #openstack-keystone19:52
samueldmqlbragstad: +2 from me, thanks19:54
r1chardj0n3sstevemar: are you about? I'm dealing with Horizon fires this morning, could you run the cp meeting pls?19:55
openstackgerritRichard Avelar proposed openstack/keystone: Add doctor checks for ldap symptoms  https://review.openstack.org/40929219:56
edmondswnarasimha_SV: fix proposed https://review.openstack.org/#/c/411477/19:57
lbragstadr1chardj0n3s i could if you need someone to19:58
lbragstadbut - i assume stevemar is around... somewhere19:58
r1chardj0n3sthanks lbragstad, I can certainly kick the meeting off, but I'm quite distracted19:58
lbragstadr1chardj0n3s no worries19:59
lbragstadr1chardj0n3s you typically jsut go down https://etherpad.openstack.org/p/ocata-keystone-horizon hitting each heading, right?19:59
narasimha_SVafter changing http://paste.openstack.org/show/592540/ these varibale to these values19:59
narasimha_SVcode got executed as expected for me20:00
r1chardj0n3slbragstad: I've slightly optimised by asking folks specifically what they want to talk about :-)20:00
stevemarlbragstad: i'm typically round, i mean around20:00
r1chardj0n3sI'm not sure it's better, but it saves a lot of dead air ;-)20:00
lbragstadr1chardj0n3s ++ in that case we do have stevemar!20:00
stevemarr1chardj0n3s: i'm great at filling dead air!20:01
r1chardj0n3s\o/20:01
*** hyakuhei has quit IRC20:04
*** hyakuhei has joined #openstack-keystone20:04
*** hyakuhei has quit IRC20:04
*** hyakuhei has joined #openstack-keystone20:04
*** adrian_otto has quit IRC20:05
*** navid_ has joined #openstack-keystone20:09
*** navid_ has quit IRC20:10
dstanekstevemar: can't pay too much attention in the horizon meeting today. i have another meeting in 18 mins that i'm prepping for20:11
lbragstadstevemar same here20:15
stevemardstanek: lbragstad kk20:18
antwashdolpm : ping20:20
dstanekantwash: looking for dolphm?20:21
antwashdstanek: yeah, he's busy I'm assuming lol20:21
antwashJust wanted to ask about the mulit node gate jobs using grenade for Keystone, was working on it, but seems like it's already in progress by another team https://blueprints.launchpad.net/keystone/+spec/rolling-upgrade-testing20:22
*** stingaci_ has joined #openstack-keystone20:22
gagehugosamueldmq: I have no idea what's going on with releasenotes, it all passes locally. I'm not sure if that elastic bug comment(s) has anything to do with it or if there is something else20:22
*** catintheroof has quit IRC20:22
*** stingaci has quit IRC20:24
*** basilAB has quit IRC20:24
dolphmantwash: julia works for mirantis, but i don't know her nick. and yes, she's got a few patches already up for keystone!20:25
*** basilAB has joined #openstack-keystone20:25
antwashdolphm : yeah, I noticed that, but I'm curious is that eveything that was expected to get done?20:26
*** ayoung has joined #openstack-keystone20:27
*** ChanServ sets mode: +v ayoung20:27
stevemarlbragstad: new ksm is out!20:27
lbragstadstevemar whew, that was exciting20:28
*** lamt has quit IRC20:29
*** diazjf has quit IRC20:32
*** catintheroof has joined #openstack-keystone20:35
openstackgerritRichard Avelar proposed openstack/keystone: Add doctor checks for ldap symptoms  https://review.openstack.org/40929220:38
stevemaredmondsw: around?20:43
edmondswstevemar in mtg20:43
*** narasimha_SV has quit IRC20:44
*** diazjf has joined #openstack-keystone20:45
*** asettle has joined #openstack-keystone20:46
openstackgerritSamuel Pilla proposed openstack/keystone: Add password expiration queries for PCI-DSS  https://review.openstack.org/40389820:47
*** ravelar has quit IRC20:51
*** diazjf has quit IRC20:51
stevemaredmondsw: send me a poke when avail20:53
*** adriant has joined #openstack-keystone20:57
*** diazjf has joined #openstack-keystone21:02
*** stingaci_ has quit IRC21:03
*** stingaci has joined #openstack-keystone21:03
edmondswstevemar ping21:08
stevemaredmondsw: hey dude21:08
stevemaredmondsw: i wanted your take on https://bugs.launchpad.net/oslo.policy/+bug/154768421:09
openstackLaunchpad bug 1547684 in oslo.policy "Attribute error on Token object when using domain scoped token" [Undecided,New]21:09
edmondswstevemar reading21:09
stevemaredmondsw: seems like anyone using v3 policy (the way we have it written) won't be able to actually use it21:09
edmondsw:) doesn't surprise me21:09
stevemaredmondsw: here's a script to re-create the error: https://launchpadlibrarian.net/242578504/policy_token.py21:09
edmondswthat v3cloud policy file has a bunch of issues, largely because it isn't used much so they're not flushed out like they are in the other file21:10
stevemaredmondsw: the main sticking point is: https://github.com/openstack/keystone/blob/master/etc/policy.v3cloudsample.json#L321:10
*** adrian_otto has joined #openstack-keystone21:10
stevemaredmondsw: the "token.is_admin_project:True" bit in particular21:10
edmondswI think I have some notes around here somewhere of some issues that I meant to fix but never have gotten around to... and that's just a few that I found, wouldn't be comprehensive21:10
edmondswhmmm21:12
edmondswthe issues I'd seen weren't related to that21:12
stevemaredmondsw: is this just a matter of needing "target:" in front of that bit?21:12
edmondswI think that should be "is_admin_project", not "token.is_admin_project" ?21:13
stevemaredmondsw: ? but that's not defined anywhere no?21:16
stevemarunless we dumped that into context21:16
stevemari think we did21:16
edmondswI think we did21:16
edmondswe.g. https://review.openstack.org/#/c/384655/2/etc/policy.json21:17
*** jaugustine has quit IRC21:19
openstackgerritOpenStack Proposal Bot proposed openstack/keystonemiddleware: Updated from global requirements  https://review.openstack.org/41150521:22
edmondswstevemar, that help?21:24
stevemaredmondsw: so you're saying we've shipped a fault policy file (granted not the default one) for two releases in a row, cause of a typo?21:24
stevemarffs21:24
* stevemar throws fish at everyone21:24
gagehugo:(21:24
edmondswstevemar consider it an incentive to merge the policy files <ducks>21:24
stevemaredmondsw: i totally would be down for that21:24
*** ravelar has joined #openstack-keystone21:25
edmondswI think everyone would be down for it... problem is finding someone to do it21:25
* stevemar hands gagehugo a wet wipe21:25
edmondswstevemar did you try removing "token." to see if it worked?21:26
stevemaredmondsw: no, will try soon21:26
stevemardistracted by tv21:26
stevemaredmondsw: short term, we should add a test in keystone that actually tries to load the damn v3 policy21:27
stevemarand enforce things21:27
edmondsw"things" would be a long list, making it hard to add "short term"21:27
edmondswI think dstanek says he's actually using that policy file and it's working for what he's tried21:28
edmondswit just won't work for everything21:28
edmondswhence why I think the best answer is to merge the policy files and look at how well we're testing policy settings in general21:28
edmondswrather than just focus on testing v3cloudpolicy that we want to merge into normal policy and get rid of anyway21:29
stevemari've been thinking we should merge policy files since we're the only project that has 221:29
edmondswhaving 2 was an awful idea to start with21:29
*** ravelar has quit IRC21:29
* edmondsw says without knowing what the reason was21:29
stevemaredmondsw: whatever it is, i'm sure it's not valid any longer21:30
stevemaredmondsw: it predates me21:30
edmondsw++21:31
*** ravelar has joined #openstack-keystone21:36
*** ravelar has quit IRC21:41
*** browne has quit IRC21:53
*** adrian_otto1 has joined #openstack-keystone21:54
*** adrian_otto1 has quit IRC21:54
*** edtubill has quit IRC21:55
*** adrian_otto has quit IRC21:55
*** adrian_otto has joined #openstack-keystone21:58
*** edmondsw has quit IRC21:59
jamielennoxstevemar, edmondsw: thanks for sticking with that allow_expired review22:00
stevemarjamielennox: ++22:00
*** edmondsw_ has joined #openstack-keystone22:02
*** diazjf has quit IRC22:03
*** browne has joined #openstack-keystone22:03
stevemaredmondsw_: OK, successfully recreated the issue22:03
stevemaredmondsw_: sigh... yep22:04
stevemarthat fixed it22:04
*** asettle has quit IRC22:05
*** asettle has joined #openstack-keystone22:06
*** edmondsw_ has quit IRC22:06
*** ayoung has quit IRC22:10
*** asettle has quit IRC22:11
stevemarnow to make a test for it22:12
openstackgerritMerged openstack/keystone: Implement password requirements API  https://review.openstack.org/41051522:42
openstackgerritRon De Rose proposed openstack/keystone: WIP - Add domain_id to the user table  https://review.openstack.org/40987422:46
*** catintheroof has quit IRC22:46
openstackgerritRon De Rose proposed openstack/keystone: WIP - Add domain_id to the user table  https://review.openstack.org/40987422:51
*** browne has quit IRC22:52
openstackgerritRon De Rose proposed openstack/keystone: WIP - Add domain_id to the user table  https://review.openstack.org/40987422:56
*** phalmos_ has quit IRC23:00
*** mvk has joined #openstack-keystone23:03
*** dave-mccowan has quit IRC23:04
*** asettle has joined #openstack-keystone23:07
david-lylecrinkle, stevemar, I added some feedback to https://review.openstack.org/389337 I think I've unfortunately increases the scope of the bug fix more than I should have. let's fix the bug first, then support multi-domain role assignments later.23:08
david-lyle*increased23:08
david-lyleI think going back to patch 4 while retaining the bug-id is probably the best way forward for right now23:08
david-lylewell scope wise, the fixes in patch 5 should remain23:10
*** asettle has quit IRC23:11
*** markvoelker has quit IRC23:13
*** ngupta_ has quit IRC23:16
*** ngupta has joined #openstack-keystone23:17
*** catintheroof has joined #openstack-keystone23:17
*** catintheroof has quit IRC23:17
*** catintheroof has joined #openstack-keystone23:18
*** ngupta has quit IRC23:21
*** itisha has quit IRC23:22
openstackgerritMerged openstack/keystonemiddleware: Updated from global requirements  https://review.openstack.org/41150523:23
*** ayoung has joined #openstack-keystone23:29
*** ChanServ sets mode: +v ayoung23:29
*** gyee has quit IRC23:36
*** jamielennox is now known as jamielennox|away23:46
*** edmondsw has joined #openstack-keystone23:47
*** jamielennox|away is now known as jamielennox23:50
*** edmondsw has quit IRC23:51
*** dave-mccowan has joined #openstack-keystone23:55
*** adrian_otto has quit IRC23:57
*** harlowja has joined #openstack-keystone23:58

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