yahoo-eng-team team mailing list archive

[Rafael Weingartner <1907810@xxxxxxxxxxxxxxxxxx>]

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