Fine-grained per-project users/ACLs

[GuillaumeAmat]

Hi there, and thanks for that great project!

I'm looking for the roadmap but can't find it yet. Is it available to the public?

Right now, I specifically would like to know if a stronger authentication mechanism and privacy policy are planed or not (eg: user management, access control).

[patrickhulce]

There is no roadmap outside of what's contained here in GitHub issues with respective priority, though existence of an issue is not a guarantee it will be implemented.

No one is actively working on more advanced user management and access control, nor are there any concrete plans for what that would look like. Would you mind describing your use cases for what different tiers you're interested in?

Given that the server is mostly a viewing portal meant to be shared across an entire team, the most common requests for security have been covered by the two existing tiers.

Would you mind explaining what you mean by privacy policy? You can follow #386 for an update on the GitHub app privacy policy but the server itself is operated by you, so I'm not sure how a privacy policy applies there.

[GuillaumeAmat]

Would you mind explaining what you mean by privacy policy?

I create web projects for several customers and I would need to ensure them the confidentiality of the hosted data (eg: metrics, trends).

Right now, the only solution is to host several LH servers, one for each customer, which does not scale, generates work and increases the budget of the my infrastructure.

To be clear, I'm not building a SaaS out fo LH, I just would like to be able to share some of the projects metrics to my customers ;)

Thanks for your feedback

[patrickhulce]

Ah so not really a service privacy policy (that would be mostly up to you as the operator of the service and data steward for your clients) but functionality for siloing different projects in LHCI?

This isn't something we're planning on baking in to Lighthouse CI anytime soon. Though some more detail on your ideal user access model would be very welcome :) i.e. what levels of access do you need to prevent other people from having, what roles are there, what is per-project and what is global, etc

[patrickhulce]

As a thought for your workaround, I would personally setup a proxy in front of LHCI that routes to multiple instances based on the domain each locked down with basicAuth that LHCI clients already support. Multiple instances running with separate SQLite DBs would be relatively lightweight and could all run on the same instance

[somehowchris]

Hey, I'm fairly new to lighthouse ci though I have been using lighthouse inside chrome.

I didn't try this but it seems fairly simple to inject a a middleware as there is a createApp which seems to be the one to actually create the routes and middleware.

Now I don't like the hacky way of doing things in such projects but I also see the point and have the need to actually controll who can view what. Now I don't have nor see the need to actually have the management integrated into the lighthouse ci but rather the checks if someone can look at the page because most of us have some kind of AD, oidc or what ever system supplies access roles and other properties.

If you don't mind heres a proposal which consists out of 3 parts:

• Just like the basicAuth offer an oidc login to have per use logins
• Inside the options object of createServer have a property called i.e. access inside which all types of endpoints have different callbacks to check if someone can actually do the action. Just like any other express middleware.

  {
  access: {
    projects: {
        canView(req, res, next){},
        canDelete(req, res, next){}
        canCreate(req, res, next){},
        ...
    }
  }
  }

  Now for me it doesn't make sense to do one per endpoint but grouping them by types of actions. This structure leaves it open if there is going to be something standalone other than besides projects.

• Have a access denied page in the frontend.

In my opinion this would integrate well with oidc providers and give a pluggable way of handling access since this could not only be used for oidc rbac but also if other types of access management. You could actually develop a plugin with this setup.

A thing to note. This currently doesn't solve the problem of having an /projects api endpoint which lists all projects.

I would love to have your feedback. I'm not the best react/preact dev since I'm more into the data but I can help where ever needed.

[LukeLeber]

Having recently opened https://github.com/GoogleChrome/lighthouse-ci/issues/494 -- which seems to be a duplicate, more or less -- I'd just like to point out some key points that enterprise consumers can greatly benefit from:

• A way to delegate end-user authentication to a central entity: This can be a significant security enhancement, as no usernames or passwords are stored in the node application, and access tokens can be restricted to machine users.
• A way to delegate user-management to a central entity: This can really streamline processes for large organizations that see folks come and go quite frequently. Certain user management tools, such as MS Azure, can potentially take ownership of ACL if the right infrastructure is set up (https://github.com/GoogleChrome/lighthouse-ci/issues/391#issuecomment-668652332).

Is there any sort of delineation between the parts of the API that are typically end-user accessible and the parts that are typically accessed by a CI agent?

I have to say we're really impressed by this tool!

[patrickhulce]

Thanks @LukeLeber! Two followup questions:

• Do you have any insight to share into how that works with the uploading portion of server functionality? For example, is it easy to create service accounts and have those credentials available to the CLI through just an extra header?
• Does the proposal in https://github.com/GoogleChrome/lighthouse-ci/issues/391#issuecomment-723672281 of getting raw access to the request object based on canView/canDelete/canCreate satisfy your needs?

[LukeLeber]

@patrickhulce

• Unfortunately, I don't have any insight into how this change would work, functionally. I haven't had time to take a deep dive into the project source yet.
• I do believe that the canView/canDelete/canCreate can work.

As I share this out with our internal teams, I can try to get some more eyes on this topic.

[patrickhulce]

Unfortunately, I don't have any insight into how this change would work, functionally. I haven't had time to take a deep dive into the project source yet.

Sorry I'll rephrase :) My question isn't really specific to this project.

In general, when you have a service using SSO interally, is it common (or even possible?) for automated processes to access that service as well? If yes, is the mechanism simple enough to be solved by just adding a header to the requests?

[somehowchris]

@patrickhulce In most companies Service Accounts can work through the sso or get an access token from the sso. We currently have this split as SAs are usually m2m (exclude testing) so we have we have a sso for all the natural users and a secure oauth m2m api. I don't know your use case @LukeLeber but I haven't seen an sso without some kind of oidc/oauth2 or SAML capability

[LukeLeber]

I'd have to assume that the big names in SSO all support the concept of a Service Account. I know for a fact that MS Azure does. Adding a header that can be used to split mechanisms should be able to work unless I'm missing something obvious.

[somehowchris]

Hey @patrickhulce

As I had a bit time the last week I took this issue for a spin again. I came across a better idea but again with some constraints.

Instead of canView/canDelete/... a single fetchPermissions method which returns an array of projects (as they are the root) with some properties

[
    {
        "projectId": "xyz",
        "actions": ["read", "write", "delete"]
    }
]

This reduces the repeated js code in the server config as the logic is written in a single function. Scenarios:

• Using active directory: groups and users can be mapped into permissions and projects can be mapped as objects
• Using sso (oidc/etc.): Depending on the token permissions can be mapped

If permission management shouldn't be part of lhci then a backend can be created to the needs of tracking permissions between users/groups and projects. Should it be done as part of lhci or not?

small edit: I can see a problem with lhci caching usernames and groups as there is the (small) chance of users having the same username after one deleted his account and another logged in as lhci wouldn't be given the update that a user has been deleted. As I know most of the providers assign a definitely unique id to a user but this could be one of the pitfalls

---

This would handle authorization. For authentication, I see 2 possibilities. either move a bit of code from the createBasicAuthMiddleware function into the config or define the possible methods of authentication inside lhci.

working at a company where default settings are usually forbidden I see the chore of making something like oidc working with a predefined oauth2 setup.

---

Again I'm not much of a react guy but I couldn't find a page to handle HTTP codes 401 or 403, is this right?

If authentication is customizable is there a way of configuring a custom component for authentication, adding users, removing users,... inside the server configuration which is provided?

---

As of the cli I imagine having a fetchToken function to identify a given script and add it as a header but that does not really add any security in my knowledge as there is already the build token.

[patrickhulce]

Thanks @somehowchris! I think that approach moves the responsibility of mapping actions/objects back onto LHCI. The most likely way I see this resourced and implemented is something closer to your first approach where hooks are exposed before view/create/delete actions that can be stopped. The repetition issue can be solved in userland with shared logic if necessary and it greatly simplifies the burden on LHCI hook exposure. How does that sound?

Loosely related #438

[somehowchris]

Ok. #438 is about the client side right? I see the problem if I get all the projects. With the first approach I would need to fetch all the projects (or at least all the ids) and then check for each project as the second approach would list all the projects by their ids already

[axe312ger]

I have the same problem, having multiple customers and want to share regular performance repots with them. Giving them access to all the reports of a single server would expose information of other customers.

If we could generate a public URL per page/project, that surpasses the http-auth, would already help a lot.

Like this:

http://lhicerver.com/app/projects/my-project/dashboard?auth=bb316de022231e1b2b9eb2bbd25fb409

If we allow the build token to be used as auth token, that might need only a additions to the code.

WDYT?