<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 5, 2015 at 3:43 PM, Doug Hellmann <span dir="ltr"><<a href="mailto:doug@doughellmann.com" target="_blank">doug@doughellmann.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Excerpts from Clint Byrum's message of 2015-11-05 10:09:49 -0800:<br>
<div><div class="h5">> Excerpts from Doug Hellmann's message of 2015-11-05 09:51:41 -0800:<br>
> > Excerpts from Adam Young's message of 2015-11-05 12:34:12 -0500:<br>
> > > Can people help me work through the right set of tools for this use case<br>
> > > (has come up from several Operators) and map out a plan to implement it:<br>
> > ><br>
> > > Large cloud with many users coming from multiple Federation sources has<br>
> > > a policy of providing a minimal setup for each user upon first visit to<br>
> > > the cloud: Create a project for the user with a minimal quota, and<br>
> > > provide them a role assignment.<br>
> > ><br>
> > > Here are the gaps, as I see it:<br>
> > ><br>
> > > 1. Keystone provides a notification that a user has logged in, but<br>
> > > there is nothing capable of executing on this notification at the<br>
> > > moment. Only Ceilometer listens to Keystone notifications.<br>
> > ><br>
> > > 2. Keystone does not have a workflow engine, and should not be<br>
> > > auto-creating projects. This is something that should be performed via<br>
> > > a Heat template, and Keystone does not know about Heat, nor should it.<br>
> > ><br>
> > > 3. The Mapping code is pretty static; it assumes a user entry or a<br>
> > > group entry in identity when creating a role assignment, and neither<br>
> > > will exist.<br>
> > ><br>
> > > We can assume a special domain for Federated users to have per-user<br>
> > > projects.<br>
> > ><br>
> > > So; lets assume a Heat Template that does the following:<br>
> > ><br>
> > > 1. Creates a user in the per-user-projects domain<br>
> > > 2. Assigns a role to the Federated user in that project<br>
> > > 3. Sets the minimal quota for the user<br>
> > > 4. Somehow notifies the user that the project has been set up.<br>
> > ><br>
> > > This last probably assumes an email address from the Federated<br>
> > > assertion. Otherwise, the user hits Horizon, gets a "not authenticated<br>
> > > for any projects" error, and is stumped.<br>
> > ><br>
> > > How is quota assignment done in the other projects now? What happens<br>
> > > when a project is created in Keystone? Does that information gets<br>
> > > transferred to the other services, and, if so, how? Do most people use<br>
> > > a custom provisioning tool for this workflow?<br>
> > ><br>
> ><br>
> > I know at Dreamhost we built some custom integration that was triggered<br>
> > when someone turned on the Dreamcompute service in their account in our<br>
> > existing user management system. That integration created the account in<br>
> > keystone, set up a default network in neutron, etc. I've long thought we<br>
> > needed a "new tenant creation" service of some sort, that sits outside<br>
> > of our existing services and pokes them to do something when a new<br>
> > tenant is established. Using heat as the implementation makes sense, for<br>
> > things that heat can control, but we don't want keystone to depend on<br>
> > heat and we don't want to bake such a specialized feature into heat<br>
> > itself.<br>
> ><br>
><br>
> I agree, an automation piece that is built-in and easy to add to<br>
> OpenStack would be great.<br>
><br>
> I do not agree that it should be Heat. Heat is for managing stacks that<br>
> live on and change over time and thus need the complexity of the graph<br>
> model Heat presents.<br>
><br>
> I'd actually say that Mistral or Ansible are better choices for this. A<br>
> service which listens to the notification bus and triggered a workflow<br>
> defined somewhere in either Ansible playbooks or Mistral's workflow<br>
> language would simply run through the "skel" workflow for each user.<br>
><br>
> The actual workflow would probably almost always be somewhat site<br>
> specific, but it would make sense for Keystone to include a few basic ones<br>
> as "contrib" elements. For instance, the "notify the user" piece would<br>
> likely be simplest if you just let the workflow tool send an email. But<br>
> if your cloud has Zaqar, you may want to use that as well or instead.<br>
><br>
> Adding Mistral here to see if they have some thoughts on how this<br>
> might work.<br>
><br>
> BTW, if this does form into a new project, I suggest naming it<br>
> Skeleton[1]<br>
<br>
</div></div>Following the pattern of Kite's naming, I think a Dirigible is a<br>
better way to get users into the cloud. :-)<br></blockquote><div><br></div><div>lol +1</div><div><br></div><div>Is this use case specifically for keystone-to-keystone, or for federation in general?</div><div><br></div><div>As an outcome of the Vancouver summit, we had a use case for mirroring a federated user's project ID from the identity provider cloud to the service provider cloud. The goal would be that a user can burst into a second cloud and immediately receive a token scoped to the same project ID that they're already familiar with (which implies a role assignment of some sort; for example, member). That would have to be done in real time though, not by a secondary service.</div><div><br></div><div>And with shadow users, we're looking at creating an identity (basically, nothing but a user_id) in the second cloud anyway. And as another consequence of shadow users, they wouldn't be getting a "federated token" of any sort, but rather a simpler, local token, referencing a local identity (the user_id that was just created automatically).</div><div><br></div><div>Adam, does any of this align with your use case?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
Doug<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
><br>
> [1] <a href="https://goo.gl/photos/EML6EPKeqRXioWfd8" rel="noreferrer" target="_blank">https://goo.gl/photos/EML6EPKeqRXioWfd8</a> (that was my front yard..)<br>
><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>