Uploaded image for project: 'Red Hat 3scale API Management'
  1. Red Hat 3scale API Management
  2. THREESCALE-8280

Ability to create tokens associated to a specific Product and not bound to any single user

XMLWordPrintable

    • Icon: Feature Request Feature Request
    • Resolution: Can't Do
    • Icon: Major Major
    • None
    • SaaS, 2.11.2 GA
    • System
    • False
    • None
    • False
    • Not Started
    • Not Started
    • Not Started
    • Not Started
    • Not Started
    • Not Started

      Use case:
      The customer has a CI/CD pipeline that uses the 3scale toolbox/3scale APIs which currently uses Personal Access Tokens that are bound to a given user but the token is used by a process which they don't want to be coupled to a user through this dependency our current architecture dictates.

      Request:
      The request is to have the ability to create tokens associated to a specific Product and not bound to any single user.

      Used workaround:
      The customer creates a "technical user" per product with a fictive (non existing) email address (product-system-name@company.com), grant permissions to manage only this product and activate it. (This is implemented with the 3scale integration api)

      Afterwards the "technical user" logs in to the Admin Portal with it's credentials, deactivate all notification subscriptions and create an access token with read & write for the scope account management API. (This must be done manually because of the lack of functionality in the 3scale integration api)

      The access token created is then sent to the developer and then used it in the product publication ci/cd pipeline.

      Other possible workaround:
      Create the user with a mailing list such as 3scale-toolbox@example.com which the admins responsible for maintaining that integration are subscribed to and securely store locally the logging credentials for that account. This way the risk of breaking the pipeline is mitigated until this RFE is implemented. While the approach to have 1 single "technical user" which must have permissions assigned to all products is less secure.

            Unassigned Unassigned
            rhn-support-avilatus Anna Vila Tusell
            Votes:
            3 Vote for this issue
            Watchers:
            12 Start watching this issue

              Created:
              Updated:
              Resolved: