Permissions Lifecycle Management for Console and other clients

[mb365247]

Problem Statement

Managing the permissions life cycle for applications and services onboarded to Keycloak can be tedious and involve a lot of back-and-forth human to human integration. This introduces a margin of error, delays, and inefficiencies in setting up and managing permissions.

How might we simplify the permissions lifecycle management of a Platform application or service onboarded to Keycloak?

Hypothesis or Bet

By simplifying and centralizing permissions lifecycle management per application, we hypothesize we can reduce the time Platform teams need to spend integrating with AMT.

We will know we're done when... ("Definition of Done")

What requirements does this project need to meet for you to finish this initiative?

Known Blockers/Dependencies

N/A

Projected Launch Date

End of Q2

Launch Checklist

Is this service / tool / feature...

... tested?

• [ ] Usability test (TODO: link) has been performed, to validate that new changes enable users to do what was intended and that these changes don't worsen quality elsewhere. If usability test isn't relevant for this change, document the reason for skipping it.
  • [ ] ... and issues discovered in usability testing have been addressed.
  • Note on skipping: metrics that show the impact of before/after can be a substitute for usability testing.
• [ ] End-to-end manual QA or UAT is complete, to validate there are no high-severity issues before launching
• [ ] (if applicable) New functionality has thorough, automated tests running in CI/CD

... documented?

• [ ] New documentation is written pursuant to our documentation style guide
• [ ] Product is included in the List of VSP Products
  • List the existing product that this initiative fits within, or add a new product to this list.
• [ ] Internal-facing: there's a Product Outline
• [ ] External-facing: a User Guide on Platform Website exists for this product/feature tool
• [ ] (if applicable) Post to #vsp-service-design for external communication about this change (e.g. customer-facing meetings)

... measurable

• [ ] (if applicable) This change has clearly-defined success metrics, with instrumentation of those analytics where possible, or a reason documented for skipping it.
  • For help, see: Analytics team
• [ ] This change has an accompanying VSP Initiative Release Plan.

When you're ready to launch...

• [ ] Conduct a [go/no-go] (https://vfs.atlassian.net/wiki/spaces/AP/pages/1670938648/Platform+Crew+Office+Hours#Go%2FNo-Go) when you're almost ready to launch.

Required Artifacts

Documentation

• PRODUCT_NAME: directory name used for your product documentation
• Product Outline: link to Product Outline
• User Guide: link to User Guide

Testing

• Usability test: link to GitHub issue, or provide reason for skipping
• Manual QA: link to GitHub issue or documented results
• Automated tests: link to tests, or "N/A"

Measurement

• Success metrics: link to where success metrics are measured, or where they're defined (Product Outline is OK), or provide reason for skipping
• Release plan: link to Release Plan ticket

[annekerr49]

@kjduensing - Can we get a status update on this item?

[annekerr49]

@kjduensing - Kevin we are trying to increase the information available to those persons who monitor this board. To that end we are asking that open items updated monthly as to any changes. For our interested colleagues. Please let me know if you have any questions.

[annekerr49]

@mb365247 @kjduensing - Kevin we are trying to increase the information available to those persons who monitor this board. To that end we are asking that open items updated monthly as to any changes. For our interested colleagues. Please let me know if you have any questions.

[annekerr49]

@raywangoctova @kjduensing @FHiatt @mb365247 - Platform Crew is having a DE Product Board meeting and I would like to be able to give a status update on the progress the team is making on this item. Can you help? If not can you direct me to someone who can assist?