For those who may be following along and are not familiar with what we mean by federated auto-provisioning [0].
[0] https://docs.openstack.org/keystone/latest/advanced-topics/federation/federated_identity.html#auto-provisioning On Wed, Sep 26, 2018 at 9:06 AM Morgan Fainberg <morgan.fainb...@gmail.com> wrote: > 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 ( > similar.to 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. > > I don't want user/explicit admin set IDs. > > On Wed, Sep 26, 2018, 04:43 Jay Pipes <jaypi...@gmail.com> wrote: > >> On 09/26/2018 05:10 AM, Colleen Murphy wrote: >> > Thanks for the summary, Ildiko. I have some questions inline. >> > >> > On Tue, Sep 25, 2018, at 11:23 AM, Ildiko Vancsa wrote: >> > >> > <snipped> >> > >> >> >> >> We agreed to prefer federation for Keystone and came up with two work >> >> items to cover missing functionality: >> >> >> >> * Keystone to trust a token from an ID Provider master and when the >> auth >> >> method is called, perform an idempotent creation of the user, project >> >> and role assignments according to the assertions made in the token >> > >> > 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. >> > >> >> * Keystone should support the creation of users and projects with >> >> predictable UUIDs (eg.: hash of the name of the users and projects). >> >> This greatly simplifies Image federation and telemetry gathering >> > >> > 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? >> >> Hi Colleen, >> >> I wasn't in the room for this conversation either, but I believe the >> "use case" wanted here is mostly a convenience one. If the edge >> deployment is composed of hundreds of small Keystone installations and >> you have a user (e.g. an NFV MANO user) which should have visibility >> across all of those Keystone installations, it becomes a hassle to need >> to remember (or in the case of headless users, store some lookup of) all >> the different tenant and user UUIDs for what is essentially the same >> user across all of those Keystone installations. >> >> I'd argue that as long as it's possible to create a Keystone tenant and >> user with a unique name within a deployment, and as long as it's >> possible to authenticate using the tenant and user *name* (i.e. not the >> UUID), then this isn't too big of a problem. However, I do know that a >> bunch of scripts and external tools rely on setting the tenant and/or >> user via the UUID values and not the names, so that might be where this >> feature request is coming from. >> >> Hope that makes sense? >> >> Best, >> -jay >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
