feat(keycloak): onboard Apply7 as an OIDC identity provider

[shaidar]

What are the relevant tickets?

N/A

Description (What does it do?)

Onboards Apply7 (apply7.ai) as a new OIDC identity provider on the olapps (MIT Learn) Keycloak realm, using the existing onboard_oidc_org/OIDCIdpConfig/OrgConfig helpers in org_sso_helpers.py.

• IdP alias: APPLY7, client ID: mit-learn
• Metadata URL: https://keycloak.apply7.cn/realms/mit-learn/.well-known/openid-configuration
• org_domains is intentionally empty — like upGrad and Masai School, Apply7 users authenticate via a direct kc_idp_hint link rather than domain-based home-realm discovery, so no email domain is needed to gate access.
• No client_secret configured (same pattern as several other partners, e.g. DUTH).

Screenshots (if appropriate):

N/A — backend Keycloak config only.

How can this be tested?

• ruff format, ruff check, and mypy all pass via pre-commit.
• After merge/apply, verify in the Keycloak admin console that the APPLY7 identity provider appears under the olapps realm and that a kc_idp_hint=apply7 login link successfully redirects to https://keycloak.apply7.cn/realms/mit-learn/... and completes the OIDC flow with a test account.

Additional Context

Apply7 also asked whether MIT can provide "the public certificate for certificate-based authentication." That doesn't map to anything in this OIDC flow as configured — Keycloak validates Apply7's signature via the JWKS published at their own metadata URL, so there's no MIT-side certificate to hand over unless they actually intend mutual TLS or private_key_jwt client auth (the pattern already used for Masai School). Worth clarifying with their team before end-to-end testing.

[sentry]

Bug: The Apply7 OIDC provider configuration lacks a client_secret, which can lead to a silent failure during pulumi up if the IdP doesn't support private_key_jwt or is unreachable.
_{Severity: HIGH}

Suggested Fix

Verify with the Apply7 team whether their Keycloak instance supports private_key_jwt authentication. If it does not, a client_secret must be obtained and added to the OIDCIdpConfig for Apply7. If it does, ensure the metadata URL is consistently accessible. Consider adding an explicit failure (e.g., raising an exception) instead of a silent return with a warning log to make this failure mode more visible during deployment.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location: src/ol_infrastructure/substructure/keycloak/olapps.py#L1490-L1511

Potential issue: The new OIDC configuration for Apply7 in `olapps.py` omits the
`client_secret`. When `client_secret` is `None`, the
`oidc_identity_provider_args_from_discovery_url` function requires the identity
provider's metadata to advertise `private_key_jwt` support. If Apply7's Keycloak
instance does not support this (which is the default for Keycloak) or if its metadata
URL is inaccessible, the function returns `None`. This causes the `onboard_oidc_org`
function to log a warning and exit prematurely. The `pulumi up` process will report
success, but the identity provider will not be created, preventing Apply7 users from
authenticating. The PR description notes this configuration is currently unverified.

_{Did we get this right? 👍 / 👎 to inform future reviews.}

[Copilot]

Pull request overview

Adds Apply7 as a production OIDC provider for the MIT Learn Keycloak realm.

Changes:

• Configures the Apply7 OIDC provider and organization.
• Enables direct kc_idp_hint=apply7 login without domain discovery.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[blarghmatey]

Don't we also need to add some attribute mappers for them to do attribution of schools, etc.?