Open Stack

Hello everyone,

Thanks for the info and the feedback.

Looking at our current situation, it seems unlikely we are to be
switching to a federated Keystone. Is the preferred approach these days
to use a federated Keystone?

What we'd like to do is ideally have this service work using the
Keystone API. It should fit neatly into and add missing features to the
current OpenStack ecosystem, plus be easy to setup and gain access to
these features for people like ourselves who are using just Keystone
itself for identity.

Our primary purpose with OpenStack at present is running a semi-public
cloud. All our users are new or incoming so storing them in Keystone
isn't an issue, plus any users on our internal idp needing to use the
Cloud would ideally get signed up and managed by the project/client on
the cloud they are working in.


Enrique, if you have a github repo or some project pages you can point
me to that would be wonderful. I'm currently in the very early stages of
our proof of concept/prototype, so it would be great to see some work
others have done to solve similar issues. If I can find something that
works for a few of our use cases it might be a better starting point or
good to see what an approach others might find useful is.

I'd much rather not duplicate work, nor build something only useful for
our use cases, so collaboration towards a community variant would be ideal.

We will be discussing federated Keystone options, but it looks like too
much complexity at present, and most of the useful features we'd want I
assume won't be in until after Kilo.

Cheers,
Adrian Turjak



On 15/01/15 03:26, Enrique Garcia wrote:
> Hi all,
> 
> I'm working in a European project that uses OpenStack and I am using
> horizon and keystone for our users and organization management solution. We
> have some requirements similar to yours Adrian: we need to allow users to
> sign up themselves (with all the common functionality of email activation,
> forgot password) plus support authentication using OAuth2.0.
> 
> We are interested in having a standard open-source solution for these
> problems, therefore we are really interested in participating in this
> discussion to see other solutions for the problem, discuss them and
> collaborate in making such a service. I think this kind of requirements are
> common to anyone wanting to use OpenStack to build a public cloud system
> where there is no admin to create users.
> 
> In the meantime, we have developed our open-source system for them using
> keystone extensions and django apps which satisfy our requirements. If
> there is interest in them I can share and explain in more detail our
> approach to both problems, and help build a well-integrated solution for
> everyone.
> 
> Cheers,
> Enrique Garcia Navalon
> 
> 
> 
> 2015-01-14 13:14 GMT+01:00 David Chadwick <d.w.chadwick at kent.ac.uk>:
> 
>> Hi Adrian
>>
>> You might be glad to know that we have already produced a blueprint and
>> implementation for this, based on federated keystone and Horizon. You
>> can read the specs here
>>
>> https://blueprints.launchpad.net/keystone/+spec/vo-management
>>
>> and see a demo here
>> http://icehouse.sec.cs.kent.ac.uk/
>>
>> (However you will not be able to perform federated login without a
>> Facebook or Google account, and you will also need the name of the VO
>> role that you are to join, plus a secret/PIN - Contact me if you want one)
>>
>> Briefly, the administrator (could be keystone or domain admin) sets up a
>> VO role, sends the details to the users who are to become members of it,
>> along with a secret, and the user then logs in via his IdP (you can use
>> Facebook or Google), quoting the secret and VO role. He is then enrolled
>> in Keystone, either automatically, or pending admin approval (as a
>> config option). The user can resign from the VO role anytime he wishes.
>>
>> I have updated your etherpad giving my comments
>>
>> regards
>>
>> David
>>