Open Stack

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.


6.  Javascript submites the scoped token to Horizon and user is logged in.

Whew.


>
> 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
>>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140917/7d93cc77/attachment.html>