SOP — Subscribe to and Manage GitLab

Goal: stand up GitLab for MPT Work so that everyone with an @mptwork.com identity signs in through the company IdP, is provisioned/deprovisioned automatically, and is governed as an Enterprise User under the organization's control.

0. Choose deployment and tier

Deployment (chosen at contract signing — it can't be changed mid-term):

Tier (per user, annual billing only):

GitLab Duo AI credits are bundled into Premium/Ultimate; Duo Pro/Enterprise are separate add-ons. For enterprise users with SSO, automated provisioning, and compliance, choose Premium at minimum, Ultimate where security/compliance scanning and full Enterprise User management matter.

Part 1 — Subscribe and create the organization

1. Sign in/create an account at https://gitlab.com (an admin identity; you'll federate users later).
2. Create the top-level group that represents the company: mptwork (gitlab.com/mptwork). This namespace is the anchor for SSO, SCIM, billing, and Enterprise Users.
3. Purchase seats: Group → Settings → Billing → buy Premium or Ultimate for the seat count (annual). Apply the subscription to the mptwork group.
4. Add initial Owners of the mptwork group (keep Owners minimal).

Part 2 — Verify the mptwork.com domain

1. In the mptwork group → Settings → Domain Verification → Add domain → mptwork.com.
2. Click Verify. A verified domain is the prerequisite for Enterprise Users (Part 5).

Add the TXT record GitLab provides at your DNS host:

Part 3 — Configure SAML SSO (Microsoft Entra)

1. In the mptwork group → Settings → SAML SSO. GitLab shows the Assertion consumer service URL (callback) and Identifier (entity ID) for this group.
2. In Entra → Enterprise applications → New application → add the GitLab gallery app. Open Single sign-on → SAML:
   • Set Identifier and Reply URL (ACS) to the values GitLab provided.
   • Map the NameID to the user's email/UPN, and add the email claim.
   • Download the certificate and copy the Login URL.
3. Back in GitLab SAML SSO, enter the Identity provider SSO URL and the certificate fingerprint/certificate from Entra.
4. Set member options: Enforce SSO-only authentication for web and Enforce SSO-only membership so mptwork access requires Entra sign-in.
5. Test the SSO sign-in from a non-admin @mptwork.com account before enforcing.

Part 4 — Automated provisioning with SCIM

1. In the mptwork group → Settings → SAML SSO → generate the SCIM token and copy the SCIM API endpoint URL.
2. In the Entra GitLab enterprise app → Provisioning → set mode to Automatic → enter the SCIM endpoint (Tenant URL) and token (Secret Token).
3. Configure attribute mappings (email, name, externalId) and assign the user/group (e.g., Staff-GitLab) to the app.
4. Start provisioning. New members are created in mptwork automatically; removing a user from the app (or disabling them in Entra) deprovisions their GitLab access — the backbone of joiner/mover/leaver.

Part 5 — Enterprise Users

1. With the verified mptwork.com domain and SAML configured, users whose email matches @mptwork.com become Enterprise Users of the mptwork group (paid tier required; Ultimate for full controls — confirm current tier requirement).
2. As Enterprise Users, the organization controls their account: enforce SSO, manage/disable separate password sign-in, control the account's primary email, and prevent them from removing themselves from organizational governance.
3. Communicate to staff that their GitLab access is now a company-managed identity tied to @mptwork.com.

Part 6 — Structure: groups, projects, and roles

1. Subgroups under mptwork model teams/departments (e.g., mptwork/platform, mptwork/web, mptwork/security); projects hold repositories.
2. Use groups for access (assign teams to subgroups) rather than per-project user adds, so SCIM-driven membership flows cleanly.

Assign roles at the group/project level (inherited downward):

Part 7 — Access control and security baseline

1. Enforce 2FA for the group (in addition to IdP MFA) where required.
2. Protected branches and merge-request approval rules (Premium): require approvals and block direct pushes to main.
3. Push rules / code owners: require Code Owner approval for sensitive paths.
4. IP allowlists and audit events (Premium) for restricted access and traceability; export audit events to your SIEM.
5. Compliance frameworks, security policies, and dashboards (Ultimate): enforce required pipelines and scan policies across projects.

Part 8 — CI/CD and runners

1. Shared runners (GitLab-hosted) consume the tier's monthly compute minutes (Premium 10,000 / Ultimate 50,000); overages bill per 1,000 minutes.
2. Self-managed runners: register your own runners (in your cloud/on-prem) to avoid minute limits and meet data-locality needs.
3. Manage CI/CD variables/secrets at the group level; enable security scanning (SAST/DAST/dependency/container — Ultimate) in pipelines.

Part 9 — User lifecycle and seat management

Reconcile active members vs purchased seats regularly — especially 90 days before renewal to avoid true-up charges.

Part 10 — Ongoing operations

Appendix — Notes and caveats

• Annual billing only for paid tiers; deployment model is fixed for the contract term — choose SaaS vs Self-Managed vs Dedicated deliberately.
• SAML SSO + SCIM require Premium+; Enterprise Users require a verified domain on a paid group (Ultimate for full controls) — confirm the current tier requirement.
• Watch tier feature movement: GitLab occasionally repositions features (including into the Duo add-ons) between contract cycles — get contractual guarantees that capabilities stay in your tier for the term.
• SAML certificates expire — track the Entra app's signing-certificate expiry to avoid an SSO outage.
• Verify current steps and pricing at about.gitlab.com/pricing and GitLab docs — tiers, pricing, and console layout change periodically.