Request to add eduGAIN as IdP

[kushaldas]

Description

This is a request to add eduGAIN to the trusted IdP list. eduGAIN provides an interface to access over 70+ identity federations around the world. This will enable researchers and students from all those different institutes (over 4500 identity providers) to use sigstore.

• https://technical.edugain.org/status is the URL to see all federations under eduGAIN.

I volunteer myself to work as a bridge with the eduGAIN team.

[dlorenc]

Thank you for the details! Can you share the discovery URL?

Would there be any way to have an allow list of email domains that eduGAIN is allowed to issue certificates for? I assume they're all .edu, but is there any other type of list we could use?

[leifj]

eduGAIN (edugain.org) is a big federation - about 6000-10000 orgs - in research and education globally. Each org runs their own IdP. If we the project decides to go ahead with this edugain would deploy a gateway OP for sigstore. To answer your second question; edugain covers much more than the US so its not just .edu but it would be possible to include info about this in each claim.

[haydentherapper]

Assuming the identity is an email, we can either add this as an email OIDC issuer or under Dex.

Before adding any new IDPs, I'd like to make sure the new IDPs meet the requirements under #397.

[leifj]

The requirements look reasonable at first glance. Some questions/thoughts inline:

• As pointed out in the meeting, Dex allows us to restrict the lifetime of issued tokens. Lifetime isn't included in the hosted openid-configuration, so this may have to just be an audit and not enforced (beyond rejecting tokens that are over a certain lifetime, but at that point, the token's already been sent over the wire so it's not worth rejecting the requesting in my opinion).

I'm sure this is just a configuration issue for the OIDC2SAML gateway we would deploy.

• Also brought up in the meeting, we should require that IDPs prevent identity subject reuse.

This is of course tricky to absolutely guarantee given that we're talking about several thousands of organizations under multiple policies but I will say that during the 15+ years eduGAIN has been in operations we have had a single case of identity reuse which was dealt with within a couple of hours.

• Key rotation policy

Configuration requirement for the OIDC2SAML gateway - should be a no-brainer.

• Signing key storage policy

Is this requirement about specific ways keys must (or must not) be stored or about having a policy at all?

• Uptime requirements

Not a problem whatever those are.

• A hosted .well-known/openid-configuration (which should be a given for OIDC, but it's worth having this explicitly checked as part of onboarding a new IDP)

Another configuration requirements. Should be straight-forward.

• Minimum set of supported claims (issuer, subject, audience, issued at, expiration). I propose that we don't enforce that all tokens have precise claim name (iss, sub, aud, for some examples), but that these values are represented in some claim on the token. For example, the subject could be in sub or email or maybe some other claim.

I'm curious about the use of email actually. In eduGAIN the long term identifier is an email-like scoped identifier (sorta like a kerberos principal name) which looks like but may to actually be an email address. Typically email gets re-used a lot over time because people get assigned email addresses based on real names. Avoiding real-name duplication/reuse in an organization is pretty hard (impossible). So why insist on email?

• An OIDC provider must challenge the email address

Really? How often? Once or every few hours/days/weeks/months? Typical enterprise email assignment kinda makes it unnecessary to challenge the address since its the same directory/ad/goolge/o365/whatever that drives the email system as feeds identities to the IdP....

The use of email as an identifier seems strange at the scale we're talking about but its not really problematic for eduGAIN as such... just curious about the thinking behind the use of email as a primary identifier.

[haydentherapper]

Thanks for going through these! We're planning to formalize these, as they're a little rough and unclear at the moment.

I will say that during the 15+ years eduGAIN has been in operations we have had a single case of identity reuse which was dealt with within a couple of hours.

To confirm, the expectation is that identities cannot be reused, enforced by the backend? In this case, there was some bug?

Is this requirement about specific ways keys must (or must not) be stored or about having a policy at all?

To me, this is not a hard requirement on how keys are stored, just a policy and adequate protection. For example, using either a key management service like Vault or KMS, or having keys encrypted on disk and decrypted on start up using a managed key, would be ideal.

Uptime - Not a problem whatever those are.

We will define this! Probably 99.9.

I'm curious about the use of email actually. In eduGAIN the long term identifier is an email-like scoped identifier (sorta like a kerberos principal name) which looks like but may to actually be an email address. Typically email gets re-used a lot over time because people get assigned email addresses based on real names. Avoiding real-name duplication/reuse in an organization is pretty hard (impossible). So why insist on email?

Email isn't a hard requirement, we do have support for other types of identifiers (for example, a generic [username identifier](https://github.com/sigstore/fulcio/blob/main/docs/oidc.md#username or a URI). For most of our current OIDC providers, they use email. Each IDP doesn't support email reuse. However, like you alluded to, you can reuse an email across IDPs, there's no guarantee that the same person is behind each, so we are working on requiring that clients check both the identity and issuer in a verification policy.

Really? How often? Once or every few hours/days/weeks/months? Typical enterprise email assignment kinda makes it unnecessary to challenge the address since its the same directory/ad/goolge/o365/whatever that drives the email system as feeds identities to the IdP....

We were thinking just initially, on account set up.

[haydentherapper]

Hi all, is there any interest still in adding this? If so, feel free to submit a PR to update the configuration (this can be an email provider), otherwise I'll close out this issue.

[kushaldas]

Hi all, is there any interest still in adding this? If so, feel free to submit a PR to update the configuration (this can be an email provider), otherwise I'll close out this issue.

I will get back to this next week.

[haydentherapper]

Something to clarify, is eduGain a federated identity provider in that it issues tokens for various upstream providers? Will emails differ for identity tokens, or do all tokens have the same address (such as [email protected])?

Another question, would we expect that users are interacting with Sigstore clients or would signing occur through automation, such as service accounts, machine identities, etc? If the former, then no PR is needed, but the Sigstore-managed federated identity provider will need to be registered the identity provider to get a client secret.

[leifj]

edugain is an identity federation, not an email provider. IdPs connected to edugain provide a uniform set of security promises to relying parties. Email address is one of the attributes that can be released from an OP (assuming the user and home organization consents). Email addresses belong to the domain that owns the IdP so its not @edugain.com for anyone.

[haydentherapper]

Thanks for clarifying. Let's add eduGAIN then, that should unblock a lot of educational organizations.