Alternative auth design for self-hosted shields

[coopernetes]

Hi all! 👋
First off, thank you for the shields project! Our company uses shields internally as a self-hosted instance due to operating in an air-gapped environment and it's extremely helpful to build our badges for our internal CI and related services. That said, I have a predicament that I'd like to bring up to the community here.

One challenge we have is most of our systems that we are looking to generate badges for require authentication. Normally, this isn't a problem for shields since there is the concept of server secrets and the associated auth helper. However, we don't have any mechanism of handling multiple sets of credentials or tokens for a single type of badge. For example, I run many internal Maven repositories that are all privately secured. Alternatives are running individual shields instances per team/customer/"tenant", which isn't ideal. My intention is to run a single set of shields instances that can handle badges for all our internal development teams and thought it would be useful to have some sort of "auth delegation" to self-hosted shields.

My original idea was to extend the existing server secret model and allow selectable credentials to be used. Putting aside the authorization question of who is allowed to use a credential if it were made to be a drop-down, this made me think that maybe a better model would be to build in support for something like OIDC or SAML so that an individual user's access can be reused by shields and we could use a standard auth code OAuth flow. Of course, the systems I'm dealing with do not all support the newer authentication methods so I'm stuck with manual auth via LDAP, username+password, API tokens, etc.

This is my long-winded way of asking - Is this a useful enough feature for anyone else to use upstream or is there better alternative solutions we can use with the existing project? What my idea may look like:

public:
  services:
      jenkins:
        authorizedOrigins: ...

# Retain global server secret config, act as default/fallback?
private:
  github: ... 
  jenkins: ...

  # Expose authDelegate=<id> as query param in badge generation
  delegates:
    <my-private-endpoints>:
      github: ...
    <other-private-endpoint>:
      github: ...
      jenkins: ... # If authDelegate=other-private-endpoint, use this token instead of private.jenkins

Alternatives considered:

• running multiple instances with their own unique server secrets. Doable but we now have to host shields in multiple places with only minor config differences (server secrets in this case)
• relaxing our access control to allow read-only access on a single set of secrets; we're a bit too security paranoid and I don't think this is suitable for all teams.
• Allow tokens to be specified as query params for specific badges. This is obviously insecure and only really suitable in places where the hosting document (README) is behind its own private auth (ie. a private GitHub repo)

Just wondering if anyone else has experience in this area and can sanity check. I'm leaning towards either allowing tokens to be specified by users (bad), have a shields self-hosted instance accept multiple credential sets (better but still insecure because anyone can request to use another group's creds) or requiring our devs to run their own instance with their own server secrets (not ideal but minimal/no code changes needed to shields to support this)

[calebcartwright]

Thanks for reaching out, and for the kind words! There's a lot to process here but fundamentally I think you have two questions/suggestions.

The first was this (in the context of OIDC/SAML) 👇

This is my long-winded way of asking - Is this a useful enough feature for anyone else to use upstream or is there better alternative solutions we can use with the existing project?

and I think the shortest answer is "no".

Shields is an open source project maintained by an increasingly small number of volunteers in their spare time. Our efforts, along with the codebase, are primarily centered around the deployment/hosting of the free Shields.io service that's used extensively across the global developer ecosystem.

We do of course strive to make it feasible, and hopefully straightforward, for folks to host their own badge server, but we've historically rejected requests that were only relevant in self-hosted contexts/had no utility (and often associated complexity) in the core shields.io context.

In my view that posture is directly applicable here. While I understand the contexts and constraints you are working with, it does feel like a more niche self-hosting scenario, and it's most definitely not applicable to the shields.io context. As such I can't see how this would make sense for us to take on.

Your other suggestion of allowing multiple credential sets to be specified is a potentially viable approach, certainly more than the other. 👇

However, we don't have any mechanism of handling multiple sets of credentials or tokens for a single type of badge

This is actually one we've discussed in the past, especially in the context of badges/services where a list of allowedOrigins has to be provided. We'd pictured a world where the server config would essentially allow for specifying origin(s)+auth pairs so that everything would be handled via config and the badge server itself; users wouldn't have to worry about anything in their badge urls.

[coopernetes]

Hey @calebcartwright thanks for the response! Your first point makes a great deal of sense. If a full-blown OAuth flow is something we need for our org, I'll keep that internal for now. I agree that it's overkill and outside the scope of the badges project. I doubt it's something we'll pursue.

We'd pictured a world where the server config would essentially allow for specifying origin(s)+auth pairs so that everything would be handled via config and the badge server itself; users wouldn't have to worry about anything in their badge urls.

This is something I think would suffice for our use. If there's appetite for multiple origin + auth pairs, I'd love to take a stab at this and contribute back if others may get some use out of this functionality. Do you have any thoughts on how this may work in practice? I tried searching for previous issues but turned up nil so apologize if I'm retreading old ground here.

[chris48s]

One set of credentials per authorizedOrigin does sound like the best approach IMO 👍

---

One other thing to consider:

Allow tokens to be specified as query params for specific badges. This is obviously insecure and only really suitable in places where the hosting document (README) is behind its own private auth (ie. a private GitHub repo)

We have a number of services like CircleCI, CodeCov, POEditor, Localizely, etc where the user can generate a token with read-only access to some subset of data within the service and then supply the token via a query param. This works well as long as it is possible to generate a sufficiently narrowly scoped token that it can be exposed via the URL to anyone who can view the badge without exposing any sensitive data or allowing write access to any resource. i.e: as long as the only data you can view by calling the API with the exposed token is stats you are trying to make viewable by showing it on a badge anyway, there's not really a security issue. I don't know maven well enough to know if there is a set of permissions you can give a token which is narrow enough for that to work for this service though.