Problem: API lacks an authorization implementation

[jraddaoui]

Is your feature request related to a problem? Please describe.

Enduro's API has optional authentication using OpenID Connect (OIDC), but there is no mechanism in place to control access to resources based on user roles or permissions.

Describe the solution you'd like

I looked at different options to provide this functionally:

• Access Control Lists (ACLs)
• Role-Based Access Control (RBAC)
• Attribute-Based Access Control (ABAC)
• Policy-Based Access Control (PBAC)

ACLs allows granular control over each resource, but it has scalability issues as the application grows. Like RBAC, they won't provide a flexible and fine-grained access control that will allow us to manage complex access needs dynamically as the application grows.

Both ABAC and PBAC grant or deny access based on attributes like user roles, resource types, operations, etc., evaluating them through defined policies. This attributes can have a hierarchical organization, policy inheritance and delegated administration (as the system and organization evolves). While PBAC provides comprehensive policy management, it can be implemented following ABAC when more defined policies and integration with external decision points are needed.

As an initial implementation or PoC, I'd like to see how Enduro is capable of getting a list of attributes from a configurable claim in the OIDC access token and limit user actions based on them. For example, considering the following actions (API-endpoints/UI-views):

• List packages
• Read package
• Download package

And the following attributes:

• package:*
• package:list
• package:read
• package:download

"configurable_claim": [ "package:*" ]

Should be able to perform all actions.

"configurable_claim": [ "package:list", "package:read" ]

Should only be able to list and read packages, but not download them.

Describe alternatives you've considered

Mentioned above.

Additional context

• Similar to the API authentication, we should try to make it optional and configurable.
• Actions and attributes above are just an example for an initial implementation.
• Should we consider attribute negation (not:package:download, !package:download, package:!download)?

[aseles13]

This is a good incremental approach to validating and building out our identity management capabilities in Enduro.

[fiver-watson]

@jraddaoui I believe this is the issue related to our discussion about adding a prototype landing page so we can test users w no permissions. If that's correct, below is a super simple, rough first pass:

I thought it could be nice to show the username in the welcome header text, but we can also skip that if it adds too much complexity. Otherwise, it's just a basic project description and a link or two.

[jraddaoui]

Initial implementation:

Some notes @fiver-watson:

• I used the home icon from https://icon-sets.iconify.design/clarity/ (line version) for consistency.
• I left the same content width from other pages, with it centered.
• I didn't add the @ in front of the user name. Depending on the claims obtained by the OIDC provider the user name could read "Jane Doe", so I think it's better without it.
• I added an element in the sidebar to indicate it's the current page and have an obvious link for it. The heading logo also works as a link to the home page, but it's not so obvious.

Let me know your initial thoughts.

[sallain]

As discussed, we don't currently have the infrastructure to test this locally. I can see the lovely new landing page 🎉 For our purposes, I'm going to move this to done; we can reopen if necessary once the client has had a chance to configure and test.