settingsLogin | Registersettings

[openstack-dev] Fwd: keystone federation user story

0 votes

Colleagues,

here is an actual use case for shadow users assignments, let's discuss
possible solutions: all suggestions are appreciated.

---------- Forwarded message ----------
From: Andrey Grebennikov agrebennikov@mirantis.com
Date: Tue, May 24, 2016 at 9:43 AM
Subject: keystone federation user story
To: Alexander Makarov amakarov@mirantis.com

Main production usecase:
As a system administrator I need to create assignments for federated users
into the projects when the user has not authenticated for the first time.

Two different approaches.
1. A user has to be assigned directly into the project with the role Role1.
Since shadow users were implemented, Keystone database has the record of
the user when the federated user authenticates for the first time. When it
happens, the user gets unscoped token and Keystone registers the user in
the database with generated ID (the result of hashing the name and the
domain). At this point the user cannot get scoped token yet since the user
has not been assigned to any project.
Nonetheless there was a bug https://bugs.launchpad.net/keystone/+bug/1313956
which was abandoned, and the reporter says that currently it is possible to
assign role in the project to non-existing user (API only, no CLI). It
doesn't help much though since it is barely possible to predict the ID of
the user if it doesn't exist yet.

Potential solution - allow per-user project auto-creation. This will allow
the user to get scoped token with a pre-defined role (should be either
mentioned in config or in mapping) and execute operations right away.

Disadvantages: less control and order (will potentially end up with
infinite empty projects).
Benefits: user is authorized right away.

Another potential solution - clearly describe a possibility to assign
shadow user to a project (client should generate the ID correctly), even
though the user has not been authenticated for the first time yet.

Disadvantages: high risk of administrator's mistake when typing user's ID.
Benefits: user doesn't have to execute first dummy authentication in order
to be registered.

  1. Operate with the groups. It means that the user is a member of the
    remote group and we propose the groups to be assigned to the projects
    instead of the users.
    There is no concept of shadow groups yet, so it still has to be implemented.

Same problem - in order to be able to assign the group to the project
currently it has to exist in Keystone database.

It should be either allowed to pre-create the project for a group (based on
some specific flags in mappings), or it should be allowed to assign
non-existing groups into the projects.

I'd personally prefer to allow some special attribute to be specified in
either the config or mapping which will allow project auto-creation.
For example, user is added to the group "openstack" in the backend. In this
case this group is the part of SAML assertions (in case when SAML2 is used
as the protocol), and Keystone should recognize this group through the
mapping. When user makes login attempt, Keystone should pre-create the
project and assign pre-defined role in it. User gets access right away.

--
Andrey Grebennikov
Deployment Engineer
Mirantis Inc, Mountain View, CA

--
Kind Regards,
Alexander Makarov,
Senior Software Developer,

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
asked May 24, 2016 in openstack-dev by Alexander_V_Makarov (900 points)   1 2
retagged Jan 25, 2017 by admin

4 Responses

0 votes

On 05/24/2016 01:55 PM, Alexander Makarov wrote:
Colleagues,

here is an actual use case for shadow users assignments, let's discuss
possible solutions: all suggestions are appreciated.

---------- Forwarded message ----------
From: Andrey Grebennikov <agrebennikov@mirantis.com
agrebennikov@mirantis.com>
Date: Tue, May 24, 2016 at 9:43 AM
Subject: keystone federation user story
To: Alexander Makarov <amakarov@mirantis.com
amakarov@mirantis.com>

Main production usecase:
As a system administrator I need to create assignments for federated
users into the projects when the user has not authenticated for the
first time.

Two different approaches.
1. A user has to be assigned directly into the project with the role
Role1. Since shadow users were implemented, Keystone database has the
record of the user when the federated user authenticates for the first
time. When it happens, the user gets unscoped token and Keystone
registers the user in the database with generated ID (the result of
hashing the name and the domain). At this point the user cannot get
scoped token yet since the user has not been assigned to any project.
Nonetheless there was a bug
https://bugs.launchpad.net/keystone/+bug/1313956 which was abandoned,
and the reporter says that currently it is possible to assign role in
the project to non-existing user (API only, no CLI). It doesn't help
much though since it is barely possible to predict the ID of the user
if it doesn't exist yet.

Potential solution - allow per-user project auto-creation. This will
allow the user to get scoped token with a pre-defined role (should be
either mentioned in config or in mapping) and execute operations right
away.

What we discussed at the summit was the ability for some power user to
pre=-create the shadow user record by passing in the data that that
would be mapped:

Kerberos example
{
Realm: YOUNGLOGIC.NET
Principal: ayoung@YOUNGLOGIC.NET
REMOTE_GROUPS: ipausers,demo,bookworms
}

Another API will allow for query if a user exists.

Disadvantages: less control and order (will potentially end up with
infinite empty projects).
Benefits: user is authorized right away.

Another potential solution - clearly describe a possibility to assign
shadow user to a project (client should generate the ID correctly),
even though the user has not been authenticated for the first time yet.

Disadvantages: high risk of administrator's mistake when typing user's ID.
Benefits: user doesn't have to execute first dummy authentication in
order to be registered.

  1. Operate with the groups. It means that the user is a member of the
    remote group and we propose the groups to be assigned to the projects
    instead of the users.
    There is no concept of shadow groups yet, so it still has to be
    implemented.

Same problem - in order to be able to assign the group to the project
currently it has to exist in Keystone database.

It should be either allowed to pre-create the project for a group
(based on some specific flags in mappings), or it should be allowed to
assign non-existing groups into the projects.

I'd personally prefer to allow some special attribute to be specified
in either the config or mapping which will allow project auto-creation.
For example, user is added to the group "openstack" in the backend. In
this case this group is the part of SAML assertions (in case when
SAML2 is used as the protocol), and Keystone should recognize this
group through the mapping. When user makes login attempt, Keystone
should pre-create the project and assign pre-defined role in it. User
gets access right away.

--
Andrey Grebennikov
Deployment Engineer
Mirantis Inc, Mountain View, CA

--
Kind Regards,
Alexander Makarov,
Senior Software Developer,

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: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded May 25, 2016 by Adam_Young (19,940 points)   2 7 12
0 votes

On 05/24/2016 10:30 PM, Adam Young wrote:
On 05/24/2016 01:55 PM, Alexander Makarov wrote:

Colleagues,

here is an actual use case for shadow users assignments, let's
discuss possible solutions: all suggestions are appreciated.

---------- Forwarded message ----------
From: Andrey Grebennikov <agrebennikov@mirantis.com
agrebennikov@mirantis.com>
Date: Tue, May 24, 2016 at 9:43 AM
Subject: keystone federation user story
To: Alexander Makarov <amakarov@mirantis.com
amakarov@mirantis.com>

Main production usecase:
As a system administrator I need to create assignments for federated
users into the projects when the user has not authenticated for the
first time.

Two different approaches.
1. A user has to be assigned directly into the project with the role
Role1. Since shadow users were implemented, Keystone database has the
record of the user when the federated user authenticates for the
first time. When it happens, the user gets unscoped token and
Keystone registers the user in the database with generated ID (the
result of hashing the name and the domain). At this point the user
cannot get scoped token yet since the user has not been assigned to
any project.
Nonetheless there was a bug
https://bugs.launchpad.net/keystone/+bug/1313956 which was abandoned,
and the reporter says that currently it is possible to assign role in
the project to non-existing user (API only, no CLI). It doesn't help
much though since it is barely possible to predict the ID of the user
if it doesn't exist yet.

Potential solution - allow per-user project auto-creation. This will
allow the user to get scoped token with a pre-defined role (should be
either mentioned in config or in mapping) and execute operations
right away.

What we discussed at the summit was the ability for some power user to
pre=-create the shadow user record by passing in the data that that
would be mapped:

Kerberos example
{
Realm: YOUNGLOGIC.NET
Principal: ayoung@YOUNGLOGIC.NET
REMOTE_GROUPS: ipausers,demo,bookworms
}

Another API will allow for query if a user exists.

Spec is here

https://review.openstack.org/#/c/313604/

Disadvantages: less control and order (will potentially end up with
infinite empty projects).
Benefits: user is authorized right away.

Another potential solution - clearly describe a possibility to assign
shadow user to a project (client should generate the ID correctly),
even though the user has not been authenticated for the first time yet.

Disadvantages: high risk of administrator's mistake when typing
user's ID.
Benefits: user doesn't have to execute first dummy authentication in
order to be registered.

  1. Operate with the groups. It means that the user is a member of the
    remote group and we propose the groups to be assigned to the projects
    instead of the users.
    There is no concept of shadow groups yet, so it still has to be
    implemented.

Same problem - in order to be able to assign the group to the project
currently it has to exist in Keystone database.

It should be either allowed to pre-create the project for a group
(based on some specific flags in mappings), or it should be allowed
to assign non-existing groups into the projects.

I'd personally prefer to allow some special attribute to be specified
in either the config or mapping which will allow project auto-creation.
For example, user is added to the group "openstack" in the backend.
In this case this group is the part of SAML assertions (in case when
SAML2 is used as the protocol), and Keystone should recognize this
group through the mapping. When user makes login attempt, Keystone
should pre-create the project and assign pre-defined role in it. User
gets access right away.

--
Andrey Grebennikov
Deployment Engineer
Mirantis Inc, Mountain View, CA

--
Kind Regards,
Alexander Makarov,
Senior Software Developer,

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: 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: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded May 25, 2016 by Adam_Young (19,940 points)   2 7 12
0 votes

On 25 May 2016 at 03:55, Alexander Makarov amakarov@mirantis.com wrote:

Colleagues,

here is an actual use case for shadow users assignments, let's discuss
possible solutions: all suggestions are appreciated.

---------- Forwarded message ----------
From: Andrey Grebennikov agrebennikov@mirantis.com
Date: Tue, May 24, 2016 at 9:43 AM
Subject: keystone federation user story
To: Alexander Makarov amakarov@mirantis.com

Main production usecase:
As a system administrator I need to create assignments for federated users
into the projects when the user has not authenticated for the first time.

Two different approaches.
1. A user has to be assigned directly into the project with the role
Role1. Since shadow users were implemented, Keystone database has the
record of the user when the federated user authenticates for the first
time. When it happens, the user gets unscoped token and Keystone registers
the user in the database with generated ID (the result of hashing the name
and the domain). At this point the user cannot get scoped token yet since
the user has not been assigned to any project.
Nonetheless there was a bug
https://bugs.launchpad.net/keystone/+bug/1313956 which was abandoned, and
the reporter says that currently it is possible to assign role in the
project to non-existing user (API only, no CLI). It doesn't help much
though since it is barely possible to predict the ID of the user if it
doesn't exist yet.

Potential solution - allow per-user project auto-creation. This will allow
the user to get scoped token with a pre-defined role (should be either
mentioned in config or in mapping) and execute operations right away.

Disadvantages: less control and order (will potentially end up with
infinite empty projects).
Benefits: user is authorized right away.

This is something that has come up a few times as a workflow problem. For
some group of users you should end up with your own project that doesn't
exist until the first time you log in. This is something i think we could
extend the mapper to handle. It wouldn't be user authenticated immediately,
just solve the workflow of personal projects.

Another potential solution - clearly describe a possibility to assign
shadow user to a project (client should generate the ID correctly), even
though the user has not been authenticated for the first time yet.

Disadvantages: high risk of administrator's mistake when typing user's ID.
Benefits: user doesn't have to execute first dummy authentication in order
to be registered.

I would prefer not to do this. It either involves creating a user and then
somehow associating what federated information they will present with
later, or allowing you to create a user with a predetermined or predictable
id. I dont think we should add either of those APIs.

  1. Operate with the groups. It means that the user is a member of the
    remote group and we propose the groups to be assigned to the projects
    instead of the users.
    There is no concept of shadow groups yet, so it still has to be
    implemented.

Same problem - in order to be able to assign the group to the project
currently it has to exist in Keystone database.

I'm not sure what you want for shadow groups here. Groups are always a
keystone concept, they have never been ephemeral in the way that federated
users used to be. Are you wanting to make it so that keystone groups are
auto created?

Mapping federated users into groups has always been the way federation was
designed in keystone because even though you can't know the actual users
that are going to log in, it is very likely they fall into something that
can fairly easily be categorized by looking at the roles that come in from
the IDP assertion. So your mapping does something like "if user has the
admin role put them in the federated-admin group", the federated-admin
group has already been established and already has roles on a number of
projects. Users are then automatically granted those roles on those
projects. You could go so far as to check for user names in the mapping
here but that's not a sustainable solution.

It should be either allowed to pre-create the project for a group (based
on some specific flags in mappings),

maybe - if you created the groups why don't you know the projects they are
going to be in?

or it should be allowed to assign non-existing groups into the projects.

still not sure on this non-existing groups concept.

I'd personally prefer to allow some special attribute to be specified in
either the config or mapping which will allow project auto-creation.
For example, user is added to the group "openstack" in the backend. In
this case this group is the part of SAML assertions (in case when SAML2 is
used as the protocol), and Keystone should recognize this group through the
mapping. When user makes login attempt, Keystone should pre-create the
project and assign pre-defined role in it. User gets access right away.

So yea, i'm interested in why the current federation mapping users to
groups isn't what you're asking for? I can see the auto create project for
user case, but i'm struggling to see why you would want to auto create
projects for groups of users you didn't set up.

--
Andrey Grebennikov
Deployment Engineer
Mirantis Inc, Mountain View, CA

--
Kind Regards,
Alexander Makarov,
Senior Software Developer,

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: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded May 25, 2016 by jamielennox_at_gmail (1,700 points)   1
0 votes

On Wed, May 25, 2016 at 2:57 AM Jamie Lennox jamielennox@gmail.com wrote:

On 25 May 2016 at 03:55, Alexander Makarov amakarov@mirantis.com wrote:

Colleagues,

here is an actual use case for shadow users assignments, let's discuss
possible solutions: all suggestions are appreciated.

---------- Forwarded message ----------
From: Andrey Grebennikov agrebennikov@mirantis.com
Date: Tue, May 24, 2016 at 9:43 AM
Subject: keystone federation user story
To: Alexander Makarov amakarov@mirantis.com

Main production usecase:
As a system administrator I need to create assignments for federated
users into the projects when the user has not authenticated for the first
time.

Two different approaches.
1. A user has to be assigned directly into the project with the role
Role1. Since shadow users were implemented, Keystone database has the
record of the user when the federated user authenticates for the first
time. When it happens, the user gets unscoped token and Keystone registers
the user in the database with generated ID (the result of hashing the name
and the domain). At this point the user cannot get scoped token yet since
the user has not been assigned to any project.
Nonetheless there was a bug
https://bugs.launchpad.net/keystone/+bug/1313956 which was abandoned,
and the reporter says that currently it is possible to assign role in the
project to non-existing user (API only, no CLI). It doesn't help much
though since it is barely possible to predict the ID of the user if it
doesn't exist yet.

Potential solution - allow per-user project auto-creation. This will
allow the user to get scoped token with a pre-defined role (should be
either mentioned in config or in mapping) and execute operations right away.

Disadvantages: less control and order (will potentially end up with
infinite empty projects).
Benefits: user is authorized right away.

This is something that has come up a few times as a workflow problem. For
some group of users you should end up with your own project that doesn't
exist until the first time you log in. This is something i think we could
extend the mapper to handle. It wouldn't be user authenticated immediately,
just solve the workflow of personal projects.

I completely agree with the solution that Jamie is describing here
(although I think it has even more potential than just personal projects),
and attempted to capture it in this keystone spec:

https://review.openstack.org/#/c/324055/

Another potential solution - clearly describe a possibility to assign
shadow user to a project (client should generate the ID correctly), even
though the user has not been authenticated for the first time yet.

Disadvantages: high risk of administrator's mistake when typing user's ID.
Benefits: user doesn't have to execute first dummy authentication in
order to be registered.

I would prefer not to do this. It either involves creating a user and then
somehow associating what federated information they will present with
later, or allowing you to create a user with a predetermined or predictable
id. I dont think we should add either of those APIs.

  1. Operate with the groups. It means that the user is a member of the
    remote group and we propose the groups to be assigned to the projects
    instead of the users.
    There is no concept of shadow groups yet, so it still has to be
    implemented.

Same problem - in order to be able to assign the group to the project
currently it has to exist in Keystone database.

I'm not sure what you want for shadow groups here. Groups are always a
keystone concept, they have never been ephemeral in the way that federated
users used to be. Are you wanting to make it so that keystone groups are
auto created?

Mapping federated users into groups has always been the way federation was
designed in keystone because even though you can't know the actual users
that are going to log in, it is very likely they fall into something that
can fairly easily be categorized by looking at the roles that come in from
the IDP assertion. So your mapping does something like "if user has the
admin role put them in the federated-admin group", the federated-admin
group has already been established and already has roles on a number of
projects. Users are then automatically granted those roles on those
projects. You could go so far as to check for user names in the mapping
here but that's not a sustainable solution.

It should be either allowed to pre-create the project for a group (based
on some specific flags in mappings),

maybe - if you created the groups why don't you know the projects they are
going to be in?

or it should be allowed to assign non-existing groups into the projects.

still not sure on this non-existing groups concept.

I'd personally prefer to allow some special attribute to be specified in
either the config or mapping which will allow project auto-creation.
For example, user is added to the group "openstack" in the backend. In
this case this group is the part of SAML assertions (in case when SAML2 is
used as the protocol), and Keystone should recognize this group through the
mapping. When user makes login attempt, Keystone should pre-create the
project and assign pre-defined role in it. User gets access right away.

So yea, i'm interested in why the current federation mapping users to
groups isn't what you're asking for? I can see the auto create project for
user case, but i'm struggling to see why you would want to auto create
projects for groups of users you didn't set up.

--
Andrey Grebennikov
Deployment Engineer
Mirantis Inc, Mountain View, CA

--
Kind Regards,
Alexander Makarov,
Senior Software Developer,

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: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
-Dolph


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
responded Jun 1, 2016 by Dolph_Mathews (9,560 points)   1 2 3
...