Identity and access

Access to git.cnx.net.kh is federated through an identity provider. GitLab's login screen lists the providers available to you, and which ones you see depends on where you are in the onboarding process.

UAT and proof-of-concept access

During a UAT or proof-of-concept phase, CNX provisions a dedicated testing identity provider for your team (passkey-based, no passwords). Registration links go out to your nominated testers directly; this identity is scoped to the testing phase and isn't what your organization uses once you move to production.

Production access

For production, GitLab access is federated to an identity your organization already controls — either:

• your own IdP (SAML/OIDC), or
• CamDigiKey, Cambodia's public digital-identity provider, if your organization uses it.

Contact CNX during onboarding to choose which one applies to you; CNX binds the identity you choose to your GitLab group.

Maker/Checker roles

Once identity is set up, CNX assigns GitLab roles on your DNS product group to match your organization's change-control needs:

• Maker (GitLab Developer) — can push branches and open merge requests. Needs an SSH key registered at git.cnx.net.kh/-/user_settings/ssh_keys to push.
• Checker (GitLab Maintainer) — approves and merges merge requests through the web UI. Doesn't need an SSH key.

If your organization requires segregating who makes a change from who approves it, tell CNX during onboarding how many of each role you need — see Managing zone changes for what a Maker and a Checker each do in practice.