this would work as well, but wouldn't it require two different API calls? 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 >>> >> _______________________________________________ >> OpenStack-dev mailing list >> [email protected] >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
