Friday, 2014-08-15

*** stevemar has joined #openstack-keystone00:04
*** leonchio_ has quit IRC00:04
*** gokrokve has quit IRC00:28
*** gokrokve has joined #openstack-keystone00:29
*** bknudson has joined #openstack-keystone00:29
*** gokrokve has quit IRC00:33
*** gokrokve has joined #openstack-keystone01:14
*** gokrokve has quit IRC01:14
*** gokrokve has joined #openstack-keystone01:15
openstackgerritA change was merged to openstack/keystone: Keystone service throws error on receiving SIGHUP
stevemarbknudson, clearly we need some non-ibmers to review some of our patches!01:36
bknudsonstevemar: we should talk to their employer and tell them to spend more time on reviews01:37
bknudsonthey should get paid for reviews01:37
stevemarbknudson, maybe they are not reviewing ours because we don't review their, spite and all01:37
stevemardolphm, seems like the grudge holding type01:38
*** gokrokve has quit IRC01:39
*** gokrokve has joined #openstack-keystone01:39
*** gokrokve has quit IRC01:43
ayoungbknudson, stevemar spread the rumor that the non IBMers are going to get thrown off core.01:48
stevemarayoung, starting with dolphm01:48
ayoungHeh.  Seriously, though, what patches are languishing?01:49
stevemarayoung, i think it's just this guy:
stevemaroh right, this one too: ayoung01:53
*** zzzeek_ has joined #openstack-keystone01:59
*** zzzeek has quit IRC01:59
*** zzzeek_ is now known as zzzeek01:59
*** yasukun has joined #openstack-keystone02:02
*** zzzeek has quit IRC02:18
ayoungstevemar, the links one....02:23
ayoungthey would make the token larger.  That would be bnad02:24
ayoungbad even02:24
ayoungstevemar, +A02:25
ayoungany others?02:25
*** diegows has quit IRC02:25
openstackgerritA change was merged to openstack/keystone-specs: Role assignment notifications
*** Krast has joined #openstack-keystone02:33
*** topol has joined #openstack-keystone02:35
openstackgerritA change was merged to openstack/identity-api: Make API specification match our token format.
openstackgerritA change was merged to openstack/keystone: Rename bash8 requirement
stevemarayoung, nah, just those two02:47
stevemarthe links were never being returned, just some long standing copy pasta02:47
nkinderdstanek: I reviewed from a security perspective02:51
nkinderdstanek: it all looks fine to me.  I don't see how that would leak anything sensitive.02:51
nkinderdstanek: I played around with openssl to trigger some various failures with the commands we run, and all of the error information is very generic and safe if exposed.02:52
*** arosen1 has quit IRC03:05
*** arosen1 has joined #openstack-keystone03:05
*** Krast has quit IRC03:10
*** Krast has joined #openstack-keystone03:10
*** gokrokve has joined #openstack-keystone03:31
*** gokrokve has quit IRC03:33
*** harlowja is now known as harlowja_away03:42
openstackgerritMorgan Fainberg proposed a change to openstack/keystone: Bump hacking to 0.9.x series
*** yasukun has quit IRC03:43
*** yasukun_ has joined #openstack-keystone03:44
*** chandankumar has joined #openstack-keystone03:54
*** rushiagr_away is now known as rushiagr03:56
*** hrybacki has joined #openstack-keystone04:06
*** chandankumar has quit IRC04:06
*** richm has quit IRC04:21
*** amcrn has quit IRC04:23
dstaneknkinder: thanks!04:30
nkinderdstanek: sure04:32
*** alex_xu has quit IRC04:32
*** alex_xu has joined #openstack-keystone04:33
*** amirosh has joined #openstack-keystone04:49
amiroshhi guys, could you review I'm sure someone somewhere is waiting for this feature, we shouldn't make her waiting04:51
openstackgerritJamie Lennox proposed a change to openstack/python-keystoneclient: Allow passing user_id to v2Password plugin
*** amirosh has quit IRC04:53
*** amirosh has joined #openstack-keystone04:54
*** rushiagr is now known as rushiagr_away04:56
*** amirosh has quit IRC04:58
*** rushiagr_away is now known as rushiagr05:03
openstackgerritJamie Lennox proposed a change to openstack/python-keystoneclient: Allow unauthenticated discovery
openstackgerritJamie Lennox proposed a change to openstack/python-keystoneclient: Make keystoneclient use an adapter
openstackgerritJamie Lennox proposed a change to openstack/python-keystoneclient: Allow providing a default value to CLI loading
openstackgerritJamie Lennox proposed a change to openstack/python-keystoneclient: Fix handling of deprecated opts in CLI
openstackgerritJamie Lennox proposed a change to openstack/python-keystoneclient: Version independent plugins
openstackgerritJamie Lennox proposed a change to openstack/python-keystoneclient: Make auth plugins dest save to os_
openstackgerritJamie Lennox proposed a change to openstack/keystonemiddleware: Refactor auth_token cache
*** Krast has quit IRC05:31
*** jamielennox is now known as jamielennox|away05:35
*** arosen1 has quit IRC05:41
*** arosen2 has joined #openstack-keystone05:41
*** hrybacki has quit IRC05:47
*** alex_xu has quit IRC05:55
openstackgerritA change was merged to openstack/keystone: Bump hacking to 0.9.x series
openstackgerritSteve Martinelli proposed a change to openstack/keystone: Transform a Keystone token to a SAML assertion
openstackgerritOpenStack Proposal Bot proposed a change to openstack/keystone: Imported Translations from Transifex
*** Krast has joined #openstack-keystone06:09
*** alex_xu has joined #openstack-keystone06:11
*** topol has quit IRC06:12
*** amirosh has joined #openstack-keystone06:14
openstackgerritSteve Martinelli proposed a change to openstack/keystone: Create SAML generation route and controller
*** tomoiaga has joined #openstack-keystone06:17
*** alex_xu has quit IRC06:21
*** stevemar has quit IRC06:22
*** alex_xu has joined #openstack-keystone06:27
*** arosen2 has quit IRC07:26
openstackgerritMarcos Fermín Lobo proposed a change to openstack/keystone: Implement group related methods for LDAP backend
*** RicoLin has joined #openstack-keystone08:40
*** Dafna has quit IRC08:49
*** RicoLin has quit IRC08:49
*** RicoLin has joined #openstack-keystone08:51
*** RicoLin has quit IRC08:52
*** RicoLin has joined #openstack-keystone08:53
*** Dafna has joined #openstack-keystone08:58
*** RicoLin has quit IRC09:01
*** RicoLin has joined #openstack-keystone09:01
*** RicoLin has quit IRC09:33
*** Krast has quit IRC09:56
*** RicoLin has joined #openstack-keystone10:02
*** RicoLin has quit IRC10:06
*** RicoLin has joined #openstack-keystone10:06
openstackgerritMarcos Fermín Lobo proposed a change to openstack/keystone: Implement validation on the Catalog V3 resources
*** RicoLin has quit IRC10:44
*** diegows has joined #openstack-keystone11:01
*** RicoLin has joined #openstack-keystone11:11
*** RicoLin has quit IRC11:25
*** rushiagr is now known as rushiagr_away11:30
*** rushiagr_away is now known as rushiagr11:35
*** aix has joined #openstack-keystone11:38
*** aix has quit IRC11:40
*** henrynash has joined #openstack-keystone11:40
*** aix has joined #openstack-keystone11:40
*** yasukun_ has quit IRC11:50
*** RicoLin has joined #openstack-keystone11:53
*** henrynash has quit IRC11:53
*** RicoLin has quit IRC12:05
*** henrynash has joined #openstack-keystone12:07
*** rushiagr is now known as rushiagr_away12:08
*** henrynash has quit IRC12:11
*** afazekas has joined #openstack-keystone12:19
openstackgerritMarcos Fermín Lobo proposed a change to openstack/keystone: Implement validation on the Catalog V3 resources
*** gordc has joined #openstack-keystone12:29
*** cjellick has joined #openstack-keystone12:30
*** _elmiko is now known as elmiko12:40
*** jimbaker has joined #openstack-keystone12:44
*** aix has quit IRC12:55
*** aix has joined #openstack-keystone12:57
*** topol has joined #openstack-keystone12:57
*** radez_g0n3 is now known as radez12:59
*** jdennis has quit IRC13:01
*** russellb is now known as rustlebee13:03
*** topol has quit IRC13:04
*** joesavak has joined #openstack-keystone13:08
*** rushiagr_away has quit IRC13:09
*** nkinder has quit IRC13:10
miquiis there keystone v3 installed with the latest devstack?13:12
*** richm has joined #openstack-keystone13:16
dolphmmiqui: keystone itself has supported both v2 and v3 side by side since grizzly; to use v3 from the CLI, use python-openstackclient rather than python-keystoneclient's deprecated CLI13:18
miquidolphm:  thanks ... so the url endpoint displayed at the end of the devstack install is same but with /v3 ?13:19
dolphmmiqui: yes13:19
miquidolphm: is this the proper way to test keystone and contribute?13:20
*** fifieldt has quit IRC13:20
*** bknudson has quit IRC13:22
*** jdennis has joined #openstack-keystone13:22
dolphmmiqui: there's a lot of ways to contribute :) but if you're looking to do any sort of API work, we're certainly putting all our focus on v313:22
miquidolphm:  thanks..13:24
ayoungmiqui, want an easy hit?13:26
*** rushiagr_away has joined #openstack-keystone13:27
ayoungThe Horizon code has some "v2.0" strings embedded in it.  Yank those and make the URLs correct for either v2 or v313:27
miquiayoung:  sure... no better way to get started13:27
ayoungmiqui, I'll post a link13:27
miquiayoung:  thanks...13:27
miquiinteresting that those strings do not come from a config ...13:28
ayoungmiqui, I need to find it...I made the change in an installed system, one of the few things not done in a git repo13:29
ayoungmiqui, yeah, I think this one was an oversight, and someone might have got it already...13:29
miquino probs...13:30
miquii'll be around, i'll find another one... thnanks13:30
ayoungits not quite what I remebered13:34
ayoungit looks like someone has touched used to bre13:34
ayoung bits = urlparse.urlparse(url)13:35
ayoung    root = "://".join((bits.scheme, bits.netloc))13:35
ayoungand that didn't work for V3...I had changed it to13:35 more line, it had then13:35
ayoungurl = "%s/v%s" % (root,
ayoungI had hacked it to13:35
ayoung url = "%s/v%s" % (url,
ayoungthe current code might be better.13:36
*** RicoLin has joined #openstack-keystone13:36
ayoungbut it still looks wrong....lets see13:36
ayoungmiqui, yeah, so that won;t work13:37
ayoungwhat I had in another code was replaceing the /v2.0 with ""  if it was there.  That was just proof of concept13:38
ayoungI think the right code might be something like13:38
ayoung url = url.replace('/v2.0',"")13:38
ayoung url = url.replace('/v3',"")13:38
ayoungurl = urlparse.urljoin(url, 'v%s' %
ayoungHorizon should  be doing discovery to find V2.0 vs V3, but since we have it as a config option, and since older clients need the service catalog to have V2.0  in there, we are kindof stuck with horrible hacks like this13:40
*** bknudson has joined #openstack-keystone13:40
*** RicoLin has quit IRC13:40
miquihmm yeah i see,,13:41
*** RicoLin has joined #openstack-keystone13:41
amiroshhi guys, could someone review ? implementation of filter-credentials-by-user bp depends on it13:42
*** hrybacki has joined #openstack-keystone13:45
ayoungamirosh, sure.13:52
amiroshayoung: thanks! you help me second time in a row, appreciate it13:53
openstackgerritMarcos Fermín Lobo proposed a change to openstack/keystone: Implement validation on the Catalog V3 resources
ayoungcred_from_credential_api = self.credential_api.list_credentials_for_user(self.user_id))13:59
ayounghard to do in IRC14:00
ayoungbottom line, its too pedantic for me to care about.  Just so you know14:00
*** nkinder has joined #openstack-keystone14:00
amiroshThanks for letting me know, I thought it's pep8 recommended way, will check14:01
amiroshayoung: would it be too much to ask review - the last one for today, promise14:04
*** henrynash has joined #openstack-keystone14:05
*** stevemar has joined #openstack-keystone14:08
*** henrynash has quit IRC14:18
stevemarsometimes VPN just isn't your friend14:22
*** gordc_ has joined #openstack-keystone14:23
ayoungamirosh, do you need to update policy.json as well, or just cloudsample?14:23
amiroshayoung: good question, I thought cloudsample was enough, perhaps I was wrong14:24
ayoungamirosh, your change won't take effect on standard policy14:25
ayounglets see...14:25
amiroshI think I should change it too in that case14:25
ayoungits admin only right now14:25
ayoungamirosh, no, I think I would prefer that we not touch the standard policy for this one14:26
amiroshayoung: trust your judgement14:27
*** mitz has quit IRC14:27
ayoungamirosh, we can always roll in that change as a follow on if it is required.14:28
ayoungbeating on it in cloudsample is the safer approach14:28
*** vhoward has joined #openstack-keystone14:30
*** tomoiaga has quit IRC14:31
openstackgerritSteve Martinelli proposed a change to openstack/identity-api: Add SAML generation route to OS-FEDERATION
*** amirosh has quit IRC14:37
*** amirosh has joined #openstack-keystone14:38
*** amirosh has quit IRC14:42
*** henrynash has joined #openstack-keystone14:48
henrynashstevemar: hi14:48
stevemarhenrynash, hola14:49
henrynashstevemar; so maybe I’m just having a senior moment, but assuming we exchange a scoped token for a SAML assertion (for K2K), where in the assretion is the scope?14:49
stevemarhenrynash, ahhh good question :)14:50
stevemarhenrynash, rewind to icehouse14:50
stevemarhenrynash, did the SAML assertions have scopes there? (nope)14:50
stevemarhenrynash, the mapping determined what 'group' the user would be slotted into, and we would inherit roles from the group14:51
henrynashstevemar: True……although the original assertion was usncoped in that it had (i assume) everything that the IdP knows about me14:52
stevemarhenrynash, that is also true...14:53
*** zhiyan has quit IRC14:53
*** zhiyan has joined #openstack-keystone14:54
henrynashstevemar: I’m just trying to work it if I’m the receivor of one of our K2K assertions, whether I can make sense of it…..14:54
stevemarhenrynash, it should look like any other incoming assertion14:54
henrynashstevemar: so let me try and walk myself through this :-)14:55
stevemarhenrynash, ideally we have keystoneclient issue the request to the SP, once it has the assertion in hand14:55
henrynashstevemar: I’m teh SP and providing some set of services (say compute for some set of projects)14:56
henrynashstevemar: I assume I agree with the Keystone IdP cloud provider, that I should allow requests provided they have some set of roles?14:57
stevemarthe SP admin should set up the keystone idp (create an identity_provider, protocol, and mapping)14:58
henrynashstevemar: agreed14:58
henrynashstevemar: and that mapping is driven by the “roles” we put in the assertion, I assume14:58
stevemarhenrynash, yep14:59
*** jorge_munoz has joined #openstack-keystone14:59
henrynashstevemar: so if the role mapping required, say, “teaboy”…14:59
henrynashstevemar: so I could scope to any project (or domain) that I have the role  “teaboy” on, swap that for an assertion and then go to the SP15:00
stevemarhenrynash, thats the plan15:00
stevemarhenrynash, not to muddy the waters, but you had me thinking... we could list all effective roles a user has, upon receiving a token15:01
henrynashstevemar: so we really saying (I think) role assignments are kind of global for K2K (i.e. it doesn’t matter what project/or domain they’re on)15:01
henrynashstevemar: which somehow feels odd to me15:01
stevemarhenrynash, yeah it kinda does. what do you think about an unscoped token.. and getting effective roles ?15:02
*** jorge_munoz has quit IRC15:02
stevemarall/effective/inherited, whatever word we're using today15:02
henrynashstevemar: effective roles - meaning whatever roles you have anywhere?15:02
henrynashstevemar: well. that would actually be more accurate to what we are actually doing….I think I just need to tyhink though where what we are doing isn’t too scary!15:03
henrynashstevemar: back in sec15:03
*** jorge_munoz has joined #openstack-keystone15:04
*** topol has joined #openstack-keystone15:08
*** david-lyle has joined #openstack-keystone15:12
*** gokrokve has joined #openstack-keystone15:15
*** hrybacki has quit IRC15:15
*** mflobo has quit IRC15:16
openstackgerritBob Thyne proposed a change to openstack/keystone: Implementation of Endpoint Grouping
morganfainberganyone have any issues with spec:
morganfainbergjust wanted to check before pressing "go" on it15:28
morganfainbergayoung, bknudson, if I'm adding documentation about token audit_ids... where would you expect that documentation?15:30
morganfainbergcc dolphm, ^ question i just asked ayoung, bknudson15:31
morganfainbergbknudson, ok.15:31
ayoungmorganfainberg, looking15:31
bknudsonmorganfainberg: some people also look at the docs in
bknudsonmorganfainberg: and here --
morganfainbergbknudson, yeah not sure which file to stick it in for the api-ref15:32
morganfainbergbknudson, i don't even know how to get it there.15:32
morganfainbergif it requires editing wadls, i uh i'm not doing it :P15:33
bknudsonmorganfainberg: POST /v3/auth/tokens15:33
morganfainbergbknudson, and v2/tokens my guess15:33
bknudsonmorganfainberg: (and I already filed a bug for the lack of sections in POST /v3/auth/tokens.15:33
bknudsonmorganfainberg: looks like it's also copied in GET /v3/auth/tokens15:34
morganfainbergbknudson, so, i have no clue where that data is generated from15:34
bknudsonmorganfainberg: WADLs!15:34
morganfainbergbknudson, ok i'll open a bug for the docteam. i don't think i'll be able to get it updated myself in any reasonable timeframe15:35
bknudsonmorganfainberg: you probably also have no clue what "xsd:string" is.15:35
bknudsonwe're in the same boat15:35
morganfainbergbknudson, phew, i am glad i'm not the only one :P15:35
bknudsonor what "plain" style is.15:35
ayoungmorganfainberg, what do you think of changing the end state of the specs to being documentation.  We can  state at some point that a spec is "approved"  but the document we start writing can continue to morph past that point to be something usable long term?15:35
*** gokrokve has quit IRC15:36
ayoungIt seems a waste to put all of the energy into the specs without making them part of the final product15:36
morganfainbergayoung, something to consider, not something i want to think too hard about now.15:36
*** joesavak has quit IRC15:36
*** joesavak has joined #openstack-keystone15:36
morganfainbergayoung, as in... not thinking about it today :P15:36
* ayoung just planting the seed15:36
*** gokrokve has joined #openstack-keystone15:36
openstackgerritRichard Megginson proposed a change to openstack/keystone: Use mail for the default LDAP email attribute name
ayoungmorganfainberg, so,  basically  I'm OK with the spec. The one reservation I have is that we need a way to communicate how to get tokens from tokens as well.  If I get a token using X509 client cert or Kerberos,  do I need to continue to use that mechanism when converting one token to another?  What about SAML?15:38
morganfainbergayoung, what?15:38
ayoungmorganfainberg, ok...lets take the SAML case15:39
morganfainbergayoung, i'm confused did we just end up in left field?15:39
ayoungmorganfainberg, there are three things an unscoped token with no service catalog can't tell us todya15:39
ayoungtwo are covered by Jamie's spec15:39
morganfainbergoh oh jamie's spec15:39
ayounghow to list projects and how to list domains15:39
morganfainberglike i said, felt like left feild going from tokens -> jamie's15:40
ayoungthe third is how to exchange the token we have for a scoped one, using the info on projects15:40
morganfainbergayoung, i don't think that really changes much with jamie's proposed change15:40
ayoungmorganfainberg,  in my Kerberos work, I have to be able to use the Password mechanism and the Kerberos mechanism for the same Keysteon server15:40
morganfainbergayoung, those changes i see as improvements/further specs15:40
ayoungbut ideally I would not let people using kerberos use the password mechanism15:41
ayoungthis needs to be thought through15:41
*** gokrokve has quit IRC15:41
ayoungstay with me for a moment,15:41
morganfainbergayoung, again don't see how that spec is changing that15:41
ayoungfor each auth url, we should say "what mechanism is supported"15:41
ayoungor mechanisms15:41
ayoungand also, once we have an unscoped token, where do we go to get a scoped token15:41
ayoungI'm npot certain, however, that it needs to be in /auth15:42
ayounglisting mechanism would be like /auth/mechanisms , and that probably should be there15:42
ayounglistting projects and domains, though, probably should be links that become avaialble once you have a token15:42
morganfainbergayoung, back up. if it isn't in /auth where should it go?15:42
ayoungand that doens;t need to be in /auth15:43
ayoungmorganfainberg, I was thinking that the links to where to list project should be in the token response15:43
ayoungthey don't need to be known before getting a token15:43
ayoungif I get an unscoped token, I should get access to the links.  I'm almost thinking that Jamies spec is headed the wrong direction, away from discoverability15:43
morganfainbergso.. it goes wherever we want to stick it.15:44
morganfainbergjust not /auth15:44
ayoungin the response15:44
ayoungleave the currnet /projects and /domains as is15:44
morganfainbergbut... he's saying if you're asking information about your current scope you ask in /auth15:45
morganfainbergso why is it bad to put it there? i'm not clearly seeing the argument against it15:46
ayoungmorganfainberg, it means you have "a-priori" knowledge of where to ask.  Just becasue We do that throughout the API.  doesn't make it right, though.15:46
ayoungI'm not certain it is either necessary nor sufficient15:46
ayoungnot saying "no"  just...suspect it is wrong15:47
ayoungYou shouldn't have to read the spec to figure out what url to use15:47
morganfainbergso, please comment on the spec. it's been lingering and we are kind of at the deadline here. pocket veto wont fly :)15:47
ayoungyou should chain that from the response to figure out where to go.15:47
morganfainbergyou know he doesn't say you can't have those links in the response just that they'd exist in /auth/XXXX not <some ranome place>15:48
morganfainbergbecause it's relevant to auth15:48
morganfainbergcurrent authorization scope, you don't ask /v3/domains "what domains do i have access to"15:49
morganfainbergwith an unscoped token15:49
*** aix has quit IRC15:49
morganfainbergin either case, please comment on the spec, if it needs clarification in your mind, that would be fine - or if it really is headed in the wrong direction15:50
*** HenryG has joined #openstack-keystone15:55
*** jsavak has joined #openstack-keystone16:01
*** aix has joined #openstack-keystone16:02
openstackgerritBob Thyne proposed a change to openstack/keystone: Implementation of Endpoint Grouping
*** joesavak has quit IRC16:04
ayoungmorganfainberg, I left a comment with neither + nor -  .16:07
ayoungI know why he submitted it, as it is a response to this patch of mine:
bknudsonmorganfainberg: do we support a migration directly from havana to juno (keystone-manage db_sync), or is that broken by removing the migrations?16:10
*** cjellick has quit IRC16:11
*** cjellick_ has joined #openstack-keystone16:11
openstackgerritMorgan Fainberg proposed a change to openstack/identity-api: Add information about audit_id in token docs
*** hrybacki has joined #openstack-keystone16:15
*** cjellick_ has quit IRC16:16
morganfainbergbknudson, we should be able to do havana -> juno16:19
morganfainbergbknudson, the collapse was to the last migration of havana16:19
morganfainbergbknudson, so as long as someone used havana release (and nothing wonky was backported) it *should* work16:20
morganfainbergayoung, ++ thanks16:20
bknudsonmorganfainberg: I thought so... but someone here is complaining16:20
morganfainbergwhere is it failing?16:20
bknudson CRITICAL keystone [-] KeyError: <VerNum(35)>16:21
bknudsonmorganfainberg: which I assume means that the migration script isn't present16:21
*** hrybacki has quit IRC16:21
morganfainbergthey should already be on ver3616:21
morganfainbergif they are havana release16:21
bknudsonmorganfainberg: oh, weird.16:21
ayoungthey are on Grizzly16:22
* ayoung guesses16:22
morganfainbergmaybe they were on an RC of Havana?16:22
morganfainbergsomehow missed that last migration16:23
ayoungkeystone-manage db_version16:23
morganfainbergor the last two16:23
*** hrybacki has joined #openstack-keystone16:23
morganfainbergneither would affect keystone runtime (maybe make it a bit slower16:23
* ayoung duh must be 3416:24
*** gokrokve has joined #openstack-keystone16:25
morganfainbergbknudson, the easiest fix is to get an icehouse (or havana) git checkout, setup a venv and migrate to at least 36 before trying the juno upgrade.16:25
morganfainbergit's what metacloud had to do (for nova) when they jumped essex -> grizzly16:26
*** comstud is now known as bearhands16:26
*** gokrokve has quit IRC16:27
bknudsonmorganfainberg: y, maybe migration 36 failed for them and they didn't notice the failure.16:27
morganfainbergayoung, thanks for the comment, that is a bit easlier to read than our conversation, totally get what you're driving at now. :)16:27
henrynashstevemar: sorry, back16:28
stevemarhenrynash, np at all16:29
morganfainbergayoung, i like everything being under /auth, but the links would def. make it clearer.16:29
morganfainbergayoung, anyway, circle back w/ others / jamie first thing next week (or sunday our time)16:29
morganfainbergayoung, see where we land16:29
henrynashstevemar: so I must admit I had imagined (!) that somehow the scope for which the roles were valid where in the assertion16:29
*** hrybacki has quit IRC16:29
ayoungmorganfainberg, I think the key thing is that GET /auth should have links.  The rest is commentary16:29
morganfainbergayoung, yep.16:30
henrynashstevemar: which I realise isn’t very SAML-like16:30
morganfainbergayoung, and i don't disagree in the slightest.16:30
morganfainbergayoung, i think it isn't clear if that was the intention in the spec or not (it may have been)16:30
raildohenrynash: Could you see my last comment on hierarchical projects?16:30
stevemarhenrynash, yeah, that would be the problem, just cause i have adminness on myown system, doesn't mean i have adminness on yours16:30
henrynashstevemar: quite true….but that’s the mapping does16:31
stevemarhenrynash, you have to define the mapping which gives me some measure of authorization16:31
ayoungstevemar, henrynash I've been thinking about Horizon, login, Kerberos and SAML16:31
stevemarhenrynash, i think the only thing i would change is maybe use an unscoped token, and get all the roles a user has16:31
ayoungwhat do you think of this idea:16:31
henrynashayoung: sh*t…with those 4 things on the same line, I’m making a run for it now16:32
stevemarhenrynash, lol wait for me!16:32
ayounginstead of Horizon going to keystone to fetch a token, Horizon uses Javascript to direct the user to Keystone to fetch a token, and the users's browser will then ajax-post it to Horizon16:32
ayoungits in line with marekd|away 's WebSSO approach16:33
morganfainberghenrynash, I'm with you there!16:33
ayoungWell, I have a requirement to support Kerberos from Horizon, and I think this is the simplest way.16:33
ayoungThen i realized it would work for SAML, too16:34
henrynashayoung: so the principle of making Horizon work more in a WebSSO approach I think is good….we really don’t want it tied so tight……I think it kind of shows a godo work ing model16:34
henrynashstevemar: when you say unscoped token…you mean the one we supply to get the assertion, or the when we get in teh SP from the assertion?16:35
ayoungit would require CORS support for non-all-in-one deployments, but I don't think that is a huge barrier.  Swift already has support for CORS16:35
stevemarhenrynash, the first one, one we would supply to get an assertion16:36
henrynashayoung: so I’d have to dig in a look some more to commetn on the deatils of your suggestion…but I like the principle16:36
ayoungIf I understand it correctly, it would work like this:  the Javascript from horizon would have an additional header: Origin: http://horizon16:37
henrynashstevemar: well today, you can’t get an unscoped token that has roles in it16:37
henrynashstevemar: oh you mean you provide taht just to show proof of identity16:37
ayoungand then Keystone will have to respond with  Access-Control-Allow-Origin: http://horizon16:37
stevemarhenrynash, yep, but it's got the user_id, and we could query the backend to get all the roles she has16:37
ayoungwhich implies that horizon should be registered as an endpoint, and then we allow CORS between endpoints.  I think.16:38
stevemarhenrynash, although that would break the 'recursive' model, where a user is ephemeral :(16:38
openstackgerritA change was merged to openstack/keystone: Support the hints mechanism in list_credentials()
ayoungstevemar, why do you need Roles again?16:39
stevemarayoung, to put in the saml assertion16:39
ayoungstevemar, is this for K2K?16:39
stevemarayoung, yep16:39
henrynashayoung: the question is, for K2K federation via SAML, what are the “attribute” we put in it16:39
ayoungOK,  lets start by stating the obvious.  SAML and Keystone PKIZ tokens are just two different marshalling mechanisms16:40
ayoungneither should be able to have info that the other would not have16:40
ayoungit should be based on a scoped token, not an unscoped one16:40
ayoungso instead of /auth/tokens, I go to /auth/saml.   That is all that is different.16:41
*** aix has quit IRC16:41
henrynashayoung: so I raised this since the current spec doesn’t have the scope in it…so you get some roles, but as a consumer I can’t differente betweem to people turning up with “admin” in their assertion UNLESS we are going to treat roel assignments as “global” (which feel wroung)16:41
henrynashayoung: but whatver we do, we need to be able to write some nice mapping rules that make sense of it16:42
afaranhaDoes someone knows how to execute a SQL migrate script? I have this migrate script that seems it is not being executed.16:42
ayoungI still see no reason to use SAML16:43
ayoungit confuses things16:43
morganfainbergraildo, added some comments to the spec16:43
openstackgerritBob Thyne proposed a change to openstack/keystone: Implementation of Endpoint Grouping
morganfainbergraildo, it is looking well rounded, just have some concerns16:43
henrynashafaranha: I think there is alerady a 52 defined16:43
ayoungSAML from our perspective should be limited to "proving" authentication, for limited, suspect values of prooving16:44
ayoungbut that aside16:44
ayoungIf I go t my local keystone, I need a scoped token to do anything outside of keystone16:44
ayoungthat doens't change if I'm doing K2K16:44
henrynashayoung: I think we agreed to use SAML as the K2K payload format16:44
ayounghenrynash, I never agreed16:44
ayoungI must have stepped out of the room, but that idea is not helping.16:45
ayoungMind you, I have nothing against SAML, and love the Idea of Keystone supporting it in general16:45
ayoungjust not that K2K somehow benefits from it16:45
henrynashayoung: eek, I think everyone came away with…and that’s what the juno/spec was approved as16:45
ayoungit reflects, I think, a fundamental misunderstanding16:45
morganfainbergayoung, i'm fairly certain you at least gave some concent to saml at the hackathon16:46
morganfainbergbut it was late in the day that day16:46
afaranhahenrynash:  ah, true, thanks16:46
ayounghenrynash, does that mean I can't expect you guys to give a decent reality check to it16:46
morganfainbergmight have been a lot of cross talk16:46
ayoungmorganfainberg, it really doesn;t matter16:46
ayoungmorganfainberg, I'm OK with SAML, but lets understand it as just a marshalling format.16:46
morganfainbergayoung, i think the choice for saml comes from leeraging the federation code we have and mod_shib16:46
raildomorganfainberg: thanks! I will answer them now16:47
ayoungSAML in general looks like a snapshot of an LDAP query16:47
morganfainbergayoung, was a low barrier to entry with support already in place (in a good way)16:47
ayoungmorganfainberg, ah...but...16:47
* ayoung just had epiphany16:47
ayoungok ,token pipeline16:48
ayoungwe've discussed that alot16:48
henrynashayoung: OK, let’s make it general….should the K2K payload passed include the roles a user has on the scoped entity to get this payload, along ith info on the scope taht was used16:48
morganfainbergand we'll keep discussing it :) until we get there.16:48
ayoungthink of it this way:  there is the unmarshall stage...apache does that for Kerbers and SAML, but Keystone does it for Token to Token exchanges16:48
morganfainberghenrynash, i don't *think* it would work like that, it would work like current federation, attributes (maybe the roles are used) are mapped to the group on the remote end16:49
ayoungso  for K2K,  lets say for arguments sake that we accept both16:49
ayoungthe end product is a set of GROUPS16:49
ayoungif we were to use mod_auth_identity, it would be REMOTE_GROUPS.  lets just use that as shorthand16:49
henrynashayoung: I never said the roles were passed through unmodified…I agree they are jsut an attribute to be mapped at will by the SP receiving the payload16:50
ayounghenrynash, right, I 'm with you16:50
ayoungthe disconnect is groups (flat) versus role-in-project16:50
ayoungso I thnk the SAML approach was assuming that the exporting keystone would flattend the role assignments somehow16:51
ayoungbut it really doesn't matter who does it16:51
ayoungwe need a way to convert a role assignment to a group.16:51
morganfainbergayoung, so you're saying project:role is required? and that maps to the group on the other end?16:51
ayoungmorganfainberg, absolutely16:51
ayoungor domain16:51
ayoungthere can be additional roles assigned on the other end16:51
morganfainbergdomain:role same thing, in this convo :)16:51
henrynashayoung: the disconnet is: i supply a tolen scoped to project X to get my asserton..which is built with just teh roels/groups I have on project X……but (as spec’d today) no idea of project X is put in the assertion16:52
ayoungits only if you want to have roles on the remote side based on roles on the local side16:52
ayounghenrynash, its similar to the userid mapping issue you just resolved16:52
henrynashayoung: so if am the SP receiving these assertions: two users claim to be in group/role “admin”…but they were for very different entities16:53
ayounglet me try that again16:53
ayoungadmin  should not come through.16:53
ayoungif I have admin on the demo project I could make a group  demo-admin16:53
ayoungnow, we have the same issues as the ID mapping about parsing16:53
ayoungso...we could hash, just like before.16:53
morganfainbergayoung, i think you're thinking from the perspective if roles mapped 1:1 local to remote, they don't16:54
ayoungso  the group in the SAML assertion would be sha256(project, role)16:54
ayoungmorganfainberg, we can also do16:54
ayounguser always gets a group sha256(project)16:54
ayoungor just project if we don't care about consistnaacy16:54
morganfainbergayoung, on which side?16:55
morganfainbergayoung, i'm lost now16:55
ayoungmorganfainberg, this is one reason that I prefer the keystone token format to SAML.  Lets assume that for the moment16:56
morganfainbergayoung, it sounds to me like you're saying the remote end automatically has a group for user based on the idp16:56
*** nkinder has quit IRC16:56
openstackgerritA change was merged to openstack/keystone: Issue multiple SQL statements in separate engine.execute() calls
*** aix has joined #openstack-keystone16:56
morganfainbergayoung, the confusion wouldn't change with a token vs saml16:56
morganfainbergayoung, as far as i can tell16:56
ayoungif I have a token with  {proejct: demo, role:admin}  coming from my keystone, and I hand it to your keystone,  your keystone can then map that to a group however it likes.16:56
morganfainbergyou'd still not be able to use that token for anything *really* and have to map it to something local16:56
ayoungand...dchadwick would point out, that the groups were not how they wanted to do mapping in the first place16:57
morganfainbergno different than what we do with saml and federation16:57
ayoungyou could instead map incoming project-role to outgoiung project-role16:57
morganfainbergand you'd still need to issue a new token for the remote cloud16:57
ayoungmorganfainberg, yep16:57
morganfainbergso... we need to add extra attributes to act on in the k2k saml assertion... is what i'm getting out of this?16:58
ayoungmorganfainberg, the difference is which keystone does the mapping in the  K2K exchange16:58
morganfainbergthe remote one always does the mapping16:58
morganfainbergthe local one cannot since it doesn't know anything about the remote cloud16:58
henrynashayoung: so all I was say (which is actually I think agreeing with ayoung) is that we shouldn’t lose scope information when we crreat the SAML assertion….so we need some mechanism of including it16:58
morganfainbergin both caes.16:58
ayoungmorganfainberg, actually, we should look into the saml format, and see if it has a way to represnt the role intact.  I bet it does16:59
ayoungI'm guessing SAML accounted for RBAC16:59
morganfainbergayoung,  the remote end still needs to do the mapping.16:59
ayounghenrynash, so, first off lets see if there is a clear way to persist the current keystone token data in SAML16:59
morganfainberghenrynash, yeah i think we need to include the scope data / roles as attributes so they can be acted on16:59
henrynashmorganfainberg: ++17:00
morganfainberghenrynash, it should be able to be done as attributes is my guess17:00
ayoungif there is, then SAML vs Keystone token is irrelevant17:00
ayoungit may mean, however, that we need to expand the scope of what the mapping mechanism accepts17:00
ayoungright now it accepts a list of groups,17:00
henrynashayoung: agreed….and I think teh point of using SAML would be that its nice not to invent our own federation assertion…we’ve been accused on re-inventing the wheel enough already17:01
ayoungproject-role could be represented that way, but it is ugly17:01
morganfainbergayoung, it can only map to groups, but it accepts any attrinutes17:01
morganfainbergayoung, iirc17:01
ayoungmorganfainberg, ah17:01
ayoungthen I think we are ok....we could, in theory, also let it map directly to role-project for certain domains, and it would avoid a lot of duplication of data, but that can come later17:01
*** openstackgerrit has quit IRC17:02
*** openstackgerrit has joined #openstack-keystone17:02
morganfainberghenrynash, ++++++++++17:02
* morganfainberg needs breakfast =/17:02
ayoungit also means we can stop treating Keystone tokens as different from any other mechanism17:02
henrynashnneds dinner17:02
morganfainberghenrynash, hows that side of the pond today?17:03
henrynashayoung: agreed17:03
ayoungtoken for token would be handled the same regardless of where the token came from.  Hmmmm17:03
henrynashmorganfainberg: sunny and showers…..17:03
morganfainberghenrynash, nice17:03
henrynashsunny now…so runninng to grab dinner17:03
morganfainberghenrynash, have a good dinner!17:03
*** harlowja_away is now known as harlowja17:03
morganfainbergayoung, it does open up a number of doors we can expand on17:04
ayoungmorganfainberg, ok , I have a book with a bit about SAML in it right here..  This is an example from it17:07
* ayoung types in17:07
*** nkinder has joined #openstack-keystone17:08
ayoung <saml: AttributeDesignamtr AttributeName="username"  AttributeNamesapce="">17:08
ayoungugh, that was from the request...ok17:09
ayoungfrom the response17:09
*** htruta has joined #openstack-keystone17:10
ayoung<saml: Subject><saml: NameIdentifier SecuirytDomain=""  Name=joe.bloggs" />  <saml: Subject/>17:10
ayoungI would think that, in our case, the secuiryt domain would be  something like17:11
openstackgerritBob Thyne proposed a change to openstack/keystone: Implementation of Endpoint Grouping
ayoungand then Role...17:12
ayoung  is the one from my company that I somewhat modified for an example17:12
openstackgerritBob Thyne proposed a change to openstack/keystone: Implementation of Endpoint Grouping
*** hrybacki has joined #openstack-keystone17:19
*** aix has quit IRC17:23
*** hrybacki has quit IRC17:23
*** shakamunyi has joined #openstack-keystone17:24
*** jorge_munoz has quit IRC17:26
*** aix has joined #openstack-keystone17:36
*** shakamunyi has quit IRC17:43
*** shakamunyi has joined #openstack-keystone17:57
bknudsonmorganfainberg: looks like there were some migrations added since the original stable/havana?18:01
raildomorganfainberg: I answered your comments if you can look :)18:02
*** amcrn has joined #openstack-keystone18:03
*** aix has quit IRC18:05
bknudsonmorganfainberg: 2 migrations were added in 2013.2.2 ... so you can upgrade from 2013.2.2 to juno but not from 2013.2.1 or 2013.218:11
openstackgerritRodrigo Duarte proposed a change to openstack/keystone: Add parent_project_id field
openstackgerritRodrigo Duarte proposed a change to openstack/keystone: Base methods to handle hierarchical projects
openstackgerritRodrigo Duarte proposed a change to openstack/keystone: Create, update and delete hierarchical projects
*** zzzeek has joined #openstack-keystone18:15
*** jorge_munoz has joined #openstack-keystone18:31
rodrigodsquick question: when we request to keystone return in a XML format, is there any place where the json is parsed? Or it's used some kind of lib that does the job?18:33
rodrigodsjust found middleware.XmlBodyMiddleware =)18:45
ayoungraildo, what about if, instead of "root":"openstack"   we called it "installation"  and, while it could have any string as the name, it got a UUID?18:48
richmhello - I'm working on adding unit tests for deleteTree for
ayoungrichm, thanks18:48
ayoungrodrigods, that is such a hack18:48
ayoungI had a "contentt type:" middleware which is really what we need, to replace JSON and XML middlewares18:49
richmI thought I would create a subclass of FakeLdap that would override delete_s and delete_ext_s - this would check for children of the given dn and throw ldap.NOT_ALLOWED_ON_NONLEAF18:50
richmhowever, I'm not sure where to add the tests to use the new class18:50
ayoungrichm, ldap_identity tests, I suspect, is the right place18:51
ayoungrichm, you mean that there is not general LDAP unit tests?18:51
richmI thought about subclassing LDAPIdentity in test_backend_ldap18:51
ayoungrichm, would you want those tests run against a live server too?18:52
richmbut if I do that, would running the test suite execute every test method in the parent class, then again in the subclass?18:52
richmayoung: right, that's another concern18:52
richmI would prefer to just write a very specific unit test that would exercise the various code paths in the deleteTree method18:52
ayoungrichm, so the issue is that these tests should use a different subclass of FakeLDAP.  But that logic would not be the same for the live test18:52
richmthe live test already fails18:53
richmbecause e.g. openldap does not support deleteTree18:53
ayoungI'd to it inside of ldap_identity, and have a method that gets called from the test to swap the FakeLDAp18:53
ayoungthen, onlive tests, that function is a no-op18:53
raildoayoung: no, it's just a string18:53
ayoungraildo, Federation.  K2K18:53
openstackgerritA change was merged to openstack/python-keystoneclient: Add oslo.utils requirement
openstackgerritA change was merged to openstack/python-keystoneclient: Use oslo.utils
richmayoung: ok - I thought that might be sort of ugly (== -1 review)18:53
ayoungrichm, necessary ugliness18:53
richmmy favorite kind18:54
openstackgerritBrad Topol proposed a change to openstack/keystone: Add audit support to keystone federation
ayoungrichm, you could make that call on the live tests check to see what ldap is being used, and skip if openldap, or better yet18:54
ayoungskip if the control is not supported on the server18:54
ayoungmake the call something like delete_specific_setup18:55
richmok - I'll also have to add support to FakeLdap to query the rootDSE supportedControls18:55
ayoungrichm, you sure about that?18:56
richmeither that, or the caller will have to do something like this:18:56
ayoungrichm, actually, that is good18:57
raildoayoung: sorry but I did not understand the relationship with root project: openstack in hierarchical projects --- federation and K2K18:57
ayoungraildo, sorry, too many convos at once.  I get incoherent18:57
richmif isinstance(obj, FakeLdap): use subtree delete18:57
ayoungmore incoherent than usual18:57
richmelif isinstance(obj, FakeLdapNoSubtreeDelete): do not use subtree delete18:57
ayoungrichm, OK, I think that is the right approach. And we can set FakeLDAP to both support and not support.18:57
raildoayoung: hahaha no problem18:57
richmelse obj.search_s("", ...)18:58
ayoungIf not supported, the test will run the same for Fake and Live...18:58
ayoungsame with supported18:58
ayoungrichm, so on live, you have two tests, one of which would always be skipped based on whether or not the server supported the control18:58
ayoungraildo, ok...BACK TO YOU18:59
ayoungraildo, if I want to see the whole Heirarchy,  I start with root.  If every installment has "openstack" as root, there is no way to compare two different installments18:59
ayoungideally root would be the name of the organization hosting the cloud18:59
ayoung so "rackspace" , or "HP"19:00
ayoungraildo, and...if an organization wants to do it right, they could do this19:00
ayoungsay rackspace wants to do a private cloud and a public cloud in two unlinked datacenters19:00
raildothats make sense19:01
ayoungthey make root for one "rackspace public" and the other "rackespace private"  then, later, when they decide to put them in the same,  the yroot it with "rackspace joint"19:01
ayoungand each project bumps one level deeper in the hierarachy, but everything else stays the same19:01
ayoungand, to make sure that two companies don't sit on the same name, like "test lab"19:02
ayoungyou actually distinguish between them with a uuid, like we do for everything else19:02
ayoungraildo, you like that?>19:02
raildoayoung: I liked a lot of your vision.19:03
ayoungraildo, its cuz I had LAZIK19:03
raildoayoung: that is why you are part of the core keystone and I do not hahaha19:03
raildoLasik -> vision -> keystone  core19:05
*** henrynash has quit IRC19:08
* ayoung mike drop19:16
* ayoung dropped mike on bare foot. Is likely now to look big toenail19:17
afaranhaHello, does someone knows how can I execute a SQL migrate script? Is it automatically executed when I restart Keystone service?19:28
morganfainbergbknudson, ugh, we backported things to havana in a wierd way then19:29
bknudsonafaranha: keystone-manage db_sync19:29
morganfainbergbknudson, :(19:29
bknudsonmorganfainberg: y, I think we need to move havana back a couple of changes19:29
bknudsonmove the havana marker back to 3419:30
morganfainbergbknudson, lets get a bug filed i'll get that brewed up early next week or on sunday19:30
bknudsonshouldn't be impossible or be incompatible19:30
bknudsonmorganfainberg: I filed a bug...19:30
uvirtbotLaunchpad bug 1357498 in keystone "Can't upgrade from 2013.2 or 2013.2.1 to Juno" [Undecided,New]19:30
morganfainbergbknudson, i *thnik* it'll just be moving 036_havana to 034_havana and re-adding those two migrations19:30
morganfainbergand making sure they are idempotent19:31
morganfainbergminimal work.19:31
bknudsonmorganfainberg: y, that's what I was thinking.19:31
afaranhabknudson: Thanks, I'll try that19:31
morganfainbergbknudson, cool. i'll see if i can get that rolled up this weekend and tag you on it19:31
morganfainbergunless someone else beats me to it :P19:31
bknudsonmorganfainberg: I might take a look at it since I've got people asking about ti19:32
morganfainbergbknudson, let me know if you get it done, happy to review it.19:32
dolphmanyone know if (i think dstanek's) xml matcher redux landed in master?19:33
morganfainbergbknudson, in either case i expect it'll be ready for review on monday19:33
morganfainbergdolphm, hm. i *think* it did, but... let me check19:33
morganfainbergdolphm, this one?
dolphmmorganfainberg: yep!19:34
morganfainbergdolphm, not landed, but def on the way19:34
dolphmmorganfainberg: i'd like to backport that to icehouse as well19:34
morganfainbergdolphm, ++19:34
ayoungstevemar,  is for splitting the ID backend off the rest of keystone, right?19:35
ayoungAlso for K2K, maybe, but with no role info in the token?19:35
morganfainbergraildo, ok so responded to your comments. i added a -1, lets look at that security concern and add any clarification needed for henry's comments and notifications. but i really think the major issues have been addressed in the spec19:42
morganfainbergraildo, thanks for the quick response on it!19:42
morganfainbergraildo, the -1 is only really because of the security concern, if you have a good answer to that i'll reverse the scoring19:44
morganfainbergdolphm, before i dive into code, anything else to talk about for pycadf?19:44
dolphmmorganfainberg: oh yeah!19:44
* morganfainberg is hoping to get a patch for revocation events to use audit ids done in the next hr or so. (and corresponding identity-api change)19:45
dolphmmorganfainberg: first, stable backport:
raildomorganfainberg: Thanks for the reply, I will respond as soon as possible19:45
morganfainbergraildo, ++ i'm ducking out in a couple hours, but i'll look at your responses tonight at the latest19:45
morganfainbergdolphm, clean cherry-pick ?19:45
dolphmmorganfainberg: no19:45
dolphmmorganfainberg: we switched from io to six.io19:46
morganfainbergthats too bad :P makes it easier. ok looking at the two reviews19:46
dolphmmorganfainberg: rebased around that, and some other import change19:46
* morganfainberg nods.19:46
dolphmmorganfainberg: so, i agree descriptors are a really cool pattern, but i think it's far from being the most easy to read, low maintenance solution for the problem that pycadf is solving19:47
dolphmmorganfainberg: before i continued further in switching to json schema, i wanted to stop and ask if you saw any value in maintaining the descriptor approach instead19:48
morganfainbergdolphm, i'm 100% sure the descriptor approach is way cooler than jsonschema, but i agree it's hard to read19:48
dolphmmorganfainberg: nevermind cooler, do you think it's better19:49
dolphmmorganfainberg: there are improvements to be had without switching to jsonschema19:49
morganfainbergdolphm, i think from a strict maintainablility standpoint (and readability) jsonschema makes more sense19:49
dolphmthat's what i care about more in open source19:50
morganfainbergdolphm, which is my biggest concern. performance differences should be negligible19:50
morganfainbergto get all the benefits of the descriptor pattern and none of the negatives we can add __setitem__ that does a .valid check on each set once initialized19:50
morganfainberg(or even make that optional)19:50
dolphmbut you need that for *every* attribute, right?19:52
morganfainbergdolphm, __setitem__ is a dict magic method, so it would occur when you did something like cadf_obj['thing'] = value19:53
dolphmor you mean setattr19:53
morganfainbergif you did something like that19:53
dolphmoh ok19:53
openstackgerritSteve Martinelli proposed a change to openstack/identity-api: Add SAML generation route to OS-FEDERATION
morganfainbergsame thing can be done with __setattr__ but it gets a bit more wonky with lots of super calls to not break things in cases.19:53
dolphmwell that was my other motivation to just switch to jsonschema - cadf events are just json, so i'd rather the datatype more closely reflect that19:53
morganfainbergdolphm, descriptors are better in only one real clear way, you have more control over individual properties and how they act (can validate them in all sorts of magic ways) since each attribute is it's own descriptor class19:55
morganfainbergdolphm, i don't think we're losing much (if anything) moving to pure jsonschema like you're doing. and we are gaining a lot in readability19:55
dolphmmorganfainberg: and most of the validation is basically isinstance-basestring and maybe is-not-none19:55
morganfainbergdolphm, net win in my book19:55
openstackgerritayoung proposed a change to openstack/python-keystoneclient: Enumerate Projects with Unscoped Tokens
morganfainbergdolphm, ++19:55
dolphmalright, i'll keep it up then19:56
morganfainbergdolphm, and yes i am still volunteering to be core on pycadf if you need volunteers. otherwise i'm content to review the code and +1 as appropriate19:56
morganfainbergdolphm, unrelated - stable backport looks really clean. super simple conflict19:56
morganfainbergjust 2x checking the tests19:57
*** chmouel has quit IRC19:57
*** chmouel has joined #openstack-keystone19:58
openstackgerritAndreas Jaeger proposed a change to openstack/identity-api: Add SAML generation route to OS-FEDERATION
*** hrybacki has joined #openstack-keystone20:02
morganfainbergdolphm, you might need a __setattr__ to convert pycadf.ATTR = thing  to the dict model, i'm not sure if people directly set attributes on a pycadf object or if they just do a .to_dict() then thing[key] = value20:04
*** jsavak has quit IRC20:06
*** bknudson has quit IRC20:09
*** notmyname has quit IRC20:10
*** chmouel has quit IRC20:10
*** notmyname has joined #openstack-keystone20:11
morganfainbergdolphm, ooh i think we need to cleanup our specs page... we still have some templates rendered in there >.>20:15
morganfainbergdolphm, "Template": and "Client"20:15
openstackgerritayoung proposed a change to openstack/keystonemiddleware: Hash for PKIZ
*** chmouel has joined #openstack-keystone20:15
morganfainbergtemplate might be fine.20:15
openstackgerritMorgan Fainberg proposed a change to openstack/keystonemiddleware: Hash for PKIZ
morganfainbergayoung, ^ fixed typo in commit20:16
morganfainbergooh thats kindof a nasty bugger.20:16
dolphmmorganfainberg: there are set_ methods on a couple objects20:17
morganfainbergdolphm, ah20:17
morganfainbergdolphm, haven't gotten all the way through the review yet.20:17
dolphmmorganfainberg: it's still WIP20:17
ayoungmorganfainberg, dolphm should I submit that  PKIZ hash fix to keystone client as well?20:17
morganfainbergdolphm, ack.20:17
morganfainbergayoung, is it a security fix?20:17
morganfainbergayoung, then i'd say answer is no20:18
morganfainbergayoung, not sure if we can test this. but we might want to add a test for this one.20:19
dolphmayoung: it's just a performance fix?20:19
morganfainbergdolphm, it's a we'd have a cache miss everytime on pkiz tokens (so yes)20:19
ayoungjust performance20:19
dolphmayoung: the bug report is for something different then? "that should make token revocation for PKIZ tokens broken"20:20
dolphmayoung: that's why i marked it critical20:20
ayoungah...lets see...if the hash is not done, then it will fall back to...20:20
ayoungoh, the revocation list....20:20
ayounghmmm...not sure how to test that.  But yeah, if a token was cached, the revocation check would not match it20:24
morganfainbergayoung, i think brant has a test for that when he redid some of the cache stuff20:25
morganfainbergayoung, i think just need to funnel a pkiz token through20:25
*** nkinder has quit IRC20:26
ayoungmorganfainberg, there is a test test_cached_revoked_pki(sel20:26
ayoungI can dupe for pkiz20:26
morganfainbergayoung, perfect, should do that if you don't mind20:27
*** ajayaa has joined #openstack-keystone20:29
ajayaaayoung, hi!20:29
openstackgerritayoung proposed a change to openstack/keystonemiddleware: Hash for PKIZ
ayoungmorganfainberg, I'm going to submit that toe KC as well20:30
dolphmayoung: add keystoneclient to the bug first20:31
dolphmwe should probably add OSSA too20:32
openstackgerritayoung proposed a change to openstack/keystonemiddleware: Hash for PKIZ
ayoungdolphm, should I remove "affects Keystone?"20:33
morganfainbergayoung, ++ yes security (please mark it as a securityimpact)20:33
morganfainbergor.. do we mark it securityimpact?20:33
morganfainbergin either case yes, security20:34
dolphmmorganfainberg: the patch should be SecurityImpact, yes20:34
dolphmayoung: if it doesn't affect keystone (i wasn't sure), remove it there20:34
ayoungdolphm, , that is Security-Impact:  in the commit message, right?20:36
morganfainbergayoung, SecurityImpact20:36
openstackgerritayoung proposed a change to openstack/keystonemiddleware: Hash for PKIZ
*** david-ly_ has joined #openstack-keystone20:43
openstackgerritayoung proposed a change to openstack/python-keystoneclient: Hash for PKIZ
ayoungcan you guys expedite those?20:44
*** david-lyle has quit IRC20:45
dolphmayoung: this looks like a valid fix, but i don't see how it addresses the concern in the bug about revocation20:50
*** henrynash has joined #openstack-keystone20:50
*** rwsu has quit IRC20:51
morganfainbergdolphm, i *think* the .get() (which does the hash check) is responsible for hashing the ids which then get passed to the verifynot revoked code20:52
morganfainbergdolphm, /me is still looking20:52
*** hrybacki has quit IRC20:54
dolphmmorganfainberg: if i'm reading it correctly, a cache miss results in it falling into verify_pkiz_token() with the original unhashed token and checking the revocation list anyway20:55
dolphmand holy crap the revocation check has a for loop in it that runs on every check20:56
morganfainbergdolphm, the .get does the hashing and returns out at line 141120:56
*** bknudson has joined #openstack-keystone20:56
raildomorganfainberg: I answered your comments there, if you can take a look :D thanks20:56
*** bknudson1 has joined #openstack-keystone20:57
dolphmmorganfainberg: correct, but the previous behavior was that PKIZ tokens would skip that block20:57
morganfainbergso, this fixes the bug, if i'm reading it right20:57
dolphmmorganfainberg: so you get a cache miss, and the return value of that method is (full_plaintext_pkiz_token, None), right?20:57
morganfainbergno you still get a list of [cms.hash for algo in hashing_algorithms]20:58
morganfainbergyou get ([hash, ...], None) back20:58
dolphmmorganfainberg: no, previously it never went into that if block20:58
morganfainbergthe None is if it was a cache hit20:58
dolphm([full_plaintext_pkiz_token], None)20:58
morganfainbergright previously, the TRL never contains the complete full_pkiz_token_id20:59
dolphmuser_token == full_plaintext_pkiz_token == token_id20:59
dolphmmorganfainberg: and look at where _token_cache.get() is called20:59
morganfainbergdolphm, in _validate_user_token21:00
*** bknudson has quit IRC21:01
morganfainbergPKIZ tokens were validated correctly,21:01
dolphmgod this is confusing21:01
morganfainbergPKI tokens were falling back to UUID-form21:01
morganfainbergthis fixes the cache hit-scenario but makes it so we live-validate PKI(Z) tokens 100% of the time21:01
dolphmwait really21:01
morganfainbergarguably, that is *not* a security hole, just a crappy performance21:01
morganfainbergyep, because is_pkiz and is_pki will fail on the hashed token21:02
morganfainbergso, .get is called and returns ([hash], None)21:02
* morganfainberg walks through this21:02
morganfainbergwe set token_id to [hash][0]21:03
morganfainbergahhh no we're ok21:03
morganfainbergwe do is_pki / is_pkiz on user_token not token_id21:03
*** elmiko is now known as _elmiko21:03
dolphmright, that's part of the super confusingness21:04
*** hrybacki has joined #openstack-keystone21:04
morganfainbergthen we pass user_token and the token_id list to _verify_signed_token21:04
morganfainberg(in a cache_miss)21:04
dolphmbut we're basically calling self._verify_pkiz_token(user_token, [user_token]) -- right?21:04
*** david-ly_ is now known as david-lyle21:05
morganfainbergwhich the fix ayoung provided solves. it makes pkiz tokens get hashed as expected21:05
morganfainbergso it becomes self._verify_pkiz_token(user_token, [hash])21:05
morganfainbergwhich is how is_signed_token_revoked expects it to work21:05
dolphmand then _is_signed_token_revoked([hash]) with the fix21:05
dolphmholy crap21:06
ayoungdolphm, yes.  Holy Crap.  I never wanted to do revocations for PKI tokens in the first place.  And then the complexity of multiple hash algorithms made it worse.21:07
*** radez is now known as radez_g0n321:07
morganfainbergthe really confusing part is that the cache.get does the hashing as a side effect21:07
dolphmayoung: someone -1'd btw21:08
ayoungdolphm, legit?21:08
morganfainbergwe should yank that bit out into a clearer function. i think that would be the easiest way to make it a bit more clear21:08
dolphmayoung: i don't know, my brain is fried21:08
dolphmayoung: my inline comment is a half reply to their -121:08
dolphmayoung: you tell me21:08
*** spandhe has joined #openstack-keystone21:09
ayoungI think he's just wrong21:09
ayoungit explicitly is in _TokenCache.get21:09
morganfainberglet me re-read the bug21:09
ayoungand it is what identifies that a PKIZ token should be hashed21:10
ayoungreally, we should go back to the minimum length approach:21:10
ayoungany tokens longer than a sha256 should be hashed.21:10
ayoungthat would avoid the issues with different token formats21:10
ayoungbut I would say that is a larger change than this21:10
morganfainbergayoung, actually any token longer than sha256 will fail in keystone21:11
morganfainbergayoung, but that is def a different story21:11
morganfainbergdolphm, i think the -1 is the same confusion we just had21:12
dolphmmorganfainberg: but i'm happy to entertain a request for more test coverage lol21:12
morganfainbergexcept.. can self._TokenCache be something from swift?21:12
morganfainbergas in *not* our code that does the tokencache logic21:13
ayoungI still suspect this was just a performance issue. I don;t think a PKIZ token would ever have been hashed,  thus never been cached. Which means if it was submitted a second time, it would have gone through the whole unpack, check signature, and check revocation list that way21:13
morganfainbergayoung, you'd never match in the TRL is the issue21:14
ayoungmorganfainberg, actually I would.  It was checked else whre21:14
ayoungI'll link21:14
morganfainbergayoung, for a PKIZ token, because you'd be looking for the user_token string in the TRL (we don't put it in there)21:14
morganfainbergoh we're double duty on the TRL check?21:14
dolphmayoung: what's the pkiz equivalent of cms.cms_hash_token21:14
ayoungmorganfainberg, that was only for the cache case21:14
morganfainbergdolphm, the same thing.21:15
ayoungdolphm, they hash the same way21:15
morganfainbergdolphm, cms.cms_hash_token works for asn1 and pkiz21:15
ayoung cms.cms_hash_token  hashes anything21:15
morganfainbergah ok yeah token_Cache is always our code21:15
dolphmayoung: your patch is *way* behind master btw21:16
ayoungdolphm, ugh21:16
openstackgerritDolph Mathews proposed a change to openstack/keystonemiddleware: Add test for revoked PKIZ tokens in TRL
dolphmayoung: fixed21:16
ayoungmorganfainberg, OK,  even if it was cached, it would not have been identified as cached21:16
ayoungmorganfainberg, so the check happens...21:16
dolphmayoung: this test fails when run on top of your patch - why?
notmynameFYI swift team (portante and acoles and peluse) just clicked approve on v3 auth support for swiftclient
morganfainbergdolphm, the id might not be in the TRL it has21:17
ayoungmorganfainberg, revocation list was checked here
dolphmnotmyname: yay!21:18
ayoungdolphm, looking21:18
dolphmmorganfainberg: it fabricates a TRL21:18
morganfainbergayoung, yes, but the token_ids it's using is [full_user_token_id]21:18
morganfainbergayoung, which would not be in the TRL21:19
morganfainbergayoung, because the hashing would have failed.21:19
ayoungmorganfainberg, um..no21:19
dolphmmorganfainberg: are you talking about my test there^21:19
morganfainbergdolphm, possibly21:19
dolphmmorganfainberg: lol21:20
ayoungmorganfainberg, the hashing happens on a different code path21:20
morganfainbergdolphm, i'm talking about adam's fix and PKIZ without it was not being checked against the TRL21:20
dolphmit fabricates the TRL but it also calls auth_token with X-auth-token = hashed_token21:20
morganfainbergayoung, the hashing happens in token_cache.get() as a side-effect21:20
morganfainbergayoung, it *used* to happen elsewhere21:20
ayoungthat is wrong21:20
*** nkinder has joined #openstack-keystone21:21
morganfainbergtoken_ids is a result of token_cache.get()21:21
ayoungyep, I see it now21:21
* ayoung gonna git blame that one21:21
morganfainbergit's probably 2-3 levels of refactoring back21:21
morganfainbergjust as a headsup21:22
ayoungI have to go pickup my son21:22
morganfainbergdolphm, ah21:22
morganfainbergdolphm, didn't see if fabricating the TRL21:22
morganfainbergdolphm, ooooh i see line 71121:22
morganfainberghow does this test work21:28
dolphmmorganfainberg: ?21:28
morganfainbergthis looks like it should fail on that same check in the PKI version21:29
morganfainbergthe wray it's written21:29
morganfainberglooking at your test21:29
dolphmthe calling once with a hashed version to populate the cache, and then calling with the full version is... odd21:30
morganfainbergits to check that hashing works21:30
morganfainbergit's not straight forward though :(21:30
morganfainbergi don't see how it's valid since you already put the token in the TRL a few lines before21:30
dolphmyeah, they should both be 40121:31
dolphmit's like it's asserting a vulnerability21:31
morganfainbergok maybe the PKI one is doing something dumb...21:32
dolphmi changed one line21:32
morganfainbergi dunno. this is making my head hurt21:34
morganfainberg... OH.21:34
morganfainbergshort-hash doesn't check TRL21:35
*** amcrn has quit IRC21:35
morganfainbergshort hash has to ask keystone *anyway*21:35
morganfainbergso keystone would bounce the token if it was invalid not the TRL when checking by the hashed form21:36
openstackgerritDolph Mathews proposed a change to openstack/keystonemiddleware: added FIXME to PKI cache+TRL test
dolphmi need to run, but ^21:37
dolphmoh that's terrible21:37
dolphmamend my commit with an explanation lol21:37
dolphmi need to run; happy weekend!21:37
morganfainbergdolphm, sure. i need to bail soon as well21:38
morganfainbergbeen looking at code since 645am my time21:38
ayoungwhich check failed?21:41
morganfainbergayoung, dolph's new one
ayoungmorganfainberg, the last check?21:41
ayoung# Should find the token in the cache and revocation list.21:41
ayoung        self.assertEqual(401, self.response_status)21:41
morganfainbergno the one on 71921:42
morganfainbergit gets a 401 on that one21:42
ayoungoh...he revoked it already21:42
ayoungthat test is wrong.  I'd do it like this:21:42
morganfainberglook at the test above21:42
morganfainbergthe PKI version works21:42
ayoungtest a pki token is valid.  That puts it in the cached.  Then check by passing just the hash to auth_token21:43
ayoungnah, wait21:43
ayoungthat is a different code path21:43
morganfainbergthe hashed form shouldn't check TRL21:43
morganfainbergkeystone should bounce it (hence it's valid in short form)21:43
morganfainbergand should be 20021:43
ayoungyeah, just revoke between the two checks21:43
morganfainbergthat doesn't explain why the PKI one works and PKIZ one doesn't21:44
ayoungthe hashed form checks the TRL if there is a certain flag enabled21:44
morganfainbergthere is a 1 line difference tbween the tests21:44
morganfainbergif one fails so should the other21:44
morganfainbergor we have some kind of divergent code path being really weird21:44
morganfainberganyway i am brain fried. need to stop looking at this for a bit21:45
ayoungmorganfainberg, I'm disappearing for the weekend.  I'll bring my machine with me, but...well I'll be in the middle of Lake Champlain.21:47
ayoungthe 200 is wrong, though.  That should be revoked.  Revocation is checked everytime21:48
ayoungmorganfainberg, maybe something is stateful with if self.check_revocations_for_cached:21:49
morganfainbergyeah i'll dig around it a bit later21:52
morganfainbergi need to bail as well21:52
morganfainberghave a good weekend dude21:53
*** henrynash has quit IRC22:00
bknudson1ayoung: watch out for Champ22:01
bknudson1the lake champlain monster22:01
*** ajayaa has quit IRC22:03
*** jorge_munoz has quit IRC22:04
*** nkinder has quit IRC22:14
*** nkinder has joined #openstack-keystone22:14
*** topol has quit IRC22:23
openstackgerritSteve Martinelli proposed a change to openstack/keystone: Add notifications for role assignment created and deleted events
*** shakamunyi has quit IRC22:30
openstackgerritBob Thyne proposed a change to openstack/keystone: Implementation of Endpoint Grouping
*** zzzeek has quit IRC22:41
*** stevemar has quit IRC22:49
spandheHi folks.. I see some conversion going on regarding token caching. I observed some weird behavior in my setup and hence opened a bug:
uvirtbotLaunchpad bug 1357567 in python-keystoneclient "auth_ref caching/retrieving is failing - user needs to provide password for every command" [Undecided,New]22:50
*** amcrn has joined #openstack-keystone22:51
spandhecan someone please take a look at it and check for validity of it - in case I am doing something wrong?22:51
nkinderI'm seeing a really weird gate failure with a stable.icehouse backport -
nkinderkeystone fails to start because it can't do an 'import utils'22:58
nkinderis this something related to a newer keystoneclient getting pulled in?22:58
nkinderevery test fails due to this failed import that is done by keystoneclient -
*** gordc has quit IRC23:04
*** ayoung has quit IRC23:06
*** rwsu has joined #openstack-keystone23:06
*** morganfainberg is now known as morganfainberg_Z23:07
bknudson1nkinder: .tox/py27/bin/pip install oslo.utils23:11
bknudson1nkinder: maybe we should back out the changes to keystoneclient to use oslo.utils.23:12
*** david-lyle has quit IRC23:13
bknudson1stable/icehouse & havana will need updates to requirements.txt to add olso.util23:13
*** zzzeek has joined #openstack-keystone23:16
*** zzzeek has quit IRC23:21
*** rwsu has quit IRC23:35
*** shakamunyi has joined #openstack-keystone23:51
*** zzzeek has joined #openstack-keystone23:56
openstackgerritMonty Taylor proposed a change to openstack/python-keystoneclient: Remove lxml as a forced depend

Generated by 2.14.0 by Marius Gedminas - find it at!