18:01:49 <dolphm> #startmeeting keystone
18:01:50 <openstack> Meeting started Tue Dec 17 18:01:49 2013 UTC and is due to finish in 60 minutes.  The chair is dolphm. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:01:51 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:01:55 <openstack> The meeting name has been set to 'keystone'
18:01:59 <dolphm> #topic Reminder: Hackathon January 15-17th @ Rackspace in San Antonio, TX
18:02:17 <dolphm> feel free to book flights :) sounds like a couple have already been done
18:02:23 <morganfainberg> ooh, on vacation starting next week.  (read: snowboarding trip!)
18:02:31 <dolphm> i'm curious if anyone has gotten a hotel in SA yet
18:02:43 <dolphm> morganfainberg: be careful! :P
18:02:46 <topol> dolphm, fly in the night before make the most sense?
18:02:47 <gyee> dolphm, I'll know my status by end of the week
18:02:59 <dstanek> dolphm: i have not, but i'm planning on just staying at the courtyard
18:03:19 <dolphm> topol: that's what i would do personally
18:03:20 <ayoung> Yeah there was one hotel walking distance to the office that seemed to make sense
18:03:22 <topol> dolphm, stevemar and I are a GO!  Contingent on you giving us a personal tour of the Alamo
18:03:38 <topol> dolphm, we will come in the night before
18:03:42 <dolphm> topol: i shall personally point you to it on a map
18:03:43 <morganfainberg> i have not booked hotel, but courtyard seems like the best choice
18:04:14 <dolphm> valencia is damned nice and downtown if you're into that, courtyard has free transport
18:04:20 <dolphm> so, pick your poison
18:04:21 <topol> can we all pick the same hotel? Are we going with the courtyard?
18:04:49 <morganfainberg> dolphm, i'm leaning towards free transport since i'm still wokring on details to see if i am paying for this out of my own pocket
18:04:50 <dolphm> topol: courtyard is definitely the easier & slightly cheaper option
18:05:13 <morganfainberg> dolphm, so les $ is my goal.
18:05:15 <topol> morganfainberg I'll have a car
18:05:20 <stevemar> cheaper is good
18:05:21 <dstanek> i would be up for either - the only thing i don't like about the Valencia is that i'll need a car and you have to valet it
18:05:26 <dolphm> #link https://gist.github.com/dolph/5cfa70c02f5b141060c5
18:05:30 <morganfainberg> dstanek, ++
18:05:47 <topol> Let's agree on courtyard
18:06:20 <morganfainberg> topol, sounds good to me.
18:06:23 <dstanek> i'll be booking my travel tonight
18:06:35 <dolphm> topol: noted on the gist
18:07:00 <stevemar> any international guests? henrynash or jamielennox ?
18:07:03 <dolphm> if anyone has trouble booking at the discounted rate, chase me down
18:07:08 <topol> dolphm, excellent
18:07:16 <dolphm> i'm told there's not a group code, and that you have to call
18:07:16 <jamielennox> stevemar: a little hard to justify for a hackathon
18:07:33 <ayoung> any reason not to take the Pear Tree hotel?  Easy walk to the office
18:07:50 <ayoung> $80 / night
18:07:51 <dolphm> jamielennox: frankly i wouldn't make the trip unless you're planning on staying longer than 3 days lol
18:07:54 <morganfainberg> jamielennox, you know you want to hop on a ~19hr flight :P
18:08:00 <morganfainberg> for 3 days
18:08:03 <dolphm> ayoung: i'm not familiar with it
18:08:31 <ayoung> https://plus.google.com/104227517689615970183/about?gl=us&hl=en
18:08:48 <jamielennox> dolphm:, morganfainberg: would end up just sleeping through the whole thing
18:09:19 <morganfainberg> jamielennox, i hear ya man.
18:09:20 <ayoung> 0.5 mi, 9 mins
18:09:20 <ayoung> Interstate 35 Frontage Rd/NE
18:09:44 <morganfainberg> ayoung, either that or the shuttle from the courtyard, both seem reasonable and in the same-class of price
18:09:47 <morganfainberg> for the most part
18:09:59 <bknudson> dolphm: it's next to the red lobster
18:10:16 <bknudson> by the home depot
18:10:16 <ayoung> I hate waiting on shuttles.  We're coders...and I won;t have the kids to keep me on a regular schedule
18:10:42 <bknudson> what's Shoney's?
18:11:01 <ayoung> So we won't go hungry
18:11:07 <dolphm> ayoung: as i understand it, the shuttles have a regular schedule (they run 3 times a day each way) you just need to give the front desk a heads up that you'd like to be on it
18:11:16 <dolphm> bknudson: a chain diner
18:11:24 <ayoung> Marie Callendars
18:11:46 <dolphm> there's food within walking distance of rax, and we have vendors in house every day
18:11:59 <stevemar> topol and i should have rentals - i think?
18:12:10 <topol> yes we will!!!
18:12:11 <stevemar> we could car pool
18:12:31 <morganfainberg> works for me
18:12:37 <ayoung> Is there any reason not to go to the PearTree?
18:13:05 <topol> Im fine with either. I need to check what options pop up in our hotel reservation tool. will do that now
18:13:20 <morganfainberg> ayoung, i think it is all personal preferance at this point
18:13:22 <ayoung> It would be good to all be at the same hotel
18:13:30 <ayoung> makes Logisitics easier
18:13:35 <stevemar> topol, nothing pops up :(
18:14:08 <morganfainberg> ayoung, nod
18:14:43 <ayoung> Link to the Courtyard?
18:14:47 <bknudson> mordred road. that's weird.
18:15:08 <dstanek> ayoung: i have heard that it's not a great hotel
18:15:22 <topol> whats rackspace's address
18:15:32 <stevemar> Rackspace Hosting, 1 Fanatical Place, Windcrest
18:15:43 <stevemar> topol ^
18:15:54 <stevemar> postal code 78218
18:16:02 <ayoung> "1803 E Sonterra Blvd, San Antonio, TX 78259"  That Courtyard?
18:16:16 <dolphm> stevemar: or 5000 Walzem Rd. (Fanatical Place was just built & named)
18:16:26 <dolphm> ayoung: definitely not
18:16:44 <dolphm> ayoung: that's near my house though lol
18:16:52 <dolphm> ayoung: http://www.marriott.com/hotels/travel/satca-courtyard-san-antonio-airport/
18:16:52 <ayoung> so I could get a ride in
18:17:01 <dolphm> ayoung: 8615 Broadway Street  San Antonio  Texas  78217  USA
18:17:09 <dolphm> ayoung: there's a damn good coffee shop right there...
18:17:19 <dstanek> http://www.marriott.com/hotels/travel/satca-courtyard-san-antonio-airport/
18:17:27 <dolphm> ayoung: (on Sonterra Blvd)
18:17:31 <ayoung> After the Summit I am sick of Airports....
18:17:40 <topol> stevemar, we can get an exception
18:17:41 <ayoung> Never even made it past Kowloon
18:17:53 <dolphm> ayoung: lol
18:18:05 <ayoung> Is the courtyard the Hotel of choice then?  That alone is reason to book it
18:18:17 <topol> 99$ courtyard is within budget
18:18:18 <dolphm> ayoung: sounds like it
18:18:24 <stevemar> topol, i figured that, just never had the need to
18:18:27 <dolphm> ayoung: there are a couple definites for courtyard
18:19:07 <dolphm> #topic Next Keystone meeting: January 7th
18:19:11 <ayoung> 6.2 mi, 2 hours 5 mins
18:19:12 <ayoung> NE Interstate 410 Loop  That estimate seems long
18:19:30 <ayoung> ah, still set for walking
18:19:36 <dolphm> anyone is welcome to use this time slot and have a meeting if you want, but i'll be AFK for most of the next two weeks
18:19:38 <topol> Any hotels with a bedbug special???
18:19:47 <dolphm> ayoung: walking is slow in texas
18:19:57 <ayoung> Biking route looks cool,
18:20:28 <ayoung> 7.8 ,moiles, 48 minutes, WTF?
18:21:04 <bknudson> it's hot there and people move slowly
18:21:08 <dolphm> bknudson: ++
18:21:09 <ayoung> Do they estimate based on a tricycle?
18:21:12 <dolphm> cars ftw
18:21:20 <ayoung> My experience in TExas in January was that it is not hot....very not hot.
18:21:33 <dolphm> yeah, it'll be really nice
18:21:48 <morganfainberg> dolphm, s/cars/cats <xkcd plugin />
18:21:57 <dolphm> in the 55-70 F range at the moment
18:22:09 <dolphm> morganfainberg: lol
18:22:34 * ayoung watches the snow fall outside
18:22:38 <dolphm> k, let's move on to actually important things
18:22:44 <dolphm> it's almost marekd's bed time
18:22:48 <topol> stevemar, courtyard at the airport has an IBM negotiated rate. Is thatw here everyone is staying?
18:22:49 <dolphm> #topic Leveraging mod_shib / mod_mellon to handle interaction with federated identity providers
18:22:51 <dolphm> marekd: o/
18:22:56 <marekd> dolphm: \o
18:23:02 <marekd> still awake
18:23:04 <dolphm> topol: yes
18:23:04 <ayoung> mod_auth_mellon...I'll find the linlk
18:23:22 <dolphm> #link https://code.google.com/p/modmellon/
18:24:18 <ayoung> anyone tried it out yet?  I know people in our IdM team have, but not me myself.
18:24:28 <marekd> me, but not mod_mellon.
18:24:31 <marekd> mod_shib.
18:24:32 <morganfainberg> ayoung, i haven't had a chance to yet.
18:24:39 <stevemar> ayoung, marekd tried it out: https://gist.github.com/zaccone/914822d37ac2eea420ce
18:24:43 <dolphm> mod_mellon seems to be pretty well packaged (debian, centos, rhel)
18:24:55 <stevemar> we get a whole whack of stuff back
18:25:08 <bknudson> to use saml you need to run in apache?
18:25:22 <marekd> yes.
18:25:33 <ayoung> #link reference http://www.explainxkcd.com/wiki/index.php/1218:_Doors_of_Durin
18:25:34 <dolphm> bknudson: ++
18:25:44 <marekd> another this is: is relies on static config files
18:25:57 <marekd> mod_mellon for 100% - asked on their mailing list.
18:26:05 <marekd> (completely reasonable)
18:26:21 <dolphm> bknudson: i'd rather not re-invent the wheel in the next few weeks, but we could implement the same in middleware eventually
18:26:28 <marekd> dolphm: ++
18:26:43 <dolphm> marekd: mod_mellon relies on static config?
18:27:00 <marekd> dolphm: yes.
18:27:11 <dolphm> marekd: does that imply that mod_shib doesn't?
18:27:35 <marekd> dolphm: mod_shib uses files too...
18:27:51 <marekd> i just said i am 100% about mod_mellon, because I asked it's authors.
18:28:07 <bknudson> I assume that keystone is going to have to support more than just REMOTE_USER then?
18:28:13 <marekd> however i have never seen any plugin for mod_shib + SQL/something.
18:28:15 <dolphm> mod_mellon is GNU GPL v2
18:28:38 <dolphm> bknudson: ++, the federation middleware will have to read headers from the apache module
18:28:48 <ayoung> bknudson, they should come through as additional env vars
18:28:50 <dolphm> bknudson: see stevemar's link to marekd's example
18:28:58 <marekd> bknudson: modules would do the job.
18:29:11 <marekd> bknudson: keystone would get set of parsed attributes.
18:29:44 <marekd> which is great, as I personally find SAML not very 'clean' atribute and would rather not write soft for parsing those all XMLs :-)
18:29:54 <topol> GNU GPL v2.  Isnt that like buying a hot rolex?  A big no no?
18:30:10 <marekd> topol: why?
18:30:14 <bknudson> is it the ADFS_* attrs are the assertions?
18:30:18 <marekd> yes
18:30:24 <marekd> bknudson: ^
18:30:44 <dolphm> topol: considering the nature of our dependency on it, i don't know how much we need to care? worth asking the list
18:30:45 <dolphm> bknudson: ++
18:30:55 <marekd> and as a matter of fact YOU configure in the mod_ how to make a initial mapping.
18:31:13 <marekd> #link https://gist.github.com/zaccone/021203cab26c9e4b0baf
18:31:23 <marekd> here is the code, that produced the output for my SP
18:31:27 <marekd> (mod_shib)
18:31:38 <marekd> but mod_mellon would work pretty much the same way.
18:31:38 <ayoung> reference link http://www.freeipa.org/page/Environment_Variables
18:31:41 <dolphm> topol: i'm looking for the license to mod_shib... can't find much
18:31:59 <ayoung> SAML not yet made it in there, though
18:32:03 <fabiog> topol, I think it is complicated to re-package that code, you need to use the same licensing model
18:32:47 <ayoung> http://code.google.com/p/modmellon/wiki/GenericSetup#Retrieving_attributes_from_mod_mellon
18:33:01 <topol> fabiog exactly
18:33:12 <dolphm> fabiog: i believe it's okay for us to support it, as long as we don't have a hard dependency on it
18:33:33 <marekd> anyway, using mod_* implies static configuration. dolph said it should be generated manually, one day we could add some code -> keystone would generate config based on the data stored in it's backend.
18:33:43 <fabiog> dolphm, we need to be careful, because even re-distributing it could be an issue outside GPL
18:33:52 <dolphm> fabiog: +++
18:34:10 <topol> fabiog exactly +++
18:34:20 <morganfainberg> why can't everyone use ASLv2 these days
18:34:35 <bknudson> so keystone would provide a way to map ADFS_* to roles?
18:34:41 <topol> morganfainberg, preaching to the choir!
18:34:42 <marekd> yes, mapping.
18:34:47 <bknudson> and that's going to be some middleware?
18:34:48 <marekd> bknudson: ^^
18:34:54 <bknudson> is the config in a config file or in keystone db?
18:34:55 <ayoung> ASL?  American Sign Language?  Didn';t realize there was an updated version
18:34:56 <fabiog> morganfainberg, I think MIT License is also goo
18:34:58 <fabiog> good
18:35:08 <marekd> bknudson: what config?
18:35:09 <morganfainberg> fabiog, prefer apache myself
18:35:16 <topol> ayoung, out in left field again :-)
18:35:32 <bknudson> or do we have something that translates ADFS_* to some keystone structure
18:35:46 <topol> fabiog, we must have the same lawyers :-)
18:35:50 <marekd> bknudson: mapping attributes, completely internal stuff, right stevemar ?
18:35:51 <dolphm> bknudson: config for mod_mellon / mod_shib should be deployer-handled in icehouse
18:35:53 <ayoung> Are we OK with mod_mellon as a starting point?  Not a hard dep, but a way to get things moving?  Put it to avote?
18:36:02 <marekd> dolphm: ++
18:36:04 <fabiog> topol, in reality lawyers are all the same ;-)
18:36:22 <dolphm> bknudson: config for how keystone handles assertions is basically in SQL for us, as we're exposing it to the API
18:36:55 <dolphm> ayoung: i'd like to answer that today, but can you find a license for mod_shib ?
18:37:22 <bknudson> I'm fine going with an apache/external auth method.
18:37:33 <topol> dolphm, I think you should ask if any concerns on the dev list or the OpenStack gods
18:37:35 <jamielennox> is there a pros/cons for mellon vs shib? i've at least heard of mellon and i'm pretty sure it's packaged
18:37:36 <marekd> dolphm: one thing, not sure if it's relevant: mod_mellon is a pure apache module
18:37:40 <dolphm> topol: ++
18:37:53 <dolphm> jamielennox: it's packaged
18:37:57 <bknudson> looks like it will be a lot of work to reimplement all that ourselves.
18:38:16 <ayoung> dolphm, I can., but I think we've found mellon is much more in line with what we are looking for.   Let me see
18:38:22 <marekd> dolphm: whereas shibboleth works slightly different: there is a standalone daemon, that does it's work, accessible on unix sockets or tcp, mod_shib actually is a frontend and communicates with shibd daemon
18:38:27 <jamielennox> i think the external approach is good, one mod vs the other is just selecting the better i think
18:38:28 <dolphm> ayoung: good to hear
18:38:32 <dolphm> bknudson: ++
18:38:42 <marekd> dolphm: on the other hand, i didn't find info about protocol for communicating between peers....
18:39:01 <ayoung> http://en.wikipedia.org/wiki/Shibboleth_%28Internet2%29#Development
18:39:40 <marekd> guys, how determined are you to decide today?
18:39:42 <bknudson> since there's potentially multiple providers, I think it makes sense to translate whatever they give us (ADFS_* attrs or whatever) to a keystone structure that keystone uses.
18:40:02 <topol> ayoung, yay that one is Apache 2 License
18:40:06 <dolphm> marekd: i'd like to know about blockers on one other the other today
18:40:26 <dolphm> so it's GPL w/ easy deployments vs Apache 2 w/ complicated deployment
18:40:46 <marekd> dolphm: IdP discovery. i am not sure it's stararized and whether both modules will work in the same way...
18:41:05 <marekd> https://wiki.shibboleth.net/confluence/display/SHIB2/IdPDiscovery
18:41:17 <marekd> this is for shibboleth (grep for From a Known Home)
18:41:36 <marekd> however i couldn't make it work or my shib :P
18:41:44 <dolphm> lol
18:41:45 <jamielennox> bknudson: ++ keep the provider specific interface to a minimum
18:42:04 <topol> marekd that joke went over my head
18:42:12 <ayoung> The Shibboleth License, Version 1.
18:42:13 <ayoung> * Copyright (c) 2002
18:42:13 <ayoung> * University Corporation for Advanced Internet Development, Inc.
18:42:13 <ayoung> * All rights reserved
18:42:19 <marekd> topol: hm?
18:42:46 <dolphm> bknudson: sure, and you could probably abstract away the difference between _shib and _mellon eventually
18:42:57 <dolphm> ayoung: wtf lol
18:43:08 <ayoung> dolphm, looking for a short link
18:43:15 <ayoung> but that was dated 2002
18:43:18 <ayoung> MIT cached version
18:43:29 <marekd> th other thing i am worried veryy much is the client side.
18:43:45 <marekd> wherever you google for SAML the use-case is a browser one.
18:44:05 <marekd> 'a client uses his WEB BROWSER and logs in'
18:44:11 <bknudson> we're not going to have a library for python-keystoneclient to use?
18:44:34 <marekd> bknudson: keystoneclient will be a big part in federation authn
18:44:48 <marekd> https://developers.google.com/google-apps/sso/saml_workflow_vertical.gif
18:45:03 <marekd> bknudson: if that was your question :P
18:45:03 <dolphm> bknudson: keystoneclient can't pretend to know how to auth with all existing IdP's though
18:45:04 <ayoung> https://github.com/sonian/shibboleth-sp2/blob/master/apache/mod_shib_20.cpp
18:45:49 <bknudson> keystone isn't going to provide saml assertions, only accept them
18:45:57 <marekd> bknudson: correct.
18:46:00 <dolphm> bknudson: correct
18:46:13 <jamielennox> marekd: what are you expecting the client to have to do extra?
18:46:15 <bknudson> that's like step 8 of https://developers.google.com/google-apps/sso/saml_workflow_vertical.gif
18:46:32 <jamielennox> oh right, i know what you mean
18:46:32 <bknudson> it's like you need a token from idp to get a token form keystone
18:46:40 <marekd> jamielennox: keep the session, handle HTTP redirects.
18:46:47 <marekd> jamielennox: that's for sure.
18:46:49 <dolphm> bknudson: ++
18:47:04 <dolphm> bknudson: that's exactly how it works (SAML being the token)
18:47:28 <marekd> dolphm: to me SAML likes like a web-browser only protocol, seriously :(
18:47:29 <morganfainberg> so we're using the standard SAML workflow instead of the EC or Proxy method?
18:47:29 <jamielennox> marekd:  session and redirects are fine, i'm not sure if we can handle pointing keystoneclient at any random idp provider though
18:47:35 <bknudson> the client need to get the "encoded SAML response" (step 6) and send it to keystone server
18:47:44 <morganfainberg> simply because EC / Proxy doesn't require redirects
18:47:45 <ayoung> So..before we run out of time...I'd like to suggest we discuss https://blueprints.launchpad.net/python-keystoneclient/+spec/endpoint-versioning
18:47:48 <dolphm> morganfainberg: ooh, what are the other two methods...
18:47:52 <marekd> jamielennox: willing to talk after the meeting?
18:47:57 <jamielennox> marekd: sure
18:48:14 <morganfainberg> dolphm, Enhanced client and proxy.  but the details i've drummed up are light so far
18:48:16 <morganfainberg> let me see if i can find that diagram
18:48:16 <bknudson> jamielennox: maybe if we had idp plugins in the client ?
18:48:16 <jamielennox> actually auth plugins will fix a lot of this anyway
18:48:29 <dolphm> ayoung: we've talked about that elsewhere, extensively
18:48:48 <marekd> morganfainberg: SP and IdP doen't require direct communication, it's client who transport requests/responses.
18:49:04 <morganfainberg> marekd, ah. i see.
18:49:28 <ayoung> dolphm, then it is OK if I go ahead an implement>
18:49:30 <ayoung> ?
18:49:36 <marekd> morganfainberg: that's why keystoneclient will play a big role gere.
18:49:42 <marekd> s/gere/here
18:49:44 <morganfainberg> marekd, that is standard, i think it's doable with EC or proxy though where SP -> idp is in direct communication
18:50:01 <morganfainberg> marekd, like i said, the info on EC / Proxy methods with saml seemed very light
18:50:11 <marekd> morganfainberg: standard direct communication between SP<->IdP?
18:50:15 <morganfainberg> so might not be really usable.
18:50:17 <atiwari> marekd, direct communication will be needed for artifact profile
18:50:28 <dolphm> ayoung: no
18:50:41 <marekd> atiwari: can you say more?
18:50:43 <atiwari> when SP wants to pull the SAML from IdP
18:50:51 <dolphm> ayoung: absolutely not -- all the prior art and design direction directly conflicts with everything this blueprint describes
18:50:56 <ayoung> dolphm, nope
18:51:04 <morganfainberg> marekd, http://appliedlife.blogspot.com/2007/06/saml-enhanced-client-or-proxy.html
18:51:04 <dolphm> ayoung: search on the mailing list for discovery
18:51:15 <ayoung> dolphm, so long as we don;t lock ourselves into requiring version, we should be OK
18:51:22 <ayoung> dolphm, without it, we are stuck on v2
18:51:26 <atiwari> In the SAML artifact profile, artifact will not be provided to SP initially
18:51:41 <marekd> atiwari: any links, docs for that? I never heard of that.
18:51:42 <atiwari> artifact +> assertion
18:51:55 <ayoung> dolphm, people are writing scripts etc and its all based around the current endpoints coming back from the Service Catalog
18:52:18 <dolphm> ayoung: which is a terribly broken approach that we need to rectify and not further
18:52:28 <ayoung> we just need to A)  work around it until the v2 is deprecated B) do discovery, and C) stop telling people to put versions on their endpoints
18:52:35 <shardy> ayoung: IMO all the client libs should be able to do version negotiation via an unversioned endpoint
18:52:40 <dolphm> ayoung: the reason everyone else is writing broken code is because we've failed to set the example
18:52:41 <ayoung> but we need the workaround
18:52:47 <dolphm> shardy: ++
18:52:52 <ayoung> shardy, eys, but people can't change the endpoints that are in the SC
18:52:55 <atiwari> marekd, link: http://en.wikipedia.org/wiki/SAML_2.0#HTTP_Artifact_Binding but it is for the future
18:52:57 <ayoung> I agree with all of this
18:52:57 <dolphm> ayoung: this is not a matter of deprecating v2
18:53:05 <ayoung> but still insist that we need a wrokaround or we are stuck
18:53:05 <atiwari> may be we can avoid it for now
18:53:21 <morganfainberg> marekd, dolphm, though it looks like ECP might preclude using the apache mod
18:53:23 <ayoung> wreakaround?
18:53:28 <ayoung> reakhavocaround
18:53:52 <bknudson> so identity providers have a standard for authenticating? (SAML SOAP binding?)
18:53:54 <ayoung> anyway, we need to assume that endpoints come back saying V2.0 at the end, or old clients are going to break
18:53:55 <fabiog> dolphm, less than 10 min left ...
18:54:10 <ayoung> can we just be pragmatic here, so long as we avoid the pitfalls of the past?
18:54:23 <bknudson> from http://3.bp.blogspot.com/_Hu8FwD79TOo/RoK5RmNAebI/AAAAAAAAAA4/trnodJ9iZ9s/s1600-h/ecp-diagram.jpg
18:54:34 <dolphm> ayoung: you're proposing we regurgitate all the pitfalls of the past
18:54:34 <marekd> morganfainberg: to be honest, the more i read about saml, the more i ask aroung, the more i am convinced everybody has his standard :(
18:54:49 <dolphm> fabiog: not sure we're going to have time to discuss notifications, other than direct people to it
18:55:04 <marekd> bknudson: i dont see direct arrows between SP & IdP.
18:55:32 <morganfainberg> marekd, the arrow crosses the SP, SP is the Proxy via SOAP bindings
18:55:34 <jamielennox> fabiog: i like the idea - not every extension can be implemented purely in a pipeline
18:55:38 <dolphm> bknudson: SP never talks to IdP directly
18:55:39 <morganfainberg> and directs the request to the known IdP
18:55:40 <dolphm> bknudson: afaik
18:55:46 <marekd> dolphm: ++
18:55:46 <morganfainberg> in that diagram
18:56:13 <morganfainberg> well, ECP being the "smart" proxy
18:56:13 <atiwari> dolph, "SP never talks to IdP directly" is not correct
18:56:21 <fabiog> jamielennox: and  currently the data is not in sync if there are any dependencies
18:56:29 <dolphm> atiwari: feel free to correct me with an example
18:56:32 <marekd> morganfainberg: directs the requests mean directs the client to go there, right?
18:56:38 <jamielennox> fabiog: there are a bunch of extensions that i think will need to simply run and that shouldn't have a middleware component - is this how the other projects do it though?
18:56:46 <morganfainberg> marekd, as far as i can tell, yes
18:56:47 <jamielennox> nova must have this problem
18:56:51 <atiwari> but yes not in post profile , it is correct
18:56:53 <marekd> morganfainberg: because i was referring to a direct TCP connection between IdP and SP
18:56:55 <morganfainberg> http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf 4.2.1
18:56:56 <ayoung> dolphm, no, I am proposing we ignore the versions on the URLs
18:57:09 <marekd> morganfainberg: and then i say : never heard about that (TCP conns)
18:57:14 <morganfainberg> erm 4.2
18:57:28 <dolphm> ayoung: i got that much; don't do that
18:57:34 <ayoung> we need to do at least that in order to get v2 and v3 interop
18:57:40 <ayoung> dolphm, we have to.
18:57:44 <fabiog> jamielennox: this is only for registered Keystone extensions, if you want a generic notification you can re-use the rabbitmq model
18:57:44 <morganfainberg> marekd, i think this is super complex :P
18:57:52 <ayoung> This is the corner we;ve been painted into
18:58:09 <ayoung> versions in the URLS are stupid, I agree
18:58:23 <fabiog> jamielennox: but for the extensions that are interested only in Keystone this will be very efficient and simple (I think)
18:58:24 <jamielennox> fabiog: yea i get that, i was just thinking that nova v3 is based around an extensions model and they must be doing notification like this
18:58:29 <bknudson> is PAOS the opposite of SOAP?
18:58:29 <ayoung> and this is not something we can be a purist about, or we will not be able to get rid of them
18:58:29 <marekd> morganfainberg: i think this is overkill, seriously. i think i must check whether mod_shib, mod_mellon has ECP implemented.
18:58:35 <marekd> bknudson: yes.
18:58:40 <marekd> bknudson: whatever it means...
18:58:46 <dolphm> ayoung: we put ourselves here; version discovery in the clients will push deployers to revise their catalogs
18:58:46 <morganfainberg> bknudson, lol
18:58:52 <morganfainberg> bknudson, i never noticed that.
18:58:59 <marekd> morganfainberg: he is right :)
18:59:04 <morganfainberg> marekd, i know.
18:59:07 <dolphm> ayoung: have you seen the crap nova and cinder are doing? that's our fault too
18:59:07 <ayoung> dolphm, Ifd we tell people to change the endpoints in their service catalog to either drop the version or have v3, it will break all of the v2 clients out there
18:59:12 <fabiog> jamielennox: since I have extended the Oslo notification model, I believe it should be available to all the Openstack modules
18:59:14 <morganfainberg> it makes sense, but i just... never connected it
18:59:29 <ayoung> so discovery solves it in the future, but it doens't get the car out of the ditch
18:59:30 <atiwari> dolphm, link:http://en.wikipedia.org/wiki/SAML_2.0#HTTP_Artifact_Binding has good desc of artifact binding
18:59:51 <dstanek> ayoung: can you just start accepting a version via HTTP headers and have the server redirect in the case where a version is in the url and a different one is requested?
19:00:07 <jamielennox> fabiog: ah, ok, that's fine, i agree with the approach was just interested to know if you were re-using the concept from other projects or if we were going out on our own here
19:00:19 <dolphm> ayoung: understood, but let's write the tools to make the problem non-existant rather than advocating a hacky approach that we've demonstrated is garbage
19:00:20 <ayoung> dstanek, avoid using the word 'just' cuz  no solution here is going to be neat or easy
19:00:24 <morganfainberg> marekd, i wasn't saying ECP was required, just wanted to ask if we were looking at it vs the "browser" style SAML ("traditional web SSO") model)
19:00:40 <marekd> morganfainberg: ah, ok.
19:00:42 <dstanek> ayoung: s/just //
19:00:48 <fabiog> jamielennox: no not reinventing the weel, just connecting it to the rods ;-)
19:01:00 <morganfainberg> marekd, and the reasoning is it _could_ support CLi nicely
19:01:00 <bknudson> did nova / cinder ever ask us if they should have new service for different versions?
19:01:05 <morganfainberg> marekd, but that is all speculation
19:01:07 <ayoung> dolphm, the problem is the old tools
19:01:09 <ayoung> not new
19:01:14 <jamielennox> time people
19:01:18 <atiwari> time is up
19:01:19 <ayoung> we go to great lengths to avoid breaking old clients
19:01:20 <dolphm> jamielennox: ah, thanks
19:01:28 <dolphm> #endmeeting