18:00:44 #startmeeting keystone 18:00:45 hi 18:00:45 Meeting started Tue Jan 7 18:00:44 2014 UTC and is due to finish in 60 minutes. The chair is dolphm. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:45 #topic Reminder: Hackathon January 15-17th @ Rackspace in San Antonio, TX 18:00:46 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:48 The meeting name has been set to 'keystone' 18:00:51 NEXT WEEK ^^ 18:00:54 yay! 18:00:59 o/ 18:01:02 #link https://gist.github.com/dolph/5cfa70c02f5b141060c5 18:01:02 flight and hotel booked 18:01:05 dolphm, Red Hat is sending me + 1.5 others 18:01:13 I assume its warm in San Anton 18:01:17 hopefully everyone interested is booked up by now 18:01:26 topol: it's COLD this week :( 18:01:33 topol: 15-17 F this morning 18:01:36 dolphm: I'm 50-50 right now, I'll confirm in the next 48 hrs 18:01:39 supposed to be 70 by end of week 18:02:04 two people from Dogtag development team. One is going to be coding with us, one half with us, and also working wirth Barbican folks 18:02:05 find us good places to eat and I'll be fine 18:02:09 #link https://www.google.com/search?q=weather+78259&oq=weather+78259 18:02:10 weather ^ 18:02:11 dolphm, i'm at -17F today, it'll be a welcome change 18:02:15 We have space for how many people? 18:02:57 gyee, are you in? 18:02:59 ayoung: working on getting a room finalized today/tomorrow... wednesday is apparently a really busy day for this kind of thing 18:03:07 whats the dress code at rackspace. Yes Im always the nerd who asks that question 18:03:11 stevemar, no, I don't have the approval 18:03:17 topol, pants are required 18:03:18 * gyee_ is sad 18:03:19 topol: tshirt and jeans? 18:03:25 any hp folk coming? 18:03:27 snuggies 18:03:29 This is texas. 18:03:33 Jeans are formal wear 18:03:34 pants are always a good call 18:03:37 ayoung: ++ 18:03:46 Spurs optional. 18:03:47 stevemar, none from our team 18:03:57 gyee_, boo 18:04:34 Minimum belt buckle size requirements have been relaxed for out-of-towners, though. 18:04:44 we'll have some PhD students from university of texas san antonio dropping in -- they're interested in contributing ABAC 18:04:55 ayoung, /me thank god! 18:05:23 hi everyone 18:05:33 hi 18:05:53 dwchadwick, kwss we are just getting through the Hackathon admin things first... 18:06:35 is everyone staying at the Courtyard ? 18:06:57 ayoung, I am. And will have a rental 18:06:59 http://www.marriott.com/hotels/travel/satca-courtyard-san-antonio-airport/ 18:07:00 #action if you're attending for sure, and haven't already, give me a poke so i have a rough head count / list of names to leave at the front desk 18:07:28 it sounds like we'll have a room right at the main entrance, so it'll be VERY easy for everyone to find 18:08:27 i'll keep the gist up to date with anything new 18:08:36 dolphm, got an estimated head count? 18:09:35 ayoung: a LOT of people are planning on dropping in at some point... i need to put together a list of everyone that will be here all 3 days though 18:10:28 #topic Changes to keystone-core 18:10:36 Our review queue is painfully long, I think that's a given! 18:10:53 one rule at the hackathon. No one is allowed to mention Army has lost to Navy 12 years in a row 18:11:16 in reviewing the current members of keystone-core, we've got several people that haven't participated lately, so I'll be cleaning them out in favor of some new names 18:11:24 topol, mention it away. I've come to acceptance on that point. 18:11:34 to be removed: Andy Smith (termie), Devin Carlen, Gabriel Hurley, and Joe Heck 18:11:45 ayoung, no. I refuse. Im on the Army side 18:12:10 and the fun part... 18:12:27 after discussing with keystone-core, effective today... 18:12:35 (and with unanimous support!) 18:12:46 drum roll 18:12:50 i'll be adding Steve Martinelli (stevemar), Jamie Lennox (jamielennox), and David Stanek (dstanek)! 18:12:59 w00t! 18:12:59 welcome to keystone-core! 18:13:07 woot woot 18:13:09 cool!! 18:13:12 yeee Haaa!! 18:13:13 congrats! 18:13:18 congrats jamielennox and dstanek :) 18:13:25 This should come as a surprise to no one. They are all doing great things. 18:13:36 unfortunately dstanek is teaching a python class somewhere in the frozen north today lol 18:13:36 amen brother! 18:13:39 ayoung: ++ 18:13:42 ayoung: seconded 18:13:49 stevemar, jamielennox, dstanek EXTREMELY WELL DESERVED. CONGRATULATIONS 18:14:03 Note that the addition of core members is a very selfish decision. It is an Ack that we need more help. 18:14:28 ah, shucks guys 18:15:53 I see it as a fait-accompli, as I've treated opinions from these guys bascially like core for a while now. But good to have the public acknowledgment. And the +2 / -2 ability. 18:16:12 it'll take me a bit to make the changes in a few places, but if you don't have +2 / -2 by end of day, give me a poke 18:16:18 because i probably did something wrong 18:17:06 #topic Federation 18:17:17 ayoung: (i believe you added this today) floor is yours 18:17:18 dolphm, can you send a formal email regarding the new core members. It helps for me to send those notes around 18:17:29 topol: of course 18:17:30 Yeah, lates last week 18:17:48 OK, so Federation is getting a lot of attention, and we need to get it right. 18:17:59 the biggest issue is the public APIs 18:18:02 topol, just give stevemar that bonus he deserves! :) 18:18:07 heh 18:18:13 gyee_ ++ 18:18:17 lets start with this 18:18:39 ayoung, not just public API but some data model changed needed 18:18:44 https://review.openstack.org/#/c/62417/ 18:19:16 atiwari, its all important, but API definitions are going to be froZen in i2 Time 18:19:28 so we need to clear this up now. Fixes can come after that 18:20:06 ayoung, that is true I have requested to add optional domain_id in IdP API 18:20:18 kwss, dwchadwick we've had the side conversation about the "method" = federated 18:20:22 versus 18:20:28 "method" = SAML etc 18:20:51 correct. And we propose a common method for all federated protocols 18:20:55 ayoung, federation deals with authentication 18:20:56 Pretty certain method=federated is based on some bad assumptions 18:21:01 first 18:21:25 I think that we can say that all of the federated API docs follow the same rules 18:21:38 authn plugin deals with authentication 18:21:42 there is not going to be a "SAML" implementation that is *not* federated 18:21:43 first bad assumption of ayoung. Federation = auth. No. federation = authn + authz 18:22:05 commonality of functionality is at the implementation level, not the API 18:22:10 dwchadwick, authz is is openstack-specific 18:22:12 dwchadwick, I didn't say that, gyee_ did. 18:22:31 in this case, federation is an way of getting in authZ attributes 18:22:38 correct 18:22:39 authentication is a subset of that. 18:22:42 federation establishes an identity and that's it 18:22:46 gyee_, nope 18:22:46 correct 18:22:56 ayoung: i don't think they're "bad" assumptions - just slightly too specific for the API layer (?) 18:23:06 it also provides additional attributes used to make authZ decisions, and that is critical to understand 18:23:08 and an identity (= set of attributes) is used for authz by Openstack services 18:23:35 it's also a superficial issue, IMO 18:23:35 dwchadwick, I think Authz can be derived from federation 18:23:45 agreed 18:24:00 dolphm, my ideal would be to do Federation without any new APIs 18:24:01 atiwari: i don't think anyone disagrees there 18:24:04 but federation is essentially about managing trust in third parties 18:24:11 good 18:24:11 and I think that it is possible to do that 18:24:37 ayoung: that's my train of thought as well -- but i haven't thought it all the way through yet 18:24:44 for example, if we front Keystone with mod_auth_mellon, what we end up with is just a new set of attributes passed to the keystone layer 18:24:48 so we have one method for managing the trust, and it is called federated but we can call it something else if the name bugs you 18:24:52 question, what about openId connect which has Authz as based component 18:25:06 So I have been talking to lots of customers on this topic. We need to work with saml and openid connect as both are pervasive 18:25:13 atiwari, good question, but can you hold it for a moment? 18:25:21 let me talk through SAML first, and then we'll talk openid 18:25:22 atiwari ++ exactly 18:25:25 sure 18:25:28 topol - agreed 18:25:47 agreed, and I think the answers to one will cover the other 18:25:53 topol - plus you need to allow for the next big protocol as well (such as ABFAB maybe) 18:26:20 ayoung - disagree. Dont talk about SAML only 18:26:26 I've been critical of the token request format for a while. I'd like to 18:26:35 dwchadwick, we will, one thing at a time 18:26:57 I'd like to focus on using the existing mechanism of the web for authentication where possible 18:27:04 SAML kindof blurs that 18:27:32 in that it sort of does cryptographically secure authentication. But we don't want to implement that in Keystone. Too hard to get right. What we want 18:27:34 is to consume it 18:27:35 but we are not talking simply authn (as un/pw does that) 18:27:44 dwchadwick, understood. 18:27:46 we are talking federation which includes authz as well 18:27:59 we talking about the one-line impl? 18:28:26 so ideally we would configure Apache (or other) to do all of the SAML work, and then Keystone responsibilites would start at the mapping layer 18:28:29 gyee - the one line implementation is that is needed on top of the trust management 18:28:35 which is why I wanted to focus on that BP first 18:28:51 ayoung - wrong. Mapping comes after trust management 18:29:07 So, first question, do we absolutely even need a new API for token request? 18:29:17 no 18:29:23 not with the apache approach 18:29:27 dwchadwick, trust setup would happen before token request 18:29:28 agreed 18:29:38 +2 18:29:55 trust setup = setting trust policies 18:29:58 that setup would be just like an external auth 18:30:14 now, there is a question about how dynamic the apache approach would be. 18:30:17 trust setup does not equal validating the attributes that you are presented with 18:30:34 dwchadwick, define trust set up, please? 18:30:48 keystone trust IdP 18:30:48 configuring the IDPs that you trust 18:30:50 Or, actually 18:30:52 ok 18:30:58 ayoung: afaik not as dynamic as we would like to have, but sufficiently dynamic for now :-) 18:30:59 configuring the attributes you trust IDPs to issue 18:31:01 so we have APIs for those progressing, right? 18:31:08 I think it is meta data needed at ST for trust IdP 18:31:13 configuring the mapping of these attributes into keystone authz properties 18:31:39 https://review.openstack.org/#/c/62604/ 18:31:48 for example. Now, that is specific to SAML. 18:32:12 the apache + mod_shib/mod_melon + IdP + protocol + mapping approach effectively creates a new route to produce openstack tokens 18:32:17 Ayoung - what do you trust Apache front end to do. That is the 1000 dollar question 18:32:22 if we are using apache approach, all those APIs are not required 18:32:33 so, it's a new API, but there's no "identity API" spec for the request, beyond the URL that apache is protecting 18:32:55 gyee_ i believe so 18:33:23 apache + mapping, and we are done with the first round 18:33:26 gyee. they are not required if you trust apache to do everything. you dont even need attribute mapping 18:33:40 you still need attribute map 18:33:51 apache will return attributes in env vars 18:33:51 dwchadwick, dolphm, I would guess it would need to work something like this: Apache is set up to accept a broad band of authentication sources (IdPs) and validate that the documesnt are authenticat (all the crypto heavy lifting) and then Keystone would take the aenv vars it is passed and say "yes, these pass my policy" or "no, we don't accep[t from that IdP" 18:33:55 guys, that is why I was asking for an architectural diagram so that every know what we are working on 18:34:09 gyee, that is what i thought 18:34:16 atiwari ++ 18:34:22 atiwari, I feel your pain. But that is what we are trying to nail down here. 18:34:45 in the mod_mellon case, you'd just configure mod_mellon to protect GET /v3/OS-FEDERATION/identity_providers/cern/protocols/saml2 with a configuration for cern + saml2, and keystone then knows what mapping to apply to the response, and output an authz'd token 18:34:52 mod_shib works similarly 18:34:54 https://code.google.com/p/modmellon/wiki/GenericSetup 18:35:22 yep 18:35:24 dolphm, so adding a new IdP would be a change to Apache config. It would require an apache restart 18:35:32 how does keystone know? is the mapping in a config file or keystone api? 18:35:50 bknudson, mapping API is also under review. 18:35:51 Noone has yet answered the 1000 dollar question. Come on guys. What do you trust Apache to do 18:35:52 ayoung: yes 18:35:55 bknudson, in theory, mapping can be just middleware 18:36:09 #link https://review.openstack.org/#/q/status:open+project:openstack/identity-api,n,z 18:36:09 ayoung +1, it has to be dynamic 18:36:10 gyee_: it's in review as middleware today 18:36:16 atiwari: eventually 18:36:35 dolphm, alrighty then 18:36:35 dwchadwick: why not trust an existing implementation to take care of a bunch of fragile work? 18:36:41 atiwari, I hear you. Its just that I don't think we can get there in Icehouse 18:36:42 dwchadwick: why NOT leverage that? 18:36:50 ayoung: ++ 18:37:11 dwchadwick, I trust Apache to validate a SAML assertion and provide the attributes to Keystone. 18:37:11 you can if you are sure that it does the job properly. 18:37:21 ayoung. That is not enough 18:37:23 dwchadwick: in general i trust every parameter mod_shib provides me with... 18:37:26 I'd trust existing and deployed apache code over code that hasn't been written. 18:37:34 ayoung and dolphm at least we can add optional domain_id in IdP config 18:37:50 dwchadwick, agreed. That is why we take those attributes and post process them in the mapping layer. 18:37:58 so that other use case can be supported 18:38:08 today I can send attributes from my trusted IDP to apache and have it trust them even though it should not 18:38:13 so we move the trust management and call it on all methods of authn removing the need for a specific plugin? 18:39:21 dwchadwick, if Apache sends along a variable that says "these attributes were verified by IdP=X we can then have the mapping layer say "but IdP=X can't assert those variables" 18:39:23 dwchadwick: by default apache modules let you configure a very simple map of accepted attributes. 18:40:06 dwchadwick, understand, we've shifted a bit from a "eventual design" to "what can be done in icehouse time" mindset here. 18:40:14 We can always do more in the future. 18:40:27 that's the slogan 18:40:30 :) 18:40:32 what is the term MVP? Minimal Viable Product? 18:40:45 Given that we have already implemented the current design, then why dont you think it can be ready for icehouse 18:40:48 "We can always do more in the future." 18:41:13 dwchadwick: is the implementation posted somewhere? 18:41:25 yes has been for about a week now 18:41:51 its about 700 lines long. Its the first proof of concept 18:41:56 bknudson: ++ 18:42:09 I think the team here can easily make it perfect for icehouse 18:42:14 https://review.openstack.org/#/c/64454/ 18:42:30 perfect is a big word 18:42:39 good enough then 18:43:39 your MVP requires an Apache front end, which some institutions have already rejected 18:44:07 e.g. Brazil has an operational system based on our design and a mixture of their own code and ours 18:44:14 dwchadwick ++ 18:44:42 but this code stil relies that the input is a JSON request, something like https://review.openstack.org/#/c/62604/, right? 18:44:48 dwchadwick: out of curiousity, rejected on what basis? 18:44:49 dwchadwick: i think apache is more about what we can use now - if there becomes a wsgi middleware for handling all this then it can be added to the mix later 18:45:15 jamielennox: ++ 18:45:18 on a basis of trust management and hops in the chain. Apache is an overhead they dont want 18:45:58 Apache need static configuration which is not scalable 18:46:01 dwchadwick, in your review above, how is the SAML document validated? 18:46:14 kwss, that question is actually for you 18:46:53 It uses pySAML code, which was not written by us but it publicly available 18:47:09 the saml protocol handing module is not in that review, only the apache2 module which expects prevalidated attributes from the apache module 18:47:38 kwss: module like mod_mellon, mod_shib? 18:47:44 yes 18:47:44 right...so pySAML is doing crypto in Python? Or calls to the OpenSSL librarites? 18:48:03 ayoung: pySAML uses m2crypto 18:48:10 ha 18:48:15 dolphm, is that acceptable? 18:48:25 kwss: so, why would you need some parameters like phase {negotiation, validation} and so on? mod_shib does everything as far as i am concerned. 18:48:46 dwchadwick, there are performance issues around crypto and python, exacerbated by Eventlet. 18:48:48 marekd - correct if you have the apache front end 18:49:14 the other phases are for using the same mechanism for other protocols 18:49:18 we have published performance results in our paper, and pySAML works perfectly well 18:49:18 dwchadwick: kwss mentioned she expects validated attributes from apache module...maybe i am misunderstandind something.. 18:49:19 ayoung: that's your ball park :P 18:49:41 it's not a blocker for me 18:50:01 marek. If Apache does the saml protocol, then it simply passes the attributes to Keystone for trust management 18:50:05 but i'm easily edumacatable 18:50:19 if pysaml does the saml protocol, then we dont need an Apache front end 18:50:29 OK...so we would want to make it transparent to the user. They should know that they are using SAML, but not know what Keystone is doing 18:50:33 * gyee_ looks up the word edumacatable 18:50:43 the request should look the same regardless 18:50:52 ayoung +1 18:50:52 gyee_: http://www.urbandictionary.com/define.php?term=edumacated 18:50:56 so there should not be an explicit apache2 18:51:07 haha 18:51:17 the request will always look the same to the end user since they will be talking to their own IDP to authenticate 18:51:36 end users dont see underlying protocol exchanges 18:51:44 dwchadwick, I mean the JSON document that is passed to keystone to get a token. 18:51:53 dwchadwick, yes they do 18:52:10 ayoung, JSON comes between apache and keystone 18:52:29 the JSON doc is standardised to be the same regardless of the federation protocol or whether Apache is in the picture or not 18:52:31 user will not see the JSON 18:52:44 dwchadwick, remember, that we can't even say for certain that the user is using the python-keystoneclient. All of these APIs need to be acallable from third party implementations 18:52:58 this is the feature of our design - its protocol independent federation 18:53:06 where does JSON come into play? in the apache + mod_shib / mod_mellon case, there's no JSON at all 18:53:10 ain't no such critter 18:53:37 dolphm, there would still be a JSON document passed to the auth controller. 18:53:45 Its simple. There is an Apache page that converts the headers into a json doc in the standard format 18:53:45 I mean, I would love to get rid of that 18:54:05 dwchadwick, ahhh 18:54:17 mod_rewrite type logic.... 18:54:24 yes 18:54:27 ayoung: okay i think i follow... but it would never be serialized JSON.. it's just a python dict being passed to auth? 18:54:33 or to the token backend? 18:54:40 dwchadwick: so you want to make apache httpd communicate with standalone keystone over the network, right? 18:54:54 dolphm, up until now I was thinking env vars passed through. 18:54:56 i thought it already did that 18:55:10 dwchadwick, "over the network" no 18:55:16 its assumed to be a local call 18:55:16 ayoung: ++ they do. the mapping picks up env vars and converts them into something that existing code can produce a token based on 18:55:23 ayoung: like, a pre-auth'd auth request 18:55:39 EXTERNAL_USER-style 18:55:45 Kristy is just now getting an APache front end up so that we can learn more about using it, as it is not something we have used so far 18:56:19 we use Apache to run SAML IDPs and SPs, but not to front Keystone 18:56:39 Sorry I must go now for my personal appointment 18:56:46 dolphm, dwchadwick I think I need a bit to process this, but I'm not certain it changes anything. I don't love the mod_rewrite approach. 18:56:52 dwchadwick: same sort of advantage when you're fronting keystone, not to mention the performance gains over keystonea-ll 18:56:57 dwchadwick, thanks for your time.... 18:57:32 ayoung: ++ i'd like to review both side by side in the mean time -- they're both viable approaches and if we have a head start on a better long term solution, it certainly deserves consideration for icehouse 18:57:41 let's evaluate in review, and pick it up next time! 18:57:49 (< 1 min left) 18:57:49 dolphm ++ 18:58:08 dolphm, still don't need moehod=federated 18:58:10 method 18:58:24 kwss, can you stick around in #openstack-dev? 18:58:38 ayoung: yea no problem 18:58:42 dolphm, ++, we like the Republican's, a big tent 18:58:50 #endmeeting