Open Stack

On 09/17/2014 11:56 AM, Matthieu Huin wrote:
> Hi,
>
> ----- Original Message -----
>> From: "Adam Young" <ayoung at redhat.com>
>> To: openstack-dev at lists.openstack.org
>> 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 ?

Think of it this way;  today, Horizon uses the userid and password to 
get a token.  In the case where that password is in LDAP, Horizon should 
never, ever see it.  Even  Keystone should never see it.  So the Token 
abstracts that away, and says  instead "I've checked their password.  
its good."

>
>> 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:
Once Horizon has a token, it can do all this.  Federation is kindof 
irrelevant.
>
> * 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
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev