<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
On 08/12/17 11:47, Lance Bragstad wrote:<br>
<blockquote type="cite"
cite="mid:38c08ac0-c38f-a39c-15a1-dc4bdcd3aec0@gmail.com">
<pre wrap="">
On 12/07/2017 12:27 PM, Colleen Murphy wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On Thu, Dec 7, 2017 at 5:37 PM, Pavlo Shchelokovskyy
<a class="moz-txt-link-rfc2396E" href="mailto:pshchelokovskyy@mirantis.com"><pshchelokovskyy@mirantis.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi all,
We have a following use case - several independent keystones (say KeyA and
KeyB), using fernet tokens and synchronized fernet keys, and single external
IdP for federated auth.
Is it generally possible to configure both KeyA and KeyB such that scoped
token issued by KeyA for a federated user is valid on KeyB?
Currently we have the next problem - although domains/projects where
keystone's mapping engine assigns federated users are equal by name between
KeyA and KeyB, the UUIDs of projects/domains in KeyA and KeyB are
different, which seems to invalidate the scoped token issued by KeyA when
trying to use it for KeyB. And it is not possible to create projects/domains
with specific UUIDs via keystone API (which would probably solve this
problem for non-autoprovisioned projects).
Is such usage scenario supported? Or one should always use the unscoped
token first to list projects/domains available on a specific keystone
instance and then get a scoped token for usage o this instance only?
</pre>
</blockquote>
<pre wrap="">No, it is not currently possible to use the same token on projects in
different keystones, for the reasons you gave. You might be interested
in following <a class="moz-txt-link-freetext" href="https://review.openstack.org/#/c/323499/">https://review.openstack.org/#/c/323499/</a> if you're not
already aware of it, which has the goal of solving that problem.
It's also been brought up before:
<a class="moz-txt-link-freetext" href="https://review.openstack.org/#/c/403866/">https://review.openstack.org/#/c/403866/</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/pipermail/openstack-dev/2016-December/108466.html">http://lists.openstack.org/pipermail/openstack-dev/2016-December/108466.html</a>
And we talked about it a lot at the last Forum (sorry my brief summary
does not really do the discussion justice):
<a class="moz-txt-link-freetext" href="http://www.gazlene.net/sydney-summit.html#keystone-operator-and-user-feedback">http://www.gazlene.net/sydney-summit.html#keystone-operator-and-user-feedback</a>
</pre>
</blockquote>
<pre wrap="">I had a snippet about it in my recap under the "Other Feedback" section
[0]. The TL;DR in my opinion is that we originally thought we could
solve the problem with federation 100%, and if we couldn't we wanted to
try and improve the parts of federation that would make that possible.
The interesting bit we came up with during the feedback session in
Sydney is what happens if a user no longer has a role on a project. For
example;
- A user has a role on Project A and in the us-east region and the
us-west region, each region has it's own keystone deployment, but let's
assume the ID for Project A are the same in each region
- A user authenticates for a token scoped to Project A and starts
creating instances in both regions
- The user has their role from Project A removed in us-east, but not in
us-west
- The user isn't able to do anything within us-east since they no longer
have a role assignment on Project A in that region, but they can still
take the invalid token from the us-east region and effectively use it in
the us-west region
Without replicating revocation events, or syncing the assignment table,
this will lead to security concerns.</pre>
</blockquote>
<br>
Also worth noting is that this assumes both keystones have the same
fernet keys, so as to be able to generate tokens that the other can
read.<br>
<br>
From memory, the whole point of this exercise from the regulations
side was to make it so that data isn't 'replicated' and if one
keystone was compromised, the other wouldn't be, but if the fernet
keys are the same, then its still very bad if the host is
compromised, since with the fernet keys from the compromised
keystone, you can now make bogus tokens that the other keystone
would trust. So that still doesn't solve the problem and still
probably falls out of regulations. In truth most of this sounds like
a loop hole around the regulations anyway rather than honoring what
they might intend (would be interesting to find out more about
that).<br>
<br>
Unless I'm misremembering, this is all so that users in both
'regions' can pretend it's all part of the same cloud, when in truth
it isn't really, and the regulations require that they are separate.
Making that fact clear, and that users have to swap between clouds,
or generate a token for each isn't that bad, and is overall much
much safer. The user can have the same project name in both, and
getting a token from either is as simple as just changing the auth
url. Writing code to account for this difference is probably easier
than trying to solve this problem in keystone and introducing weird
potential security problems. :(<br>
<blockquote type="cite"
cite="mid:38c08ac0-c38f-a39c-15a1-dc4bdcd3aec0@gmail.com">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">
Lance mentioned today that we'd likely try to discuss it at our next
weekly meeting: <a class="moz-txt-link-freetext" href="http://eavesdrop.openstack.org/#Keystone_Team_Meeting">http://eavesdrop.openstack.org/#Keystone_Team_Meeting</a>
</pre>
</blockquote>
<pre wrap="">Yep, I have it on the agenda for the next meeting [1].
[0] <a class="moz-txt-link-freetext" href="https://www.lbragstad.com/blog/openstack-summit-sydney-recap">https://www.lbragstad.com/blog/openstack-summit-sydney-recap</a>
[1] <a class="moz-txt-link-freetext" href="https://etherpad.openstack.org/p/keystone-weekly-meeting">https://etherpad.openstack.org/p/keystone-weekly-meeting</a>
</pre>
<blockquote type="cite">
<pre wrap="">
Colleen
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<pre wrap="">
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>