Analysis: Way forward for setting authorization rules
Description
In grooming 02.09.21 we were unable to decide if we thought #5016 was a reasonable step to achieve a simpler way of setting authorisation rules, or if we should just go for doing #26 straight away. Thus we need to do an analysis of what we believe to be the best way forward.
In scope
- Identify strengths and weaknesses with #5016 as a solution for this need
- Estimate the difference in scope size between #5016 and #26
Out of scope
Scope the details of #5016 and #26 further than what we need for estimates.
Constraints
None as of now
Ops requirements
Unlikely that either of these should have ops implications - the end result of both is the same XACML file.
Analysis
TBA
Conclusion
Short summary of the proposed solution.
Tasks
- [ ] Is this issue labeled with a correct area label?
- [ ] QA has been done
@lvbachmann I feel very strongly that we should not hide complexity and "bad" formats with UI, and in the process making it hard/impossible to edit files directly and locally in a text editor with good intellisense for those who prefer that.
Creating and maintaining a UI directly on top of XACML will also be real a pain.
@altinnadmin You were missed in our grooming session yesterday, as I knew you felt strongly this way. You will be included in the analysis here if you can prioritise the time for it.
Closing this issue - a policy editor is underway and will be implemented in Studio once it is in beta.