<div dir="ltr">For those who may be following along and are not familiar with what we mean by federated auto-provisioning [0].<div><br></div><div>[0] <a href="https://docs.openstack.org/keystone/latest/advanced-topics/federation/federated_identity.html#auto-provisioning">https://docs.openstack.org/keystone/latest/advanced-topics/federation/federated_identity.html#auto-provisioning</a></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Sep 26, 2018 at 9:06 AM Morgan Fainberg <<a href="mailto:morgan.fainberg@gmail.com">morgan.fainberg@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">This discussion was also not about user assigned IDs, but predictable IDs with the auto provisioning. We still want it to be something keystone controls (locally). It might be hash domain ID and value from assertion (<a href="http://similar.to" target="_blank">similar.to</a> the LDAP user ID generator). As long as within an environment, the IDs are predictable when auto provisioning via federation, we should be good. And the problem of the totally unknown ID until provisioning could be made less of an issue for someone working within a massively federated edge environment. <div dir="auto"><br></div><div dir="auto">I don't want user/explicit admin set IDs.</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Sep 26, 2018, 04:43 Jay Pipes <<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 09/26/2018 05:10 AM, Colleen Murphy wrote:<br>
> Thanks for the summary, Ildiko. I have some questions inline.<br>
> <br>
> On Tue, Sep 25, 2018, at 11:23 AM, Ildiko Vancsa wrote:<br>
> <br>
> <snipped><br>
> <br>
>><br>
>> We agreed to prefer federation for Keystone and came up with two work<br>
>> items to cover missing functionality:<br>
>><br>
>> * Keystone to trust a token from an ID Provider master and when the auth<br>
>> method is called, perform an idempotent creation of the user, project<br>
>> and role assignments according to the assertions made in the token<br>
> <br>
> This sounds like it is based on the customizations done at Oath, which to my recollection did not use the actual federation implementation in keystone due to its reliance on Athenz (I think?) as an identity manager. Something similar can be accomplished in standard keystone with the mapping API in keystone which can cause dynamic generation of a shadow user, project and role assignments.<br>
> <br>
>> * Keystone should support the creation of users and projects with<br>
>> predictable UUIDs (eg.: hash of the name of the users and projects).<br>
>> This greatly simplifies Image federation and telemetry gathering<br>
> <br>
> I was in and out of the room and don't recall this discussion exactly. We have historically pushed back hard against allowing setting a project ID via the API, though I can see predictable-but-not-settable as less problematic. One of the use cases from the past was being able to use the same token in different regions, which is problematic from a security perspective. Is that that idea here? Or could someone provide more details on why this is needed?<br>
<br>
Hi Colleen,<br>
<br>
I wasn't in the room for this conversation either, but I believe the <br>
"use case" wanted here is mostly a convenience one. If the edge <br>
deployment is composed of hundreds of small Keystone installations and <br>
you have a user (e.g. an NFV MANO user) which should have visibility <br>
across all of those Keystone installations, it becomes a hassle to need <br>
to remember (or in the case of headless users, store some lookup of) all <br>
the different tenant and user UUIDs for what is essentially the same <br>
user across all of those Keystone installations.<br>
<br>
I'd argue that as long as it's possible to create a Keystone tenant and <br>
user with a unique name within a deployment, and as long as it's <br>
possible to authenticate using the tenant and user *name* (i.e. not the <br>
UUID), then this isn't too big of a problem. However, I do know that a <br>
bunch of scripts and external tools rely on setting the tenant and/or <br>
user via the UUID values and not the names, so that might be where this <br>
feature request is coming from.<br>
<br>
Hope that makes sense?<br>
<br>
Best,<br>
-jay<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 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 noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div>
__________________________________________________________________________<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>
</blockquote></div>