[keystone] multiple federated keystones with single Identity Provider

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

[keystone] multiple federated keystones with single Identity Provider

Pavlo Shchelokovskyy
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?

Best regards,
--
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: [keystone] multiple federated keystones with single Identity Provider

Кирилл Беспалов
Hi, Pavlo.

Looks like it's not just project/domain UUID should be equal, but also audit_id, endpoints_id, protocol_id, roles_id and many other entities. 
So, looks like it is not possible to implement this using current code base, but I could be wrong.

You can take a look at mapped auth plugin [1] in order to investigate what exactly should be the same (ids).


Thanks.


[1] https://github.com/openstack/keystone/blob/master/keystone/auth/plugins/mapped.py#L37

On Thu, Dec 7, 2017 at 7:37 PM, Pavlo Shchelokovskyy <[hidden email]> wrote:
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?

Best regards,
--
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: [keystone] multiple federated keystones with single Identity Provider

Colleen Murphy-2
In reply to this post by Pavlo Shchelokovskyy
On Thu, Dec 7, 2017 at 5:37 PM, Pavlo Shchelokovskyy
<[hidden email]> wrote:

> 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?

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 https://review.openstack.org/#/c/323499/ if you're not
already aware of it, which has the goal of solving that problem.

It's also been brought up before:

https://review.openstack.org/#/c/403866/
http://lists.openstack.org/pipermail/openstack-dev/2016-December/108466.html

And we talked about it a lot at the last Forum (sorry my brief summary
does not really do the discussion justice):

http://www.gazlene.net/sydney-summit.html#keystone-operator-and-user-feedback

Lance mentioned today that we'd likely try to discuss it at our next
weekly meeting: http://eavesdrop.openstack.org/#Keystone_Team_Meeting

Colleen

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: [keystone] multiple federated keystones with single Identity Provider

Lance Bragstad-2


On 12/07/2017 12:27 PM, Colleen Murphy wrote:

> On Thu, Dec 7, 2017 at 5:37 PM, Pavlo Shchelokovskyy
> <[hidden email]> wrote:
>> 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?
> 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 https://review.openstack.org/#/c/323499/ if you're not
> already aware of it, which has the goal of solving that problem.
>
> It's also been brought up before:
>
> https://review.openstack.org/#/c/403866/
> http://lists.openstack.org/pipermail/openstack-dev/2016-December/108466.html
>
> And we talked about it a lot at the last Forum (sorry my brief summary
> does not really do the discussion justice):
>
> http://www.gazlene.net/sydney-summit.html#keystone-operator-and-user-feedback
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.
>
> Lance mentioned today that we'd likely try to discuss it at our next
> weekly meeting: http://eavesdrop.openstack.org/#Keystone_Team_Meeting
Yep, I have it on the agenda for the next meeting [1].

[0] https://www.lbragstad.com/blog/openstack-summit-sydney-recap
[1] https://etherpad.openstack.org/p/keystone-weekly-meeting
>
> Colleen
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: [hidden email]?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [keystone] multiple federated keystones with single Identity Provider

Boris Bobrov-2
Hi,

> On 12/07/2017 12:27 PM, Colleen Murphy wrote:
>> On Thu, Dec 7, 2017 at 5:37 PM, Pavlo Shchelokovskyy
>> <[hidden email]> wrote:
>>> 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?
>> 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 https://review.openstack.org/#/c/323499/ if you're not
>> already aware of it, which has the goal of solving that problem.
>>
>> It's also been brought up before:
>>
>> https://review.openstack.org/#/c/403866/
>> http://lists.openstack.org/pipermail/openstack-dev/2016-December/108466.html
>>
>> And we talked about it a lot at the last Forum (sorry my brief summary
>> does not really do the discussion justice):
>>
>> http://www.gazlene.net/sydney-summit.html#keystone-operator-and-user-feedback
> 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.
There is also cache invalidation issue. And that would make tokens of
various scope behave in a different manner. A year ago i was -2 on this,
and i still don't think this is a good idea.

If there is a demand to control several clouds from single place,
K2K support should be added where it is needed.


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [keystone] multiple federated keystones with single Identity Provider

Adam Heczko
Hi Pavlo, I think that there are viable alternatives to your specific use case having single external idp for federated auth.
Depending on your IT environment architecture and preferences you have the following possibilities, both of them are providing very smooth user experience:
- in AD centric environments connect each of Keystone services to AD and leverage Kerberos for SSO. You can consume REMOTE_USER and other variables from AD directly via mod_auth_gssapi and mod_lookup_identity. Advantage of this approach is that you can leverage AD native SSO mechanism based on SPNEGO. So you are not any longer  forcing users to perform SAML or OIDC referrals etc.
- in both AD or non AD centric environments you can leverage 'Tokenless Auth' plugin, which basically can also be used with Keystone to issue tokens (e.g. Fernet) and perform token scoping based on X.509 certificate properties. You can also configure specific X.509 certificate attributes e.g. SAN or subjectDirectoryAttributes to control access for specific region or Keystone instance.

On Fri, Dec 8, 2017 at 1:25 AM, Boris Bobrov <[hidden email]> wrote:
Hi,

> On 12/07/2017 12:27 PM, Colleen Murphy wrote:
>> On Thu, Dec 7, 2017 at 5:37 PM, Pavlo Shchelokovskyy
>> <[hidden email]> wrote:
>>> 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?
>> 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 https://review.openstack.org/#/c/323499/ if you're not
>> already aware of it, which has the goal of solving that problem.
>>
>> It's also been brought up before:
>>
>> https://review.openstack.org/#/c/403866/
>> http://lists.openstack.org/pipermail/openstack-dev/2016-December/108466.html
>>
>> And we talked about it a lot at the last Forum (sorry my brief summary
>> does not really do the discussion justice):
>>
>> http://www.gazlene.net/sydney-summit.html#keystone-operator-and-user-feedback
> 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.

There is also cache invalidation issue. And that would make tokens of
various scope behave in a different manner. A year ago i was -2 on this,
and i still don't think this is a good idea.

If there is a demand to control several clouds from single place,
K2K support should be added where it is needed.


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




--
Adam Heczko
Security Engineer @ Mirantis Inc.

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: [keystone] multiple federated keystones with single Identity Provider

Adrian Turjak
In reply to this post by Lance Bragstad-2
On 08/12/17 11:47, Lance Bragstad wrote:

On 12/07/2017 12:27 PM, Colleen Murphy wrote:
On Thu, Dec 7, 2017 at 5:37 PM, Pavlo Shchelokovskyy
[hidden email] wrote:
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?
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 https://review.openstack.org/#/c/323499/ if you're not
already aware of it, which has the goal of solving that problem.

It's also been brought up before:

https://review.openstack.org/#/c/403866/
http://lists.openstack.org/pipermail/openstack-dev/2016-December/108466.html

And we talked about it a lot at the last Forum (sorry my brief summary
does not really do the discussion justice):

http://www.gazlene.net/sydney-summit.html#keystone-operator-and-user-feedback
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.

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.

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).

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. :(

      
Lance mentioned today that we'd likely try to discuss it at our next
weekly meeting: http://eavesdrop.openstack.org/#Keystone_Team_Meeting
Yep, I have it on the agenda for the next meeting [1].

[0] https://www.lbragstad.com/blog/openstack-summit-sydney-recap
[1] https://etherpad.openstack.org/p/keystone-weekly-meeting
Colleen

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev