Monday, 2014-06-16

*** oomichi has joined #openstack-keystone00:06
*** dstanek_zzz is now known as dstanek00:08
*** dstanek is now known as dstanek_zzz00:18
*** xianghui has joined #openstack-keystone00:19
*** diegows has joined #openstack-keystone00:30
*** nsquare has joined #openstack-keystone00:47
*** hrybacki has joined #openstack-keystone00:49
*** dstanek_zzz is now known as dstanek01:09
*** mberlin has joined #openstack-keystone01:14
*** mberlin1 has quit IRC01:17
*** diegows has quit IRC01:17
*** hrybacki has quit IRC01:18
*** dstanek is now known as dstanek_zzz01:19
*** xianghui has quit IRC01:27
ayoungjamielennox, https://review.openstack.org/#/c/81166/  really could stand to get mergered01:55
* morganfainberg ponders...01:55
morganfainbergbook flights... review/merge code01:55
jamielennoxayoung: yea, it's a beast - i've gotten part way through reviews a couple of times01:55
ayoung++01:56
* morganfainberg weighs options01:56
morganfainbergor dinner.01:56
ayoungmorganfainberg, dinner, book flights, review code.01:56
ayoungKeep your priorities straight01:56
morganfainbergayoung, well, that means i need to pick what to eat! :P01:56
morganfainberg>.>01:56
morganfainbergooh i think i have a gift card for roys... that would be close/easy01:57
*** zhiyan_ is now known as zhiyan02:00
morganfainbergooh $2002:00
morganfainbergyeah totally doing that for dinner :P02:01
*** dstanek_zzz is now known as dstanek02:09
*** zhiyan is now known as zhiyan_02:18
*** dstanek is now known as dstanek_zzz02:19
*** praneshp_ has joined #openstack-keystone02:24
*** rodrigods has joined #openstack-keystone02:25
*** praneshp has quit IRC02:26
*** praneshp_ is now known as praneshp02:26
*** zhiyan_ is now known as zhiyan02:27
openstackgerritRodrigo Duarte Sousa proposed a change to openstack/python-keystoneclient: Add an example script for role_assignments module  https://review.openstack.org/9760002:30
*** rodrigods has quit IRC02:35
*** lbragstad has joined #openstack-keystone02:53
*** dims has quit IRC02:57
*** ncoghlan has joined #openstack-keystone03:02
openstackgerritayoung proposed a change to openstack/keystone: Default to PKIZ tokens  https://review.openstack.org/9889703:06
openstackgerritayoung proposed a change to openstack/keystone: Allow for multiple PKI Style Providers  https://review.openstack.org/9884503:07
*** dstanek_zzz is now known as dstanek03:10
*** diegows has joined #openstack-keystone03:20
*** dstanek is now known as dstanek_zzz03:20
*** diegows has quit IRC03:29
*** stevemar has joined #openstack-keystone03:47
*** nsquare has quit IRC03:50
*** ncoghlan is now known as ncoghlan_afk04:01
*** xianghui has joined #openstack-keystone04:02
*** morganfainberg has quit IRC04:04
*** morganfainberg has joined #openstack-keystone04:04
*** morganfainberg has quit IRC04:05
*** morganfainberg has joined #openstack-keystone04:06
*** dstanek_zzz is now known as dstanek04:11
*** dstanek is now known as dstanek_zzz04:21
*** dims has joined #openstack-keystone04:26
*** xianghui has quit IRC04:30
*** dims has quit IRC04:30
*** xianghui has joined #openstack-keystone04:35
*** dims has joined #openstack-keystone04:46
*** dims has quit IRC04:51
*** dstanek_zzz is now known as dstanek05:12
*** gpocentek has joined #openstack-keystone05:16
*** dstanek is now known as dstanek_zzz05:22
*** ajayaa has joined #openstack-keystone05:22
*** ncoghlan_afk is now known as ncoghlan05:26
openstackgerritSteve Martinelli proposed a change to openstack/keystone: Adds a newline for pep8 compliance  https://review.openstack.org/9941805:28
*** nsquare has joined #openstack-keystone05:42
*** dims has joined #openstack-keystone05:47
*** dims has quit IRC05:51
*** zhiyan is now known as zhiyan_05:55
*** zhiyan_ is now known as zhiyan05:56
openstackgerritOpenStack Proposal Bot proposed a change to openstack/keystone: Imported Translations from Transifex  https://review.openstack.org/9700506:00
*** dstanek_zzz is now known as dstanek06:12
openstackgerritSteve Martinelli proposed a change to openstack/python-keystoneclient: Update keystoneclient code to account for hacking 0.9.2  https://review.openstack.org/10015206:17
*** henrynash has joined #openstack-keystone06:18
*** dstanek is now known as dstanek_zzz06:22
openstackgerritSteve Martinelli proposed a change to openstack/keystone: Update sample keystone.conf file  https://review.openstack.org/10015506:25
*** stevemar has quit IRC06:37
*** dims has joined #openstack-keystone06:48
*** dims has quit IRC06:52
*** marekd|away is now known as marekd06:58
*** chandan_kumar has quit IRC07:05
*** BAKfr has joined #openstack-keystone07:09
*** dstanek_zzz is now known as dstanek07:13
*** ncoghlan has quit IRC07:17
*** dstanek is now known as dstanek_zzz07:23
*** einarf has joined #openstack-keystone07:24
*** nsquare has quit IRC07:30
*** leseb has joined #openstack-keystone07:37
*** leseb has quit IRC07:47
*** afazekas_ has joined #openstack-keystone07:48
*** dims has joined #openstack-keystone07:49
*** dims has quit IRC07:53
*** leseb has joined #openstack-keystone07:59
*** einarf has quit IRC08:00
*** xianghui has quit IRC08:05
*** xianghui has joined #openstack-keystone08:05
*** dstanek_zzz is now known as dstanek08:14
*** jaosorior has joined #openstack-keystone08:14
*** xianghui has quit IRC08:14
*** dstanek is now known as dstanek_zzz08:24
*** xianghui has joined #openstack-keystone08:28
*** mberlin1 has joined #openstack-keystone08:29
*** mberlin has quit IRC08:29
*** henrynash has quit IRC08:36
*** mberlin1 has quit IRC08:36
*** mberlin has joined #openstack-keystone08:38
*** mberlin has quit IRC08:42
*** mberlin has joined #openstack-keystone08:42
*** dims has joined #openstack-keystone08:49
*** henrynash has joined #openstack-keystone08:50
*** dims has quit IRC08:54
*** zhiyan is now known as zhiyan_08:56
*** henrynash has quit IRC08:57
*** dstanek_zzz is now known as dstanek09:15
*** dstanek is now known as dstanek_zzz09:25
*** jamielennox is now known as jamielennox|away09:29
*** praneshp has quit IRC09:30
openstackgerritOpenStack Proposal Bot proposed a change to openstack/keystone: Updated from global requirements  https://review.openstack.org/9907609:48
*** dims has joined #openstack-keystone09:50
*** luisbg has quit IRC09:50
openstackgerritOpenStack Proposal Bot proposed a change to openstack/python-keystoneclient: Updated from global requirements  https://review.openstack.org/9626509:52
*** dims has quit IRC09:54
*** rodrigods has joined #openstack-keystone10:03
*** leseb has quit IRC10:04
*** leseb has joined #openstack-keystone10:05
*** openstackgerrit has quit IRC10:06
*** openstackgerrit has joined #openstack-keystone10:06
*** leseb has quit IRC10:09
*** dstanek_zzz is now known as dstanek10:16
*** ajayaa has quit IRC10:18
*** dstanek is now known as dstanek_zzz10:26
*** openstackgerrit has quit IRC10:35
*** openstackgerrit has joined #openstack-keystone10:35
*** leseb has joined #openstack-keystone10:38
*** leseb has quit IRC10:44
*** dims_ has joined #openstack-keystone10:51
*** dims_ has quit IRC10:55
*** xianghui has quit IRC10:59
*** dstanek_zzz is now known as dstanek11:16
*** dims_ has joined #openstack-keystone11:18
*** leseb has joined #openstack-keystone11:23
*** dstanek is now known as dstanek_zzz11:26
*** rodrigods has quit IRC11:28
*** ajayaa has joined #openstack-keystone11:32
*** hrybacki has joined #openstack-keystone11:47
*** hrybacki has quit IRC11:47
*** hrybacki has joined #openstack-keystone11:47
*** lbragstad has quit IRC11:48
*** diegows has joined #openstack-keystone11:52
*** juanmo has joined #openstack-keystone11:59
*** rodrigods has joined #openstack-keystone12:04
*** dstanek_zzz is now known as dstanek12:17
*** morganfainberg has quit IRC12:18
*** morganfainberg has joined #openstack-keystone12:19
*** erecio has joined #openstack-keystone12:21
*** raildo has joined #openstack-keystone12:33
*** zhiyan_ is now known as zhiyan12:44
openstackgerritHarry Rybacki proposed a change to openstack/python-keystoneclient: check revocation by events in auth_token middleware  https://review.openstack.org/9975112:47
*** henrynash has joined #openstack-keystone12:48
*** mberlin has quit IRC12:50
*** mberlin has joined #openstack-keystone13:02
*** gordc has joined #openstack-keystone13:05
*** ajayaa has quit IRC13:05
*** lbragstad has joined #openstack-keystone13:08
*** dims_ has quit IRC13:10
*** dims_ has joined #openstack-keystone13:10
*** dims_ has quit IRC13:11
dstanekayoung: have you taken a look at https://review.openstack.org/#/c/99908/2/specs/juno/trusts-redelegation.rst yet?13:11
*** dims has joined #openstack-keystone13:12
*** joesavak has joined #openstack-keystone13:12
*** richm has joined #openstack-keystone13:15
ayoungdstanek, no, not yet13:19
dstanekayoung: i think maybe a slightly different take on some of the service scoping we were talkig about at the summit13:20
ayoungdstanek, on the redelegation spec?13:21
joesavakyo Marekd! Thanks for the review. : )13:22
marekdjoesavak: hello!13:22
joesavakmarekd - i'm a little confused by your mapping comment13:23
ayounghrybacki, so for py3313:23
joesavakare you wondering why mappings should exist for sp federation?13:23
ayoungrun tox -e py33 and you will see the errors13:23
joesavakmarekd: https://review.openstack.org/#/c/100023/3/specs/juno/keystone-to-keystone-federation.rst line 29613:23
dstanekayoung: the usecase if user trusts a service; then later a that trusted token has to be used by the service to talk to another serivce13:23
ayounghrybacki, looking at what you have in the past review, I am not sure why the test fail, but it might be the string comparisons are no longer between objects of the same type13:24
marekdjoesavak: no, we already have them at the SP side (starting from Icehouse), so given the fact we are now focusing on Keystone being an IdP what do you want map there? Shouldn't Keystone-IdP issue an assertion (like SAML assertion)?13:24
hrybackiayoung: nods -- on it13:24
dstanekayoung, hrybacki: let me know if you need a third pair of eyes for the Py3 stuff13:25
ayounghrybacki, cool.  drive on, and there are lots of smart pythonistas in here if you come across a roadblock;13:25
joesavakmarekd - yes keystone should issue an assertion for the service provider federation, but having the mapping there sets us up in a better spot should the service provider not be keystone13:25
ayounglike dstanek13:25
dstaneksome of our deps (new versions maybe?) seem to be broken on Py3 because they don't install - that's on my todo list for today13:26
marekdjoesavak: ah, ok.13:26
joesavakfor example - the ticketing use case where i'm using a vendor provided "ticketing as a service". I want to provide that ticketing api in the keystone service catalog (even though it isn't openstack). The ticketing system may require "e-mail" and "f-lname" as attrs but keystone knows that as "email" and "username"13:26
*** nkinder has joined #openstack-keystone13:26
joesavaki'd either have to place that requirement on the various service providers we will integrate with or allow that mapping to be part of keystone itself13:27
marekdjoesavak: yes yes, makes sense now.13:27
joesavakmarekd - excellent - I'll review the other comments too and reply via review. : )13:27
marekdjoesavak: do you want (in general) Keystone-IdP to issue real SAML2 assertions?13:29
joesavakmarekd - yes. : ) Or whichever federation protocol we deem best for this use case13:29
joesavakas long as it's a standard protocol. A lot of integrators speak SAML2 and OpenID connect.13:30
marekdjoesavak: I am sometimes still confused why not leave that IdPness to something that's a real IdP13:30
marekdi can feel how the user experience will be...get one token, go somewhere else and magicaly use that remote cloud.13:31
joesavakmarekd - can you expand on that... IdPness meaning credential store?13:33
hrybackianyone run into issues getting pycrypto on F20?13:34
marekdjoesavak: in general, since you want Keystone to issue a SAML2 assertion (or whatever protocol), why not leave that to a dedicated software that does that - Shibboleth, M$ ADFS  and so on...13:34
marekdjoesavak: in the end we will need to play on the SAML rules (handle redirections, keep the specified format) and we will want to integrate with an external world.13:35
joesavakSure - it could be like how we implemented mod_shib for accppeitng SAML assertions - as long as there's a method to do the token-to-Federation-workflow, I think we're fine13:36
marekdjoesavak: token-to-Federation means that local token later to be used for a remote cloud, right?13:38
joesavakright13:40
joesavakwait..13:40
joesavakit means a token to a remote cloud for an identity that doesn't exist locally, but it was issued from a trusted identity provider.13:40
joesavakso the remove cloud keysotne initiaties the federation workflow (SAML request) to the trusted identity provider13:41
joesavakremote*13:41
marekdjoesavak: which doesn't need to be a Keysone.13:41
joesavakright13:42
marekdok, so this is what's happening today, correct?13:42
joesavakpartially13:42
joesavakthere are pieces missing - we have the ability to accept a saml response and generate a token for it for it13:43
marekdcorrect.13:43
joesavakwe don't have the ability for keystone to accept a non-local token, parse the trust, and intiate the federation workflow13:43
joesavakwe also don't have the ability for that token scope to contain multiple clouds (local and remote)13:43
marekdjoesavak: the former: correct, but I don't know if that's really necessary, latter: I am not 100% sure this is what we should do.13:44
marekdjoesavak: why not do something like that: enrich service katalog with federated keystones, so client knows who is where.13:45
*** gabriel-bezerra has quit IRC13:45
marekdnow, he needs to go to a remote keystone and use what we have already and authenticate itself via SAML/openid13:45
joesavakyeah - that's the problem from my standpoint - I'm putting the requirement to speak federation protocol on the client13:46
joesavakthere's a lot of public cloud customers used to their user/pass13:46
joesavakand they don't have ( and don't want) a clue about federation protocols. ; )13:47
marekdjoesavak: okay.13:48
joesavakAlso, they are old mom&pop shops who had a contractor setup their public cloud account. Asking them to update a client would be like speaking klingon to them.13:48
marekdjoesavak: i am just fearing we may end up doing some wild hacks on top of federated protocols.13:49
marekdjoesavak: haha ++13:49
joesavaki'm hoping no wild hacks. We have time to do this right and the expertise too! : )13:49
marekdfor sure more experience13:50
joesavakalrighty marekd, I'll update the review today! Off to get more coffee. Later. : )13:52
marekdjoesavak: hehe, cheers!13:52
marekdjoesavak: thanks!13:52
*** radez_g0n3 is now known as radez13:53
openstackgerritayoung proposed a change to openstack/keystone: Default to PKIZ tokens  https://review.openstack.org/9889713:55
morganfainbergayoung, dolphm, what are your thoughts on getting one of the tempest runs to use UUID tokens -- you know until we really remove them? there are a lot of people who continue to use them.14:01
ayoungmorganfainberg, I think it is a step in the wrong direction, but won't block.14:01
morganfainbergayoung, i agree its not the way i want to see things go, but if we're legitimately not deprecating UUID (yet) we should probably gate on it more than just our unit tests.14:03
ayoungmorganfainberg, so lets deprecate it14:03
morganfainbergayoung, lets get compressed tokens in. and get apache running clean for tempest then look to deprecating it. I think that is a reasonable target14:04
morganfainbergayoung, if we can't deprecate then, we can see if we want to gate.14:04
ayoungmorganfainberg, I'm workoing on compressed tokens now14:04
morganfainbergayoung, i know you are. thats why I think we should get that in before deciding :) should be in soon14:05
hrybackianyone ever seen -- ERROR: InvocationError: '/opt/stack/python-keystoneclient/.tox/py33/bin/python setup.py testr --testr-args=' -- when trying to run the Python 3 tox tests?14:06
*** stevemar has joined #openstack-keystone14:10
*** dhellmann has quit IRC14:12
*** dhellmann has joined #openstack-keystone14:13
ayounghrybacki, tox is touchy14:13
ayoungyou can rebuild the env with -r14:13
ayoungif you ran tox before, you might have one that is somehow out of date.14:13
ayoung-r takes a while to run,14:14
ayoungso plan according14:14
ayoungly14:14
*** afazekas_ has quit IRC14:16
morganfainbergayoung, +2 on the different pki provider types. just want to confirm with gyee that his comment is addressed (it looks like it has been)14:17
ayoungYeah14:17
hrybackiayoung: nods -- tried that too. Fails the same call to setup.py -- 'db type could not be determined'14:17
ayounghrybacki, no longer stack trace?  If you have one, fpaste it14:18
*** nsquare has joined #openstack-keystone14:18
hrybackinot much more -- http://fpaste.org/110164/14029283/14:19
hrybackithe tox.ini file has 'commands = python setup.py testr --testr-args='{posargs}'' -- which I'm assuming is the command it failed on -- digging for the posargs stuff now14:20
openstackgerritLance Bragstad proposed a change to openstack/identity-api: Cleanup region V3 documentation  https://review.openstack.org/9852014:23
openstackgerritDirk Mueller proposed a change to openstack/python-keystoneclient: Adjust Python 2.6 OSerror-on-EPIPE workaround  https://review.openstack.org/9680514:24
hrybackiayoung: I see you ran into the same problem but, the file you talk about removing toward the bottom is nonexistant in my repo14:27
*** ChanServ sets mode: +o morganfainberg14:28
*** morganfainberg changes topic to "Please review Keystone Specs: https://review.openstack.org/#/q/status:open+project:openstack/keystone-specs,n,z"14:28
*** rwsu has joined #openstack-keystone14:29
ayounghrybacki, I got it, too14:35
ayoungbut I think mine is legit...need to rebase14:35
*** chandan_kumar has joined #openstack-keystone14:36
marekdjoesavak: still here?14:39
*** mberlin has quit IRC14:43
dstanekwha? https://wikis.forgerock.org/confluence/display/openam/OpenStack's+Keystone+integration+with+OpenAM14:51
*** devlaps has joined #openstack-keystone14:52
dstanekhrybacki: you may need to clean pycs, the py3 caches, etc. - i usually use 'git clean', but that will destroy anything not committed14:52
marekddstanek: where did you get this link?14:53
*** mberlin has joined #openstack-keystone14:54
dstanekmarekd: i was just search for some alternate implementations of token trusts14:54
dstaneks/search/searching/14:54
*** sbfox has joined #openstack-keystone14:57
marekddstanek: BTW, appreciate your eyes on that: https://review.openstack.org/#/c/92166/ and https://review.openstack.org/#/c/99704/ :-)14:58
*** gordc1 has joined #openstack-keystone14:59
morganfainbergdevlaps, coffee today sometime?14:59
*** leseb has quit IRC14:59
*** leseb_ has joined #openstack-keystone14:59
*** gordc has quit IRC15:00
dstanekmorganfainberg: you should have coffee everyday!15:01
morganfainbergdstanek, lol but devlaps is local, so i can bug him in person vs. just over IRC15:01
*** gordc1 is now known as gordc15:02
devlapsmorganfainberg: coffee sounds good!15:02
dstanekmorganfainberg: are you staying where you are or will you be moving?15:04
dstanekmarekd: any chance in getting _AuthConstructor renamed to AuthConstructor?15:04
morganfainbergdstanek, as of right now? staying here. but lease is up in oct15:05
morganfainbergdstanek, no idea after that15:05
marekddstanek: i think it's out of the scope of this patch...15:05
marekdi can prepare another one and make it a dependency.15:05
marekd_AuthConstructor sits in v3.py file.15:05
marekddstanek: makes sense?15:05
dstanekmarekd: if you do that i would put it first as a change to support building on top of it15:06
marekddstanek: right, I will propose a patch.15:06
*** Guest8031 is now known as mgagne15:08
*** mgagne has joined #openstack-keystone15:08
dstanekmarekd: in https://review.openstack.org/#/c/92166/24/keystoneclient/contrib/auth/v3/saml2.py do you plan on subclassing Saml2UnscopedToken and having the subclass not require username and password?15:09
marekddstanek: i was more thinging about another plugin system that handles different authn methods against IdP.15:10
hrybackiayoung, dstanek: no changes between this mornings patch and now -- I ran a git clean -f and I'm running tox -r now15:12
dstanekmarekd: hmm...then i'm not sure why you can't use username and password as kwargs instead of pulling them out of the kwargs dict15:15
dstanekwe over use kwargs all over the palce15:15
dstanekerr...place15:15
hrybackidstanek: still fails -- any other ideas?15:15
dstanekhrybacki: you're trying this on the client right?15:15
hrybackiyep15:16
dstanekanything in your pip.log?15:17
dstanekah wait. it seems you can create the venv, but it's the tests that won't run15:18
hrybackiyeah15:18
hrybackiakin to this https://bugs.launchpad.net/testrepository/+bug/122944515:18
uvirtbotLaunchpad bug 1229445 in testrepository "db type could not be determined (dup-of: 1212909)" [High,Triaged]15:18
uvirtbotLaunchpad bug 1212909 in testrepository "ImportError _bsddb with deadsnakes python2.6 anydbm" [Critical,Triaged]15:18
hrybackibut I don't have that file15:18
dstanekyeah, the clean would have removed it15:19
dstanekdo you have nose installed?15:19
hrybackiyeah -- I can run the py27 tests without any issue15:19
dstanektestr works fine when it works, but i find it impossible to debug15:19
dstaneknose always works great15:19
hrybackihrm15:20
dstanekhrybacki: are you on master or a branch?15:20
hrybackialso -- I found that file ... ayoung -- your tox cheatsheet docs are wrong15:20
hrybackiI tried on both15:20
hrybackirm .tox/.testrepository/time.dbm -> ../.testrepository/time.dbm15:21
dstanekmaster works fine for me15:21
marekddstanek: so make  function signature with username, password explicitely specified?15:22
marekddstanek: I personally don't have an isue with that. What's the convention? What should be, in general, stored inside kwargs dict and what should be specified explicitely?15:23
dstanekmarekd: yeah, and then you can document in the doc string15:23
dstanekmarekd: actually username and password are required by your class, they are not actually optional15:24
dstanekmarekd: nm, i thought you were popping15:24
hrybackidstanek, ayoung++ got it thanks! it was the aforementioned launchpad bug. Peculiar.15:28
dstanekhrybacki: testr does so much magic that it's often hard to debug15:28
hrybackinoted -- how do you use nose with tox?15:29
hrybackior do you just use nose for dev and let jenkins do the testr stuff?15:29
morganfainbergstevemar, ping15:29
dstanekonce tox creates my venv i install nose into it: .tox/py27/bin/pip install nose15:29
morganfainbergstevemar, re the keystone-to-keystone federation15:29
dstanekthen run nose from it .tox/py27/bin/nosetests15:29
hrybackidstanek++ thanks, I'll give that a try15:30
morganfainbergjoesavak, actually you might be able to answer the question for me15:30
morganfainbergjoesavak, is there a reason not to just make keystone able to be a SAML provider instead of the extra mechanisms outlined in https://review.openstack.org/#/c/100023/3 ? we already support SAML (sortof), it would be relatively easy to make keystone-to-keystone federation work with it.15:32
morganfainbergcc marekd, ^ question i asked joesavak15:32
dstanekmarekd: uggg... looking at the use of _method_params now :-(  - everytime __init__ is called a kitten dies15:32
dstanekhrybacki: i usually only do that to debug when tox isn't helpful15:32
dstaneki try sticking to tox/testr because that is what everyone else does15:33
stevemarmorganfainberg, you mean all the new SP apis?15:33
morganfainbergstevemar, well sortof15:33
morganfainbergstevemar, it doesn't hurt to have an "OK allow sending SAML assertions to XYZ" but it reads as if we're doing exactly what I was hoping we wouldn't do...15:34
morganfainbergmake our own protocol up15:34
marekdmorganfainberg: JOe wants to reuse protocols.15:34
joesavakback ! : )15:34
joesavakright on - i want it extensible to support standard protocols15:35
morganfainbergjoesavak, ++ ok i just didn't get that in the initial read-through15:35
joesavakSAML2 would be great but the spec is written from the standpoint that openID connect can be added later (or any fed protocol)15:35
joesavakWhoops - I'll take a look again15:35
morganfainbergjoesavak, i think i might just not be comprehending it clearly15:36
joesavakDon't want to give the "we want to re-invent the wheel" impression with this15:36
*** sbfox has quit IRC15:36
morganfainbergjoesavak, yeah thats my concern.15:36
*** sbfox has joined #openstack-keystone15:36
marekddstanek: you mean because _method_params are empty?15:36
*** daneyon has joined #openstack-keystone15:36
morganfainbergjoesavak, it might be the "knowledge" of endpoints and services of the trusted sps15:37
morganfainbergjoesavak, i don't know how you could ever hope to keep that in sync.15:38
joesavakand it shouldn't be expected to be near-real-time-sync15:38
joesavakprobably daily15:38
marekdmorganfainberg: that's my concern too. Pooling of endpoints across remote clouds I guess...15:38
morganfainbergjoesavak, i don't think that's even reasonable.15:38
*** afazekas_ has joined #openstack-keystone15:38
morganfainbergjoesavak, it sounds like internal keystone is issuing a token for external cloud15:39
joesavakbut this is the case where i want to build token scope quickly and i want to give clients the option of using a token across multiple clouds15:39
morganfainbergjoesavak, ?15:39
joesavakyes - a single token for authorized access across multiple clouds15:39
morganfainbergjoesavak, i see massive security concerns here.15:39
morganfainbergjoesavak, and a lot of extra code to mitigate it15:40
morganfainbergjoesavak, external cloud needs to trust what the internal cloud says then. this is a bad trust relationship. how do you know the internal cloud isn't compromised and issuing bad data.15:41
morganfainbergespecially when it comes to scope15:41
morganfainberginternal cloud could issue a token for some totally unrelated project/domain and we'd need to verify that is allowed on the external front.15:42
joesavakExternal cloud (CSP) has internal cloud as a trusted identity provider. Internal cloud has external cloud as a trusted service provider15:42
joesavakboth have mappings related to it to help limit scope of access as well15:42
morganfainbergthe way i read that, you would auth against external cloud then.15:42
morganfainbergand it would use (e.g. SAML) to get the identity from internal cloud15:43
morganfainbergnot auth against internal cloud and get a token for external cloud15:43
joesavakif you have a provisioned (non-ephmeral) identity on the external cloud you can auth there first, y es15:43
morganfainbergjoesavak, i think the external cloud needs to be far more paranoid than you're allowing it to be15:43
morganfainbergthe external cloud should be the only place that ever issues a token for the external cloud (or something under it's purveiw)15:44
morganfainberginternal cloud can only ever provide identity information - nothing else.15:44
morganfainbergauthn vs authz15:44
openstackgerritKristy Siu proposed a change to openstack/keystone-specs: Trusted Attributes Policy for External Identity Providers  https://review.openstack.org/10027915:44
joesavakwhile the token scope includes external cloud endpoints, the external cloud keysotne will still verify token validity agianst the issuing identity provider15:45
openstackgerritKristy Siu proposed a change to openstack/keystone-specs: Simplified Mapping for Federated Authentication  https://review.openstack.org/10028015:45
morganfainbergjoesavak, so external cloud gets the token, then verifies it against the internal cloud's keystone?15:45
joesavakYes15:45
morganfainbergjoesavak, so internal cloud is compromised15:46
morganfainbergjoesavak, it blindly says token is ok15:46
morganfainbergexternal cloud is now compromised15:46
joesavakexternal cloud is compromised for that tenant scope only as defined by the mapping15:46
morganfainbergjoesavak, and this is where it feels like a custom protocol15:47
joesavakjust as though a user's user/pass was compromised15:47
morganfainbergjoesavak, this isn't re-using federation technology, it's using the keystone tokens as the protocol15:47
joesavakit's using federation technology under the covers of keytone to keystone communication to obfuscate that complexity from the client15:48
marekdjoesavak: but usually the client is somehow involved in the workflow :(15:49
morganfainbergmarekd, ++15:50
openstackgerritKristy Siu proposed a change to openstack/keystone-specs: Trusted Attributes Policy for External Identity Providers  https://review.openstack.org/10027915:50
joesavakthe client is involved in the auth, yes -  but most keystone clients are coded to send in user/pass or user/api-key today15:50
morganfainbergjoesavak, alternatively keystone could provide identity information to another cloud, via SAML, OpenID, whatever15:51
marekdjoesavak: I cimpletely understand your rationale behind that and I completely like it - scalable clouds!15:51
morganfainbergjoesavak, and you request the token from the external keystone.15:51
joesavakmorganfainberg - yes -t hat is what keystone-to-keysotne federation should be15:51
openstackgerritKristy Siu proposed a change to openstack/keystone-specs: Trusted Attributes Policy for External Identity Providers  https://review.openstack.org/10027915:51
marekdjoesavak: but external keystone would have to impersonate a user.15:51
*** zhiyan is now known as zhiyan_15:52
joesavakexternal keystone would setup an ephemeral identity just like any other federatied identity.15:52
joesavakno imperosnation needed15:52
*** bearhands is now known as comstud15:53
marekdjoesavak: kind of, external keystone would have to initiate workflow on behalf of the user, and usually it's something what's client is doing.15:54
marekdwell, this could be done somehow by mixing federation and some token sending/receiving.15:55
joesavakyes, agree - at that point it is acting on behalf of an identity using the trust defined by both clouds to authorize requested access to the external cloud15:55
*** dstanek is now known as dstanek_zzz15:55
joesavakFYI - jorgew will be online at 3:30p to talk through some of this too15:56
morganfainbergjoesavak, 3:30p which timezone? :)15:56
joesavak3:30p central. lol15:56
morganfainbergjoesavak, because this really feels like the whole process is inverted15:56
marekdjoesavak: did he have any comments regarding this? :-)15:56
joesavakmarekd - i'll copy/paste and send via email15:56
marekdjoesavak: thanks dude!15:56
joesavakhe was running to a meeting - but didn't have much to add yet15:57
stevemarjoesavak, send to wider email list :)15:57
marekdjoesavak: i really love the business usecase, seriously! Just want to make it right :-)15:57
joesavaksure15:57
joesavakme too! : )15:57
morganfainbergjoesavak, usually user would have external keystone issue the token (authz), but via SAML or OpenID the authn part would occur.15:57
*** dstanek_zzz is now known as dstanek15:57
*** sbfox has quit IRC15:58
*** sbfox has joined #openstack-keystone15:58
morganfainbergjoesavak, anyway.yeah lets get a clear picture. i really want this use case to work. but i have concerns with the current proposal15:59
stevemarmorganfainberg, is there a library we could depend on that is py3 compatible - for issuing SAML tokens?15:59
morganfainbergstevemar, is pysaml2 compativle15:59
morganfainberg?15:59
joesavakmorgan - souonds good.15:59
morganfainbergok i need coffee and breakfast :P16:00
lbragstadmorganfainberg: coffee for breakfast?16:01
morganfainberglbragstad, i've done that before :(16:01
stevemarmorganfainberg, yes, go eat bfast!16:01
marekdlbragstad: pretty standard thing...16:01
morganfainbergit doesn't end well16:01
lbragstadmorganfainberg: strong coffee on an empty stomach == getting lots done16:01
lbragstad:)16:01
morganfainberglbragstad, lol negative.16:02
*** leseb_ has quit IRC16:04
*** sbfox1 has joined #openstack-keystone16:04
*** afazekas_ has quit IRC16:06
*** sbfox has quit IRC16:08
*** jaosorior has quit IRC16:12
*** BAKfr has quit IRC16:18
*** marcoemorais has joined #openstack-keystone16:20
*** gyee has joined #openstack-keystone16:26
*** gordc has quit IRC16:29
*** gordc1 has joined #openstack-keystone16:29
*** gordc1 is now known as gordc16:29
*** Ju_ has quit IRC16:31
*** nsquare has quit IRC16:33
*** marcoemorais has quit IRC16:33
*** marcoemorais has joined #openstack-keystone16:33
*** marcoemorais has quit IRC16:33
*** marcoemorais has joined #openstack-keystone16:34
openstackgerritDavid Stanek proposed a change to openstack/keystone: Middleware tests now run under Python3  https://review.openstack.org/9966916:35
openstackgerritDavid Stanek proposed a change to openstack/keystone: Adds a fork of python-ldap for Py3 testing  https://review.openstack.org/9582716:36
openstackgerritDavid Stanek proposed a change to openstack/keystone: Updates Python3 requirements to match Python2  https://review.openstack.org/9582616:36
*** praneshp has joined #openstack-keystone16:36
openstackgerritDavid Stanek proposed a change to openstack/keystone: Ignore broken endpoints in get_catalog  https://review.openstack.org/8152816:41
openstackgerritDavid Stanek proposed a change to openstack/keystone: Fixes catalog URL formatting to never return None  https://review.openstack.org/9998816:41
openstackgerritDavid Stanek proposed a change to openstack/keystone: Updates keystone.catalog.core.format_url tests  https://review.openstack.org/9998716:41
*** sbfox1 has quit IRC16:52
*** dstanek is now known as dstanek_zzz16:53
*** dstanek_zzz is now known as dstanek16:58
*** marcoemorais has quit IRC17:05
*** marcoemorais has joined #openstack-keystone17:05
*** sbfox has joined #openstack-keystone17:05
*** marcoemorais has quit IRC17:05
*** marcoemorais has joined #openstack-keystone17:06
*** marcoemorais has quit IRC17:06
*** marcoemorais has joined #openstack-keystone17:07
*** sbfox has quit IRC17:08
*** sbfox has joined #openstack-keystone17:08
dstanekhenrynash: you around?17:10
*** sbfox1 has joined #openstack-keystone17:11
*** sbfox has quit IRC17:11
*** sbfox1 has quit IRC17:13
*** sbfox has joined #openstack-keystone17:13
*** sbfox1 has joined #openstack-keystone17:14
*** sbfox has quit IRC17:18
*** PritiDesai has joined #openstack-keystone17:18
openstackgerritMorgan Fainberg proposed a change to openstack/keystone-specs: Service Token Composite Authorization Specification  https://review.openstack.org/9631517:21
*** sri has joined #openstack-keystone17:22
*** sri is now known as Guest314217:22
henrynashdstanek: hi17:23
*** nsquare has joined #openstack-keystone17:23
openstackgerritA change was merged to openstack/identity-api: Cleanup region V3 documentation  https://review.openstack.org/9852017:27
*** Guest3142 has left #openstack-keystone17:28
*** sbasam_ has joined #openstack-keystone17:30
*** nsquare has quit IRC17:32
*** leseb has joined #openstack-keystone17:33
dstanekhenrynash: have you done any more work on multi-backend patch?17:33
*** topol has joined #openstack-keystone17:33
sbasam_Hey. I had a couple questions about the version of keystone in Icehouse.17:33
henrynashdstanek: am in the middle of splitting up the patch…hope to post the 1st part tomorrow17:33
sbasam_Are there any docs on how to enable a SAML based IDP online?17:33
dstanekk, i'll wait for that then. i was going up update the existing patch to include my nit patches.17:34
*** richm has quit IRC17:34
dstaneknow that we are not in a hurry to merge it i would rather they just be a part of the original commit17:34
*** sbfox1 has quit IRC17:35
*** sbfox has joined #openstack-keystone17:35
henrynashoh…OK…17:35
henrynashdstanek: I’d like that too…less work to split up!17:36
*** nsquare has joined #openstack-keystone17:36
henrynashI’ll post that maybe late tonight…and then we can see if others think it’s Ok as one big patch17:37
dstanekhenrynash: if need by i can help in splitting it up - i started to do that so that i would understand it better17:39
henrynashdstanek: ok, thx!17:39
*** ChanServ changes topic to "J1 Milestone June 12th! J2 and beyond blueprints require a formalized spec doc: https://git.openstack.org/cgit/openstack/keystone-specs | Please review the proposed specs."17:39
openstackgerritMorgan Fainberg proposed a change to openstack/keystone-specs: create python-keystonemiddleware repo  https://review.openstack.org/9598717:41
rodrigodswhat's the better approach to discuss a new feature? propose a spec and wait for reviews or send it to ml?17:42
dstanekrodrigods: can you give a real short summary of the feature?17:43
morganfainbergdstanek, i think https://review.openstack.org/#/c/95957/ is ready to go17:43
openstackgerritMorgan Fainberg proposed a change to openstack/keystone-specs: Remove template from juno approved specs  https://review.openstack.org/10031017:44
rodrigodsdstanek, yeah... the idea is to add a endpoint to keystone api, where other services could use it to do domain related auth checking17:45
dstanekmorganfainberg: ha, i was just looking at that17:45
*** leseb has quit IRC17:46
morganfainbergdstanek, ++ awesome17:46
*** richm has joined #openstack-keystone17:47
*** leseb has joined #openstack-keystone17:47
*** jaosorior has joined #openstack-keystone17:47
*** leseb has quit IRC17:51
rodrigodsdstanek, see if you can understand it: http://paste.openstack.org/show/84199/ =)17:51
rodrigodsdstanek, if it makes sense =)17:51
*** dims has quit IRC17:53
*** leseb has joined #openstack-keystone17:53
*** dims has joined #openstack-keystone17:54
*** browne has joined #openstack-keystone17:54
dstanekrodrigods: what kind of rules do you anticipate having?17:55
*** marcoemorais has quit IRC17:58
*** marcoemorais has joined #openstack-keystone17:58
*** marcoemorais has quit IRC17:58
*** marcoemorais has joined #openstack-keystone17:58
*** marcoemorais has quit IRC18:03
*** marcoemorais has joined #openstack-keystone18:03
*** harlowja has joined #openstack-keystone18:05
*** thedodd has joined #openstack-keystone18:11
*** einarf has joined #openstack-keystone18:14
*** harlowja has quit IRC18:19
*** harlowja has joined #openstack-keystone18:19
openstackgerritHarry Rybacki proposed a change to openstack/python-keystoneclient: check revocation by events in auth_token middleware  https://review.openstack.org/9975118:24
hrybackiayoung: if you could review that patch and give me a next recommended step that would be ++18:25
ayounghrybacki, ++18:32
*** morganfainberg changes topic to "Review Proposed Specs: https://review.openstack.org/#/q/status:open+project:openstack/keystone-specs,n,z"18:32
ayounghrybacki, lets see if it passes jenkins18:32
hrybackiayoung++18:33
ayounghrybacki, what do you think about moving the raise exception into 'is_signed_token_revoked' as it looks like everything is just raising upon false anyway18:36
hrybackiayoung: I can't think of any good reason why not to18:38
ayoungerr...make that 'raising upon true'18:38
openstackgerritA change was merged to openstack/keystone: Password trunction makes password insecure  https://review.openstack.org/7732518:38
hrybackiI got what you meant :)18:39
ayounghrybacki, OK...so, when you make that change, split this into two:  one is the refactoring, without adding in the revocation events.  The second adds the revocation events.  And the second will be WIP until we can integrate events in with the rest of the change18:39
morganfainberglbragstad, ping: https://review.openstack.org/#/c/95987/ the steps to extract the code is going to be really manual.18:40
morganfainberglbragstad, there is no "canned" way to do it unless you're oslo-incubator18:40
hrybackihow exactly do I do that?18:40
lbragstadmorganfainberg: gotcha,18:40
lbragstadmakes sense18:40
lbragstadI wasn't sure if they followed a specific process for it or not18:40
ayounghrybacki, split the patch?18:41
*** nsquare has quit IRC18:41
*** tomoiaga has joined #openstack-keystone18:41
hrybackiayoung: nods18:41
morganfainberglbragstad, there is a script to do it, but it's really going to be "use this method and adapt"18:41
lbragstadmorganfainberg: ok18:41
ayounghrybacki, http://adam.younglogic.com/2014/01/splitting-a-patch/18:41
morganfainberglbragstad, if we need another patch i'll fix the typo :)18:41
lbragstadmorganfainberg: sweet, that takes care of my comments.18:42
morganfainberglbragstad, cool18:42
lbragstadmorganfainberg: thanks for the quick turnaround18:42
morganfainberglbragstad, hehe, we need to get specs through and approved asap so.. watching the ones i can18:43
morganfainberglbragstad, and i think yours is ready to go... so prodding people18:43
lbragstad:)18:43
openstackgerritayoung proposed a change to openstack/keystone: Default to PKIZ tokens  https://review.openstack.org/9889718:45
morganfainbergayoung, https://review.openstack.org/#/c/98845/ approved18:50
ayoungdance party..Ungh Tss  Ungh Tss  Ungh Tss  Ungh Tss  Ungh Tss  ..18:50
morganfainbergayoung, yeah, lets agree that ^ never happened :P18:51
* ayoung can't hear you over the techno18:51
morganfainbergi need to go to a local rock gym :(18:53
morganfainbergit's been too long since i've been.18:53
*** PritiDesai has quit IRC18:53
hrybackiayoung: ^^ simple as pie...18:53
ayoungmorganfainberg, Don't think they have one in Paris, and might be a bit too cold for Fontainbleau18:54
morganfainbergdef too cold in nov18:55
*** nsquare has joined #openstack-keystone18:55
* morganfainberg gets back to running tempest, UUID under apache to verify apache works with uuid :P18:56
morganfainbergwe already know there are issues with pki...18:56
ayoungmorganfainberg, what city are you in?18:56
morganfainbergayoung, Pasadena CA18:56
morganfainbergayoung, sitting on my balcony right now enjoying the sunshine18:56
*** leseb has quit IRC18:56
morganfainbergthere is a rock gym in arcadia iirc, just need to drive there.18:57
ayoungmorganfainberg, this is one time of year where Pasadena doesn't really have much on Boston.  June here is wonderful18:57
dstanekrodrigods: took a quick peek - does that mean the middleware will have to come back to Keystone for every request?18:57
morganfainbergyeah but i'm closer to yosemite :P18:57
morganfainbergayoung, >> i might be going in july.18:57
ayoungJuly in Yose is warm.  We consider that Tuolumne  meadows time18:58
morganfainbergactually anywhere in the sierras would be very nice right now.18:58
morganfainbergayoung, i wouldn't go to the valley18:58
ayoung++18:58
*** doddstack has joined #openstack-keystone18:58
ayoungEver been to Hetch Hetchy?  Amazing part of the Park, and very few people18:58
*** erecio has quit IRC18:59
morganfainbergayoung, oh wait nvm, the weekend i was gonna do yosemite i'm going to a bachelor party for a buddy instead in santa barbara18:59
ayoungDid a great Bachelor's party camping trip there18:59
morganfainbergayoung, no haven't been there18:59
morganfainbergayoung, last time i was in the sierras was to the lemark lakes18:59
ayoungNext time you go.18:59
morganfainbergyears ago18:59
*** erecio has joined #openstack-keystone18:59
ayoungNext years Keystone mid-cycle will be a retreat in Bishop19:00
*** gordc1 has joined #openstack-keystone19:00
ayoungand the January one should be a retreat to Keystone, CO19:00
*** thedodd has quit IRC19:00
morganfainbergi kinda want to do the tuolumne camp, then into cathedral peak and down in a day, 2nd day camp again in tuolomne. (just as a "Get into shape" quick weekend)19:01
morganfainbergayoung, lol19:01
ayoungCathedral is a highway.  Mad scene.19:01
morganfainbergi know, but it's a good in/out for getting back into shape19:01
ayoungI did Eichorn Pinnacle as one of my last trips up there19:01
ayoungheh...altitude can wreck you there19:01
morganfainbergtrue19:02
morganfainbergbut i've done it before. if you pay attention it's doable19:02
ayoungthe mathis crest would be on my short list, actually,19:02
*** gordc has quit IRC19:02
morganfainbergor well.. make sure you are aware if things are going south19:02
morganfainbergmathis crest i hear is nice.19:02
*** nsquare has quit IRC19:02
morganfainbergi used to do joshua tree more than sierras.. unfortunately, jtree in summer... ugh burn your hands on the rock hot19:03
*** gordc1 is now known as gordc19:03
ayoungHeh19:03
ayoungyeah, Bishop we used to say in July you chase the shade and in November you chase the sun19:03
morganfainbergmaybe i'll do tahquitz rock this summer19:04
*** nsquare has joined #openstack-keystone19:06
*** dims has quit IRC19:07
*** einarf has quit IRC19:08
hrybackiayoung: lots of the unittests want 401's back. Obviously I can modify the unittests to look for the exception but will this break any functionality? Not sure why it was built this way in the first place19:09
*** elmiko has joined #openstack-keystone19:09
ayounghrybacki, they should still get the 401, no?19:09
elmikohey all, i'm curious about trusts/delegation. are they available in v3 only?19:10
hrybackinever gets that far, the exception is raised inside of is_signed_token_revoked()19:10
rodrigodsdstanek, sorry, was afk. Yeah, basically it would need to come back to Keystone for every action with an URL in the rule19:11
morganfainberghrybacki, what are you changing away from the 401s? everything should get the same response, unless there is a very good reason to change it19:14
*** einarf has joined #openstack-keystone19:16
hrybackimorganfainberg: moving the raise from https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/middleware/auth_token.py#L904 to https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/middleware/auth_token.py#L113719:16
hrybackibut that short circuited a lot of other things19:17
hrybackior at least I believe it did from the regression faults it caused19:17
morganfainberghrybacki, i think that is going to be hard to solve, legitimately we rely on the 401 happening. you probably need some policy.json fixes where the 401 is required as well19:18
*** dims has joined #openstack-keystone19:18
hrybackimorganfainberg, ayoung: for another day then?19:18
morganfainberghrybacki, i don't think you can just remove the raise, and changing the unit test is probably not correct to begin with (maybe with exception of unscoped actions)19:18
morganfainberghrybacki, maybe the best plan is make it an option (defaults to old behavior)19:19
morganfainberghrybacki, enforce_token_required=True19:19
ayoungmorganfainberg, are we raising two different excpetions, and giving them different return codes?19:19
morganfainbergayoung, are we?19:19
ayoungmorganfainberg,  should be 401 across the board for these otherwise19:19
* hrybacki scratches head19:20
morganfainbergayoung, this is the raise 401 on no token, right hrybacki ?19:20
morganfainbergoh oh19:20
hrybackiamong others yes19:20
ayounghrybacki, I think youa re going to far19:20
hrybackiraise 401 on revoked token, revoked token 256...19:20
morganfainberghrybacki, why are you looking to remove from the is_revoked check?19:21
ayounghrybacki  just move the raise into hrybacki19:21
morganfainbergif the token is revoked, 401 is correct though19:21
ayoungheh19:21
ayounghrybacki  just move the raise into is_signed_token_revoked19:21
hrybackiayoung: that's whay I did19:21
hrybackiwhat*19:21
morganfainberghrybacki, ah19:22
ayoungwhere else is it called, I wonder19:22
morganfainbergayoung, yeah19:22
morganfainberghrybacki, sorry i'm playing catchup ;) sounds like you're going the right direction19:22
hrybackimorganfainberg: no worries -- I'm doing the same with your codebase :P19:23
*** stevemar has quit IRC19:23
openstackgerritMorgan Fainberg proposed a change to openstack/python-keystoneclient: Do not expose Token IDs in debug output  https://review.openstack.org/9943219:23
ayounghrybacki, I think you goofed19:23
*** stevemar has joined #openstack-keystone19:23
hrybackiayoung: ?19:23
ayoungis_signed_token_revoked  is only called from _validate_user_token19:23
ayoungthere should be no change in logic...19:23
ayoungcan you paste your change?19:24
*** PritiDesai has joined #openstack-keystone19:24
*** vhoward has quit IRC19:24
*** dstanek is now known as dstanek_zzz19:25
*** PritiDesai has quit IRC19:25
hrybackiayoung: http://fpaste.org/110267/94673314/19:25
*** erecio has quit IRC19:25
*** erecio has joined #openstack-keystone19:26
marekddstanek_zzz: thanks for the review!19:26
ayounghrybacki, hmmm19:26
*** bobt has joined #openstack-keystone19:26
openstackgerritMorgan Fainberg proposed a change to openstack/keystone-specs: Service Token Composite Authorization Specification  https://review.openstack.org/9631519:26
*** vhoward has joined #openstack-keystone19:27
hrybackiayoung: there are two problems19:27
ayounghrybacki, so, OK, a lot of the tests that do true/false now would be  raise/don't raise19:28
hrybackithere is a test that calls the is_signed_token_revoked directly expecting True (which is correct before)19:28
hrybackiyes19:28
ayoungtests can be changed.  We should also make the call private19:28
ayoung_is_signed_token_revoked19:29
hrybackiI just wanted to make sure that it wouldn't break anything else19:29
ayoungnope, that is acceptable19:29
ayoungwhen you said 401, I was concerned19:29
hrybackiwell, other things broke as well19:29
hrybackithe second problem ;)19:29
hrybackie.g. test_revoked_token_receives_40119:30
ayoung_check_signed_token_revoked19:30
ayoungthat should still get a 40119:30
hrybackiwhere is that?19:31
ayounghrybacki, that is the name to change the function to19:32
ayounghrybacki, You might have a type19:33
ayoungtypo19:33
ayoungremove your changes inside the if self.check_revocations_for_cached:  block19:33
ayounghrybacki, http://paste.fedoraproject.org/110268/40294723/  I get just the tests failing due to the exception19:34
ayounghrybacki, I think you are on track19:36
morganfainbergbobt, welcome19:38
hrybackiayoung: okay, same, now it's only failing on things wanting to see True19:40
ayounghrybacki, and those tests can be changed19:41
hrybackiyes, to self.assertRaises(...19:41
openstackgerritayoung proposed a change to openstack/keystone: Kerberos as method name  https://review.openstack.org/9598919:41
*** dstanek_zzz is now known as dstanek19:43
ayounghenrynash, with your currently merged patch, do we have the capability of running an install with Mysql for the default domain, and then mounting the LDAP domain as a second step?19:44
ayoungor do we need the patch that is still up for review for that?19:44
ayounghttps://review.openstack.org/#/c/74214/  morganfainberg   you could probably answer that, too19:45
henrynashayoung: you mean, adding the LDAP specific to a given domain at a later date?19:47
ayounghenrynash, exactly19:48
henrynashayoung: sure, I think so….you can change add specifc LDAP for a given domain at any point, you wuold need to restart keystone (it only reads the configs on startup)19:49
ayounghenrynash, ooooh19:50
ayounghenrynash, and then each ldap access would end up with an entry in the shadow table?19:50
henrynashayoung: hold it, which patch are you talking about...19:50
henrynashayoung: I thought you were talking about the already merged patch....19:51
henrynashayoung: i.e. Havana19:51
ayounghenrynash, nope19:51
ayoungI meant the one that made it into Juno 119:51
ayoungbut I see the shadow table is not in yet19:51
*** praneshp has quit IRC19:52
henrynashayoung: it dodn’t make it into Juno1, the concensus view was to ditch the idea of two public ID generators and go for sha1 only19:52
henrynashand it was too late in the day to get that all fixed up to get it into J119:53
henrynashwill be posting a new version of teh patch tonight or tomorrow19:53
hrybackiayoung: okay, refactoring done, passing all the tox tests -- now you want me to split the patch?19:54
*** tomoiaga has left #openstack-keystone19:55
ayounghrybacki, yep.  The refactoring can be reviewed and merge on its own, and the other goes as WIP but shows people why the refactoring is necessary19:55
ayoungthe events portion of the patch should get a new changeid19:55
hrybackiokay -- not going to lie, your blog confused me more than anything19:56
ayounghrybacki, my work here is done19:59
hrybackiheh19:59
hrybackiI've created just enough rope...20:00
ayounghrybacki, ok start by creating a new branch, so you can mess with things without losing your own changes20:01
ayoungmakes sure everything is committed20:01
ayoungthen git checkout -b split-auth-token20:01
ayoungnow, it doesn't matter what changes you make, so long as you leave your old branch alone.20:02
ayounggit log --format=%B -n 1 HEAD > /tmp/commitmsg.txt    will make sure you have your commit message saved in its own file, to include the commit it20:02
ayoungchange id20:02
hrybackigit commit or --amend?20:02
ayoungneither20:03
*** jsavak has joined #openstack-keystone20:03
ayounggit log --format=%B -n 1 HEAD > /tmp/commitmsg.txt20:03
hrybacki16:01 ayoung: makes sure everything is committed20:03
*** devlaps has quit IRC20:03
ayounghrybacki, ah, make sure that you have everything in the one patch you are going to split20:03
ayounghrybacki, you might as well post that for review20:03
ayoungthat way we have a decent baseline20:03
hrybackiwith the refactoring?20:03
ayounghrybacki, ah...one sec20:03
ayoungyeah...but post it thist way20:04
*** marcoemorais has quit IRC20:04
*** marcoemorais has joined #openstack-keystone20:04
ayounghrybacki, so, yeah, it would be amend20:04
*** joesavak has quit IRC20:05
hrybackiokay20:05
ayounghrybacki,   to make sure you don't resubmit an older version of the patch  that you are on top of  use this magic command git push gerrit HEAD:refs/for/master20:05
*** einarf has quit IRC20:05
ayounghttps://review.openstack.org/#/c/81166/17  is ready to go, and you might not have rebased20:05
ayoungusing the "push" version I have above only submits your changes, and does not rebase20:06
ayoungwell, does not rebase in your repo, but it will rebase in gerrit,  it just does the right thing20:06
openstackgerritHarry Rybacki proposed a change to openstack/python-keystoneclient: check revocation by events in auth_token middleware  https://review.openstack.org/9975120:06
hrybackiI think I did rebase it with 17 in a bit20:07
hrybackicommit f07ba232efe7549ae3ce088170f4eabb61ab70a620:07
ayounghrybacki, its ok.  so long as it didn't trigger a resubmit of the events patch20:10
ayoungnow...20:10
*** dhellmann has quit IRC20:10
ayounghrybacki, to split the patch,  start with checking out a new branch20:11
*** dhellmann has joined #openstack-keystone20:12
ayounghrybacki, um, I think you lost some changes there20:12
ayounghttps://review.openstack.org/#/c/99751/5/keystoneclient/tests/test_auth_token_middleware.py,cm20:12
ayounghrybacki, I think you lost some of the PKIZ tests20:12
*** dims has quit IRC20:14
*** dims has joined #openstack-keystone20:15
hrybackiayoung: hrm, how would that have even happened?20:24
ayounghrybacki, maybe your version of the patch was older than code that merged, but that seems wierd20:24
openstackgerritA change was merged to openstack/keystone-specs: Propose api-validation blueprint  https://review.openstack.org/9595720:24
ayounghrybacki, need to figure out where those changes are from20:25
morganfainbergfyi, ^ merged specs, those are the ones we voted we liked last meeting.20:25
ayoungif they are from master than do20:25
hrybackiI must have deleted them somehow20:25
ayounggit checkout master keystoneclient/tests/test_auth_token_middleware.py20:26
*** einarf has joined #openstack-keystone20:26
ayoungthat will lose your changes, but they should be relatively easy to reinstate20:26
*** jcromer has joined #openstack-keystone20:26
hrybackiit'll lose all of the revocation events changes20:27
*** CaioBrentano has joined #openstack-keystone20:27
*** dstanek is now known as dstanek_zzz20:28
CaioBrentanoI'm getting these errors on keystone log20:28
CaioBrentanoCould not load 'rabbit': No module named amqp20:28
CaioBrentanoNo module named amqp20:28
CaioBrentanoDo I have to install ampq modules even if I'm not using any amqp service?20:29
morganfainbergCaioBrentano, which version of Keystone? How was it installed/deployed?20:29
*** jorgew has joined #openstack-keystone20:29
CaioBrentanomorganfainberg: version 2014.120:29
morganfainbergCaioBrentano, thats ... icehouse right?20:30
CaioBrentanomorganfainberg: It was deployed by pip install20:30
CaioBrentanomorganfainberg: yep20:30
jsavakmorganfainberg, stevemar, jorgew  - ready to talk federation?20:30
morganfainbergjsavak, in one moment just helping CaioBrentano right now20:30
morganfainbergCaioBrentano that looks like an issue with perhaps kombu or one of the oslo.messaging dependencies not being installed20:31
jsavakok, cool. We're free until 4 then off to another meeting (in 30 mins)20:31
*** leseb has joined #openstack-keystone20:31
morganfainbergjsavak, but we can def chat... *pokes stevemar* ;)20:31
CaioBrentanomorganfainberg: I got this kombu module error… I've installed and started theses other errors20:32
morganfainbergCaioBrentano, is keystone failing to start? or are you just seeing those as messages in the log? and can you post ( paste.openstack.org ) your keystone.conf (please scrub/remove passwords/sensitive data)20:32
ayounghrybacki, just the changes to the tests20:33
CaioBrentanomorganfainberg: actually it appears to be working ok… i'm getting tokens and it's working… but i'm getting theses errors repeatedly20:33
ayounghrybacki, yeah, chasing the gate.  CHasing the dream20:33
stevemarmorganfainberg, jsavak ahoy hoy20:33
*** praneshp has joined #openstack-keystone20:34
*** radez is now known as radez_g0n320:34
jorgewstevemar, jsavak, morganfainberg,  hey I'm ready when you guys are20:34
hrybackiayoung: hmm, I checked out test_auth_token_middleware from origin/master -- 38 fails now, lol20:34
morganfainbergCaioBrentano, ok that probably means it's just having a hard time loading up the messaging library, possibly just a typo in your config or in the module to use for messaging/notifications20:34
morganfainbergjorgew, jorgew, stevemar, i'm ready20:34
ayounghrybacki, looks like you have your work cut out for you20:34
morganfainbergCaioBrentano, taking a look at the config is likely the easiest route to see if something looks off (sometimes an extra pair of eyes helps)20:35
jsavakalrighty20:35
stevemarmorganfainberg, anything specific you wanted to chat about regarding federation fun20:35
*** leseb has quit IRC20:35
jorgewmorganfainberg, jsavak mentioned you had some concerns with the SP proposal.  I'd like to understand the concern.  Did those comments make it to the review?20:35
hrybackiayoung: how often do you rebase 81166 against origin/master?20:36
jsavakreview is: https://review.openstack.org/#/c/100023/20:36
*** radez_g0n3 is now known as radez20:36
ayounghrybacki, ...every so often?20:36
ayounghrybacki, if it goes stale, or gets a -1 or soemthing20:36
jsavakmajor concerns seem to be security, re-creating the wheel, and confusion about service provider vs idp, right?20:36
hrybackiayoung: hmmmm. haven't rebased against it with 9975120:36
ayounghrybacki, lets see...20:37
stevemarjsavak, jorgew i think morganfainberg wants to know why don't we just use pysaml and make keystone issue saml assertions?20:37
morganfainbergjorgew, yeah.20:37
ayoungok, I rebsed the events one last...20:37
morganfainbergstevemar, ++ also marekd had similar thoughts20:37
morganfainbergafaict20:37
ayoungjun 1320:37
jorgewmorganfainberg,  I think we want to allow users to burst to other clouds without dealing with the idocyncraisis of the SAML protocol directly and to contiune to use the same tools.20:38
hrybackishould I do a rebase every day or so for any given change?20:38
ayounghrybacki, I have something about to merge (I hope, probably just jinxed it)20:38
jorgewmorganfainberg, Also there is a good use case for having the user not even know they are bursting…think resellers.20:38
CaioBrentanomorganfainberg: thanks for your help… just to finish… do I ignore the errors for now (because its working fine) or do I install all the missing modules?20:38
ayoungactually, that is keystone, though20:38
morganfainbergjorgew, but what is being proposed is opening potential security concerns, the external cloud needs to trust the the internal cloud implictly20:39
ayoungnothing in the queue for keystoneclient20:39
ayounghrybacki, but https://review.openstack.org/#/c/100152/  looks pretty invasive20:39
morganfainbergjorgew, an internal cloud issuing tokens on behalf of an external cloud is risky20:39
ayoungand is going to cause a rebase effort...20:39
jsavakmorganfainberg - the trust is explicit. Must be setup within both internal and external cloud20:39
jorgewmorganfainberg,  How is that different than regular federation.  If someone compromises the IDP then that person can send assertions, get tokens right?20:39
hrybackiokay20:40
morganfainbergjorgew, there is a difference between accepting an authentication from a remote source and authorization20:40
jorgewjsavak, right, trust should not be given lightly.20:40
morganfainbergjorgew, most federation is authentication only.20:40
morganfainbergjorgew, the service (in this case the external cloud) would still handle the authz part20:41
morganfainbergjorgew, this proposal puts both authn and authz on a remote, not in control of the local cloud, service20:41
hrybackiI'm not sure how all of that affects me in this case though. Lesson to be learned: rebase against origin/master often? Now I have to do a huge rebase with what I have against  origin/master?20:41
ayounghrybacki, its just part of the job20:42
hrybackioh I'm not complaining, I just want to make sure I'm tracking20:42
morganfainbergjorgew, that is my #1 concern. I have some other concerns on this being a new "protocol" (using keystone tokens to transit data?) or if it's SAML or OpenID on the backend, how is that negotiation initiated20:42
morganfainbergjorgew, because those usually require user-interaction20:42
morganfainbergjorgew s/user/client20:42
ayounghrybacki, I'll probably end up rebasing against that myself for the revoke events.  Big cleanups are part of the course20:42
jorgewmorganfainberg,  The proposal is not suggesting that we do anything different in terms of federation than we are now.  Only to hide some of the flow (or orchestration) for handling SAML stuff.  Authz continues to work as it does now.20:42
morganfainbergCaioBrentano, i'll look in a moment.20:43
morganfainbergjorgew, that is not clear, it looks like authz is being provided by the internal cloud20:43
morganfainbergjorgew, not by the external cloud20:43
morganfainbergjorgew, which Keystone is issuing the token that is meant to be used in the external cloud?20:44
jorgewmorganfainberg, the underling protocols remain the same.  The issue is how we hook things together, maybe we need to make that more clear in the blueprint.20:44
jorgewmorganfainberg, it depends on how you setup the relationships :-)20:44
jorgewmorganfainberg, one keystone can act as an identity provider, that is the one that issues the token.20:45
jorgewmorganfainberg, in otherwords the keystone that knows about the user.20:45
morganfainbergjorgew, ok assume the IDP is internal keystone, SP is external20:45
jorgewmorganfainberg, k20:46
morganfainbergjorgew, walk me through the auth steps please. (sorry, just trying to understand the proposal here so we can make it clear)20:46
*** vhoward has quit IRC20:46
jorgewmorganfainberg, no worries and to be honest we need to work this out as well…but here's how I see it…20:46
jorgewmorganfainberg, off line there is a relationship established between IDP and SP via some magic keys are echanged and mappings are made.20:47
morganfainbergjorgew, ok.20:47
jorgewmorganfainberg, when a user logs in to IDP they get a service catalog that has endpoints from SP.20:47
morganfainbergjorgew, so this is User authenticates with internal keystone here, and gets a token back20:48
morganfainberg?20:48
jorgewmorganfainberg, correct.  The token can then be used to hit the SP endpoint.20:48
morganfainbergand here is where we're now insecure20:49
jorgewmorganfainberg, the SP may introspect the token, know that it came from the IDP and know there is a trust there.20:49
*** vhoward has joined #openstack-keystone20:49
*** dstanek_zzz is now known as dstanek20:49
morganfainbergthe way the middleware works, if the token is considered valid, it is valid and trusted20:49
morganfainbergso either you're then asking the external keystone on every action if it is a "valid token", or you trust it, and internal idp can issue tokens for anything in the entire external cloud20:50
jorgewmorganfainberg, obviously, we'll have to change middleware to deal with trusts between clouds….maybe that's what we're missing in the spec20:50
morganfainbergjorgew, i think this is backwards20:50
morganfainbergjorgew, the external cloud should still issue the token20:50
morganfainbergjust the authn and identity (user/group) bits should come from internal20:50
*** marcoemorais has quit IRC20:50
*** marcoemorais has joined #openstack-keystone20:51
jorgewmorganfainberg, the middle ware will need to understand what certs it accepts and validate the tokens much as it does now20:51
morganfainbergyes, it is a better UX, but what you're proposing would be like if google+ had an agreement with FB, but instead of when you login to google+ it redirects you to FB, it would just grab all your private data from FB, never asking because you authenticated w/ Google+.20:52
jorgewmorganfainberg, can you explain how that is more sucure than the other.?20:52
*** leseb has joined #openstack-keystone20:52
morganfainbergredirect in that scenario would be you needing to auth the request on fb's site.20:52
*** radez is now known as radez_g0n320:52
morganfainbergjorgew, if the internal keystone just offers the identity bits, the workflow looks like this20:53
morganfainberguser requests token from external cloud's keystone20:53
morganfainbergwait..20:54
morganfainbergsorry let me start over.20:54
morganfainbergno i was right...20:54
morganfainbergok20:55
morganfainberguser requests token from external cloud20:55
morganfainbergexternal cloud knows this is a federated request, and initiates the authentication20:55
morganfainbergauthentication then requires the user to interact directly with the internal cloud to auth, in turn an assertion is issued indicating authn was correct20:56
*** erecio has quit IRC20:56
morganfainbergthe assertion is then acted upon within external keystone, and issues the appropriate roles in a token20:56
morganfainbergthat token is now valid for the external cloud20:56
morganfainberg--20:56
morganfainbergthis is more secure simply because the authz is 100% controlled by the external cloud.20:56
openstackgerritA change was merged to openstack/keystone: Allow for multiple PKI Style Providers  https://review.openstack.org/9884520:56
jorgewmorganfainberg, (okay one sec…computing…)20:57
jsavakthe client would end up with multiple tokens, right?20:58
jsavakone for each cloud?20:58
morganfainbergjsavak, yes.20:58
morganfainbergjsavak, and you could indicate via the extension being proposed that X cloud (external) is a valid target - to burst to20:58
jorgewmorganfainberg, I'm sorry I'm not following.  AuthZ is always 100% controlled by the external cloud (SP).  In both proposals.  What do you mean by AuthZ…the assignment of roles?20:58
morganfainbergjsavak, no authz is not controlled by the external cloud in your model20:59
morganfainbergjsavak sorry, jorgew ^20:59
*** juanmo has quit IRC20:59
openstackgerritayoung proposed a change to openstack/keystone: Default to PKIZ tokens  https://review.openstack.org/9889720:59
jorgewmorganfainberg,  by external cloud you mean the SP or the IDP…sorry21:00
morganfainbergjorgew, the token itself is authorization - asking keystone every time if this token is allowed because it came from an external source is a really ugly way to handle it (external cloud would need to check the token every time)21:00
morganfainbergjorgew, sp21:00
morganfainbergjorgew, sorry21:00
*** marcoemorais has quit IRC21:00
*** marcoemorais has joined #openstack-keystone21:00
jsavakauthorization contains policy informaiton point, policy enforcement point, policy decision point and policy admin point. By Jorge's example the PIP is both internal and external (broadcasted endpoints). The PAP is external. The PDP and PEP is external. Most of the authZ is external...21:00
jorgewmorganfainberg, we don't nessesarly have to always go back to the external source if we keep track of trusts…much how PKI works today.21:00
*** marcoemorais has quit IRC21:01
jorgewjsavak, morganfainberg,  I'm sorry guys I have to run :-(21:01
jsavakok - when can you join again jorgew?21:01
morganfainbergjorgew, no worries.21:01
jorgewjsavak, morganfainberg,  I'm free most of the morning tomorrow my time from 9am to noon.  I feel that if we can just get the terminology right we've made progress :-)21:02
morganfainbergjorgew, sure.21:02
jorgewjsavak, morganfainberg, when can you guys meet?21:02
morganfainbergjorgew, i'm Pacific but usually am online starting ~7pacific each day21:02
*** marcoemorais has joined #openstack-keystone21:02
*** marcoemorais has quit IRC21:03
*** marcoemorais has joined #openstack-keystone21:03
morganfainbergCaioBrentano, can you use paste and show me an example of the logs w/ the error in it? I'm not seeing anything (openly) wrong in your config21:03
jorgewjsavak, morganfainberg, how about 8 am pacific, 10 am central?21:03
*** marcoemorais has quit IRC21:03
morganfainbergjorgew, works for me21:03
jsavakthat works! Thanks jorgew21:04
*** marcoemorais has joined #openstack-keystone21:04
jorgewjsavak, morganfainberg, okay gotta run see you then21:04
*** jorgew has left #openstack-keystone21:04
*** sbfox has quit IRC21:04
*** jcromer has quit IRC21:04
morganfainbergjsavak, yeah i wasn't using the acronyms and names there, but even if you substitute that (happy to work on using a more common vocab), i think this approach is just backwards21:05
morganfainbergjsavak, we'll talk more tomorrow.21:05
*** leseb has quit IRC21:05
jsavakgood deal. : )21:05
*** leseb has joined #openstack-keystone21:05
*** marcoemorais has quit IRC21:06
*** marcoemorais has joined #openstack-keystone21:06
*** sbfox has joined #openstack-keystone21:09
*** leseb has quit IRC21:10
*** dhellmann has quit IRC21:11
*** marcoemorais has quit IRC21:12
*** marcoemorais has joined #openstack-keystone21:13
*** dhellmann has joined #openstack-keystone21:13
*** diegows has quit IRC21:15
*** gordc1 has joined #openstack-keystone21:17
*** diegows has joined #openstack-keystone21:17
*** gordc has quit IRC21:18
*** elmiko is now known as _elmiko21:20
*** jaosorior has quit IRC21:22
*** leseb has joined #openstack-keystone21:22
*** diegows has quit IRC21:23
*** PritiDesai has joined #openstack-keystone21:27
*** leseb has quit IRC21:27
*** diegows has joined #openstack-keystone21:27
*** hrybacki_ has joined #openstack-keystone21:30
openstackgerritA change was merged to openstack/identity-api: Trusted Attributes Policy for External Identity Providers  https://review.openstack.org/6048921:31
*** gordc1 is now known as gordc21:33
*** hrybacki has quit IRC21:33
*** hrybacki_ has quit IRC21:35
*** leseb has joined #openstack-keystone21:36
*** leseb has quit IRC21:40
*** dstanek is now known as dstanek_zzz21:41
*** dstanek_zzz is now known as dstanek21:41
morganfainbergnkinder, hey, if you have some time to look over and help on the federation keystone-to-keystone spec i'd appreciate it. I know marekd and stevemar are also looking at it, but more security minds are good :) [ if you don't mind puttnig on the security hat for it ]21:44
*** diegows has quit IRC21:44
morganfainbergmarekd, not sure when you're around, would like you involved w/ the discussion on keystone-to-keystone federation21:49
*** diegows has joined #openstack-keystone21:49
nkindermorganfainberg: this one? https://review.openstack.org/#/c/100023/21:50
*** joesavak has joined #openstack-keystone21:50
morganfainbergnkinder, yeah21:50
morganfainbergnkinder, it's... setting off alarm bells in my head when i read it, but i might be just mis-reading it.21:50
morganfainbergnkinder, extra eyes, smarter people you know.. the folks that know this stuff :)21:51
*** henrynash has quit IRC21:51
morganfainbergmarekd, you have a great understanding of what needs to go on under the hood, and want to make sure things aren't missed :)21:52
*** jsavak has quit IRC21:52
*** nkinder has quit IRC21:55
*** dstanek is now known as dstanek_zzz22:02
*** daneyon has quit IRC22:03
*** daneyon has joined #openstack-keystone22:03
*** marcoemorais has quit IRC22:04
*** marcoemorais has joined #openstack-keystone22:05
*** dstanek_zzz is now known as dstanek22:05
*** marcoemorais has quit IRC22:05
*** marcoemorais has joined #openstack-keystone22:05
*** marcoemorais has quit IRC22:07
*** marcoemorais has joined #openstack-keystone22:08
*** _TheDodd_ has joined #openstack-keystone22:20
*** doddstack has quit IRC22:23
*** lbragstad has quit IRC22:24
*** stevemar has quit IRC22:27
*** daneyon has quit IRC22:30
*** einarf has quit IRC22:35
*** leseb has joined #openstack-keystone22:36
*** leseb has quit IRC22:41
*** _TheDodd_ has quit IRC22:46
*** dstanek is now known as dstanek_zzz22:48
*** PritiDesai has quit IRC22:53
openstackgerritBrant Knudson proposed a change to openstack/python-keystoneclient: auth_token cached token handling  https://review.openstack.org/9678622:53
openstackgerritBrant Knudson proposed a change to openstack/python-keystoneclient: auth_token _cache_get checks token expired  https://review.openstack.org/9678522:53
*** thedodd has joined #openstack-keystone22:56
*** gordc has quit IRC23:02
*** dstanek_zzz is now known as dstanek23:09
*** joesavak has quit IRC23:16
*** thedodd has quit IRC23:18
*** dstanek is now known as dstanek_zzz23:19
*** jamielennox|away is now known as jamielennox23:21
*** dstanek_zzz is now known as dstanek23:22
*** sbfox has quit IRC23:26
*** dstanek is now known as dstanek_zzz23:32
*** leseb has joined #openstack-keystone23:37
*** dims has quit IRC23:41
*** leseb has quit IRC23:42
*** topol has quit IRC23:47
*** dstanek_zzz is now known as dstanek23:47

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