Discuss a central identity access management service for projects

At the Adoptium project we are constantly evaluating our secure engineering practices and looking for ways to improve. An area of interest is identity access management, and ensuring that we have the confidence that contributors to Adoptium are known and trusted at an appropriate level within the project.

Clearly, we have an open community and welcome contributions from anyone. Contributions include discussions and ideas on Slack/e-mail, documentation, code contributions, and eventually committer and limited administration/PMC privileges. At Adoptium each 'level' of contribution comes with expectations of trust in the individual contributor in addition to technical ability. We apply a different level of trust to contributors of a simple Slack message that we do to someone contributing infrastructure changes.

In line with Eclipse Foundation policy we use the ECA validation bot for GitHub PR contributions. It is my understanding, however, that the ECA does not involve a natural person check. Is it possible for a fictitious actor to create an Eclipse account, submit an ECA and claim an associated GitHub id without any background checks performed? That is, as an online community we do not actually know if a contribution comes from a traceable natural person.

Following on from that, we have various points in the project where we handle identity information for more advanced contributors. For example, granting rights to review code contributions, run builds, and eventually even push builds to our public repositories and administer our infrastructure. At these additional levels of trust we aim to know well the individual and their associated online identities. The administration of these rights is spread across various systems, such as GitHub, a PKI system, and direct password management.

To date we have been able to meet in person those with extended trust and rights in the project, and there have been no problems or concerns with establishing identity or trusting their online accounts and secrets management hygiene. We follow the 2FA requirement in GitHub, and watch for any unusual behavior in our system logs. Everyone with enhanced rights at the project has been given a FIPS-compliant hardware authentication token (Yubikey) to be used on systems that support it.

It would seem desirable to have a strong identity access management service at the Eclipse Foundation that goes beyond the current ECA check. Having a trusted system that validates identity, preferably at different trust levels, and manages access rights would be very useful to incorporate into the Adoptium project in place of the multiple systems and locations we have today. Rather than do that at an individual project level, it seems appropriate that this is a broader service managed at the foundation level and integrated with the Eclipse account system. This issue is intended to discuss the concept rather than the actual implementation.

/cc: @mrybczyn , @netomi , @mbarbero

It is correct that somebody could forge commits that could impersonate another person that for example has signed an ECA and would thus be eligible to be merged with the current settings.

Something that we try to educate (so far only within our own team, but that should include all Eclipse committers at some point in time) is to enable signed commits for your personal account and enable vigilant mode in GitHub such that unsigned commits are indicated e.g. in PRs.

There is even the option to enforce signed commits in PRs but that might be counter productive, at least we dont have any data points in doing that.

I understand the scope of this ticket goes even further than that, but wanted to give some comments about what is technically possible with GitHub atm.

There would be a need to associate an identity (e.g. gpg) to an Eclipse user / email but I let others chime in on this topic.

Thanks for sharing your ideas @netomi .

As you mention there are mechanisms in GitHub to help alert to certain types of identity fraud based upon their own identity management, and I know Eclipse are structuring some contributors' organisation and rights using GitHub teams (e.g. *-contributors, *-committers, *-project-leads, etc). While it is possible to use GitHub as the OAUTH authority, I question the suitability of using GitHub as a full IAM service, since projects likely depend upon many other third-party systems outside GitHub for critical services.

At the moment the ECA check is a simple callback into the EF service to verify one particular role. The thought is whether to expand the EF service with the ability to verify more sophisticated identity and access management queries - which likely would be best accomplished by using a dedicated central service (e.g. there are many implementations of OpenID Connect services).

added team:security label

added User account label

I have concerns about what kind of information we'd need to collect(and store) as well as what processes/time would be needed to effectively implement something like this.

Hi @mward , at least in the first instance, no more than currently being used to allocate roles to people involved in the project.

I presume that each project has its own way of verifying contributors who gain merit, responsibilities, and privileges in the project. At Adoptium we take much more care about who can release a binary than we do who can open a PR to be reviewed.

The IAM service I am discussing would record decisions about trust and rights made by the project, how they are determined is orthogonal. That is, having a central service is not the same as having a central certification authority.

Today, opening a PR with a code contribution is limited to an ECA check (which, AIUI, is simply a check somebody has an e-mail account and has made a self-declaration). In future it may well be that we expect stronger verification for more impactful roles.

added GDPR label

marked this issue as related to #4639 (closed)

@tellison we have had a discussion in the security team about this and we have multiple things to investigate. I think that @mbarbero plans to come with an answer

Thanks Marta. It is not urgent, just looking to have a discussion about a considered way forward before planning something locally within the project. This is a longer-term goal.

Thank you, @tellison, for opening this issue.

First, a story :) I recently verified my identity on LinkedIn, using the Persona service (for US/Canada/Mexico, this would be via CLEAR). The verification must be done on the LinkedIn mobile app; it cannot be completed on a browser or laptop. Persona received all the sensitive data and issued an attestation to LinkedIn with minimal information: name, type of ID document, issuer, and a set of IDs (for the request and the verification process). LinkedIn can then use this to attest that the name on the profile matches the name on the government ID. I must say that the user experience was surprisingly good.

Now, I don't think the Eclipse Foundation should become an identity verification platform. However, I can see some benefits of using similar identity verification companies and being able to attest that the name on an Eclipse Foundation account profile matches a government-issued ID. Some projects, like Adoptium, could configure the ECA app or similar checks to ensure that contributions come only from "verified" contributors. However, while this might deter some persistent threat actors (PTAs) from executing attacks similar to the recent XZ-one, a motivated PTA could certainly fake this verification. As far as I know, there is no data or proof of the efficiency of such a measure.

Finally, there is the question of acceptance. Would the Eclipse Foundation community be okay with having this capability? Would it exclude contributors whose countries of origin are not supported by the identity verification platform? What is their policy on PII retention? How trustworthy are these third-party identity verification companies? In which jurisdictions do they operate?

@wbeaton, any comments?

@mbarbero you've captured my concerns.

This would represent a very high bar for participation and so is not something that I feel is broadly appropriate. That is, I believe that this is completely reasonable (and consistent with the EDP) for a very small set of projects. I could reasonably argue that Eclipse Adoptium subprojects belong in that set.

Thank you for your considered reply @mbarbero, and the example from LinkedIn of what I would consider an 'extreme' level of external identify verification. As you point out, LinkedIn allows basic verification by creating a new account with a new email address, or the process you followed that cross-checks with other agencies. It illustrates that every enterprise can manage attributes and define various levels of identity proofing that works for them.

Of course, Eclipse already maintains a form of identity management through the Eclipse account system. I think the bar for creating an account is rightly low (and to be clear I'm not proposing that it becomes extreme!). Furthermore, at the project level we have (to my understanding) a very limited ability to interact with the Eclipse account system (including the ECA check, GitHub id check) through system integrations.

If the Eclipse account management is based on a system we can extend that would be ideal. AIUI there is no way to associate project-level attributes or access controls to the Eclipse account, or link products used by the project that use standardised protocols. The closest to this I can provide is that the EMO trust that individuals voted to have more power are well-known to the project, and the account is added to a GitHub team to grant rights.

That leads to each project using our own informal identity verification process that is not represented anywhere. There is no centralised capture of attributes as used by most enterprises, or distributed web of trust used by many communities.

In Adoptium at the moment we have some shared accounts whose secrets are known to multiple people, and we have an ad hoc process for determining that people and devices are well-known enough to gain access to sensitive resources - the results of which are institutional knowledge rather than recorded in an auditable location. We have some central management of public keys, and we rely on trust that people manage their accounts correctly.

I'm sure that many projects will be quite happy with the current basic user identity management, and don't need additional capabilities. That's fine. Please don't require that they do any more than they do today. Some projects would benefit from being able to manage users and identity, integrate access control, authentication policies, and audit the changes. That's fine too, but currently there is no way to enable them. As you know, the NIS2 directive strongly emphasises robust access controls and user authentication so I expect we'll be moving in that direction anyway.

I'm happy to investigate some of the available IAM systems for our project use. Just wanted to have the discussion at the Foundation level since it seems it overlaps with the current account management system.

I'm happy to investigate some of the available IAM systems for our project use. Just wanted to have the discussion at the Foundation level since it seems it overlaps with the current account management system.

FYI, the team is currently working hard to switch our current IAM solution to Keycloak. It should provide more opportunities for external integration.

mentioned in issue #4909