Public bug reported:
Problem Description
===================
When configuring/creating credentials to enable machine to machine
integrations (e.g. backup systems, auditing tools, monitoring, and others),
the used credentials belong to the project where they are being applied;
therefore, it makes sense to enable operators to assign/create
credentials that are owned by a project, and not by a combination of
project and user.
Users should still be able to create credentials for themselves, and
their projects. The goal here is to enable the creation of credentials
for projects. Therefore, the current behavior is maintained. We can then,
restrict the API to create project credentials to super admins/operators.
People normally work around this issue by creating dummy users to hold
credentials, but that is not the best method to handle this situations.
Proposed Change
===============
The POST "/v3/credentials" API will allow the creation of credentials
with a project ID (without user ID).
To achieve that, we need to change the API schema validation for the
POST method to consider as mandatory either a project ID or a user ID.
This also means, we can still create credentials for a user ID and Project ID.
Moreover, we also need to change the database schema for the
`credential` table. Currently, the field `user_id` is not nullable in
the table. Therefore, we need to convert it to a nullable column.
Moreover, due to this change, we need to enforce via Python code that
the user enters at least project ID or user ID; otherwise, it would be
possible to create credentials that do not belong to any project or
user.
** Affects: keystone
Importance: Undecided
Assignee: Rafael Weingartner (rafaelweingartner)
Status: New
** Description changed:
Problem Description
===================
When configuring/creating credentials to enable machine to machine
integrations (e.g. backup systems, auditing tools, monitoring, and others),
the used credentials belong to the project where they are being applied;
- therefore, it makes sense to enable operators to assign/create
- credentials that are owned by a project, and not by a combination of
+ therefore, it makes sense to enable operators to assign/create
+ credentials that are owned by a project, and not by a combination of
project and user.
Users should still be able to create credentials for themselves, and
their projects. The goal here is to enable the creation of credentials
- for projects. Therefore, the current behavior is maintained. We can then,
+ for projects. Therefore, the current behavior is maintained. We can then,
restrict the API to create project credentials to super admins/operators.
- People normally work around this issue by creating dummy users to hold
+ People normally work around this issue by creating dummy users to hold
credentials, but that is not the best method to handle this situations.
-
Proposed Change
===============
The POST "/v3/credentials" API will allow the creation of credentials
with a project ID (without user ID).
To achieve that, we need to change the API schema validation for the
POST method to consider as mandatory either a project ID or a user ID.
This also means, we can still create credentials for a user ID and Project ID.
- Moreover, we also need to change the database schema for the `credential`
table.
- Currently, the field `user_id` is not nullable in the table. Therefore, we
need
- to convert it to a nullable column. Moreover, due to this change, we need to
enforce
- via Python code that the user enters at least project ID or user ID;
otherwise,
- it would be possible to create credentials that do not belong to any project
or user.
+ Moreover, we also need to change the database schema for the
+ `credential` table. Currently, the field `user_id` is not nullable in
+ the table. Therefore, we need to convert it to a nullable column.
+ Moreover, due to this change, we need to enforce via Python code that
+ the user enters at least project ID or user ID; otherwise, it would be
+ possible to create credentials that do not belong to any project or
+ user.
** Changed in: keystone
Assignee: (unassigned) => Rafael Weingartner (rafaelweingartner)
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1907810
Title:
[RFE] Enable credentials to be owned by a project
Status in OpenStack Identity (keystone):
New
Bug description:
Problem Description
===================
When configuring/creating credentials to enable machine to machine
integrations (e.g. backup systems, auditing tools, monitoring, and others),
the used credentials belong to the project where they are being applied;
therefore, it makes sense to enable operators to assign/create
credentials that are owned by a project, and not by a combination of
project and user.
Users should still be able to create credentials for themselves, and
their projects. The goal here is to enable the creation of credentials
for projects. Therefore, the current behavior is maintained. We can then,
restrict the API to create project credentials to super admins/operators.
People normally work around this issue by creating dummy users to hold
credentials, but that is not the best method to handle this situations.
Proposed Change
===============
The POST "/v3/credentials" API will allow the creation of credentials
with a project ID (without user ID).
To achieve that, we need to change the API schema validation for the
POST method to consider as mandatory either a project ID or a user ID.
This also means, we can still create credentials for a user ID and Project ID.
Moreover, we also need to change the database schema for the
`credential` table. Currently, the field `user_id` is not nullable in
the table. Therefore, we need to convert it to a nullable column.
Moreover, due to this change, we need to enforce via Python code that
the user enters at least project ID or user ID; otherwise, it would be
possible to create credentials that do not belong to any project or
user.
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1907810/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
