Hi, ----- Original Message ----- > From: "Adam Young" <[email protected]> > To: [email protected] > Sent: Wednesday, September 17, 2014 5:00:16 PM > Subject: Re: [openstack-dev] [Keystone][Horizon] CORS and Federation > > On 09/17/2014 10:35 AM, David Chadwick wrote: > > > > this would work as well, but wouldn't it require two different API calls? > > I think it would be 2 calls no matter what. > > OK, lets talk this through: > > 1. Configure Horizon to return a generic login page, with a button that says > "Or do Federated" > 2. Use clicks that button and gets the Federated UI. No new HTTP request > needed for this, still just static Javascript. Form has an edit field for > the user to enter the SAML IdP, anda button to fetch the list of the public > IdPs from Keystone. > 3. Assume user clicks the list of public IdPs, those fill out a drop-down > box. If the user clicks on one, it populates the textbox with the URL for > the IdP. > 3a. However, if the users IdP is not in the list, they go back to the email > they got from their IT guy that has "Paste this URL into the IdP edit box" > > 4. User clicks OK. > > Window pops up with the WebUI for the user to visit the SAML IdP URL. This > will be of the form > > GET > htps://keystone/main/OS-FEDERATION/identity_providers/{identity_provider}/protocols/{protocol}/auth > > Which will perform the necessary redirects to get the user the SAML > assertion, and return it to Keystone. > > 5. Javascript picks up the Federated unscoped token from the response at the > end of step 4 and use that to get a scoped token. >
I think the jump to step 6 isn't unnecessary: logging in Horizon requires only a username and a password, unless I am wrong scoping is done afterwards by selecting a project in a list. Besides, should we expect a federated user to necessarily know beforehand to which domain/project she was mapped ? > > 6. Javascript submites the scoped token to Horizon and user is logged in. Horizon will also need to keep track of the fact that a federated auth was used: * to list projects and domains available to the user * to scope the unscoped saml token As these are done through the federation API rather than the usual one. > Whew. Whew indeed ! > > > > > > On 17/09/2014 15:17, Adam Young wrote: > > > > On 09/17/2014 10:07 AM, David Chadwick wrote: > > > > On 17/09/2014 14:55, Marek Denis wrote: > > > > On 17.09.2014 15:45, Steve Martinelli wrote: > > > > ++ to your suggestion David, I think making the list of trusted IdPs > publicly available makes sense. > I think this might be useful in an academic/science world but on the > other hand most cloud providers from the 'business' world might be very > reluctant to expose list of their clients for free. > It is interesting that this latter comment came from the > academic/science world, whereas the supportive one came from the > business world :-) > > So maybe there could be a config parameter in keystone to determine > which option is installed? > My thought was that there would be a public list, which is a subset of > the overall list. > > For non-publicized IdPs, the end users would get an URL out of band and > enter that in when prompted; if they enter an invalid URL, they would > get an warning message. > > It wouldn't hide the fact that a customer was registered with a given > cloud provider, but wouldn't advertise it, either. > > > > regards > > David > > > > cheers, > > Marek. > _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
