Yes — document the project on GitHub. The answer is unambiguous in the IGA hiring space. Hiring managers for identity governance roles are skeptical of candidates with only theoretical knowledge because enterprise IGA tools are notoriously difficult to implement. SailPoint, Saviynt, and Okta IGA all have significant implementation complexity that doesn't come through in certification studying. A working MidPoint lab proves you can execute configurations, debug integration failures, and think through workflow design — which is exactly what the role requires.
The combination you're building — Okta certifications, Entra ID and AD experience, and a hands-on MidPoint project — is a strong package. The question isn't whether to document it, it's how to structure the documentation so it reads like a case study rather than a code dump.
Why MidPoint Is a Legitimate Choice for IGA Portfolio Work
MidPoint has the same features as SailPoint and Saviynt for most IGA fundamentals. MidPoint is an open-source Evolveum product with active enterprise deployments, a community conference, and genuine IGA capability: provisioning, deprovisioning, role management, access certifications, policy enforcement, and REST API connectivity. Employers who know identity will recognize it; employers who don't will see a working system with documented architecture.
The observation that MidPoint is "locked down" relative to SailPoint and Saviynt likely refers to documentation and community resources being less extensive than the enterprise IGA vendors. SailPoint and Saviynt have large professional services ecosystems that produce extensive documentation. MidPoint's community is active but smaller. That's a tradeoff for free access to a real IGA platform with no vendor qualification process.
What to Document: The Four Concepts Hiring Managers Care About
1. The JML lifecycle with a real source of truth.
The single concept that matters most in IGA interviews is the joiner-mover-leaver lifecycle — specifically, how you establish a source of truth and connect it to downstream provisioning. For your GitHub project, this means:
Document how MidPoint connects to a dummy HR system (a CSV file, a simple database, or a REST API you've built). Show that when a new user is created in the HR system, MidPoint detects the event and automatically provisions birthright access — the standard set of applications and permissions appropriate for that user's role. Show the offboarding workflow: when the user is marked inactive in the HR system, MidPoint systematically revokes access across every connected resource.
The key detail to emphasize is the source of truth concept — that the HR system drives identity events, not manual IT requests. This is what modern IGA architecture looks like and what hiring managers want to see you understand.
2. API integrations and authentication.
Modern IGA is largely an integration problem. Every application in the enterprise stack needs to be reachable for provisioning and deprovisioning, and most of that reach happens through REST APIs. For your GitHub project:
Write scripts (Python or Node.js work well) that interact with REST APIs to create, update, and deactivate users. Document how you handle authentication in those scripts — API tokens, OAuth 2.0 bearer tokens, or service account credentials. The authentication choice matters because it demonstrates you understand why credentials shouldn't be embedded in scripts (they should be in environment variables or secrets management), why OAuth 2.0 is preferred for delegated authorization scenarios, and what the security implications of different approaches are.
Even if the target application is a test environment you've set up locally, the integration pattern is what demonstrates the skill.
3. Role and entitlement mapping.
IAM tools handle basic access (who can log in to what). IGA handles granular entitlements (what they can do inside the application). For your GitHub project, design and document a role hierarchy that maps job titles to specific entitlements rather than just application access. A concrete example: a "Software Engineer" gets triage access to code repositories; an "Engineering Manager" gets admin access to the same repositories plus access to deployment pipelines. Document how MidPoint enforces these role assignments automatically when a user's job title is provisioned from the HR source.
This is the principle of least privilege in practice — and being able to explain the design decisions (why triage and not admin, what the business justification is) is as important as the technical implementation.
4. Compliance reporting and the three IGA questions.
The primary commercial driver for IGA purchases is regulatory compliance. Access reviews, audit reports, and the evidence artifacts that auditors require are what justify the budget. For your GitHub project, document how your MidPoint setup can generate an audit report that answers the three core IGA questions: who has access to what, should they have that access, and what evidence exists that the access has been reviewed. Even a simple report that shows user-application-entitlement mappings with timestamps demonstrates you understand what compliance teams need.
How to Structure the GitHub Repository
The difference between a code dump and a portfolio piece is the README.
Write the README as a case study, not a technical reference. Structure it as:
The business problem. One paragraph explaining what you're solving — "Automating SOC 2 access reviews for a company with 200 employees and 30 SaaS applications" or "Zero-touch onboarding tied to HR events with automatic birthright access provisioning." This is how hiring managers will read it: they want to see you understand why the system exists, not just how it works.
Architecture diagram. A simple diagram showing the HR source, the MidPoint instance, and the downstream applications. This doesn't have to be polished — a clear diagram drawn in draw.io or even ASCII art is fine. It shows you can communicate system design, which is an architect-level skill.
Key workflows documented. Walk through the joiner, mover, and leaver workflows with enough detail that someone unfamiliar with your specific configuration could understand what's happening and why.
Code snippets with context. Don't just post scripts. Explain what each script does, what problem it solves, and what you learned from building it. The reflection is as valuable as the code.
What you'd do differently at enterprise scale. This is the optional section that separates good portfolio pieces from excellent ones. Discuss what changes when you're doing this at 10,000 users instead of 10 — role mining complexity, connector maintenance overhead, approval workflow design for distributed organizations. Showing you've thought about scale even in a lab environment signals architectural thinking.
A Note on MidPoint vs. Enterprise Platforms in Interviews
Be prepared to explain why you chose MidPoint over a SailPoint sandbox or Okta developer account. The honest answer is the right one: MidPoint is open-source and fully functional without a vendor relationship, which made it accessible for self-directed learning. That's a legitimate and understood reason in the identity community.
Where you can strengthen this in interviews: demonstrate that you understand how MidPoint's approach maps to what SailPoint or Saviynt does differently. The connector architecture, the role management model, the access certification workflow — being able to compare and contrast shows that your MidPoint experience is translatable, not just platform-specific knowledge.
Frequently Asked Questions
Should you document an IGA learning project on GitHub?
Yes. Hiring managers for identity governance roles value demonstrated implementation experience over theoretical knowledge because enterprise IGA platforms are complex to implement in practice. A documented MidPoint project proves you can configure integrations, design workflows, and think through governance architecture — which certifications alone don't demonstrate.
Is MidPoint a credible platform for IGA portfolio work?
MidPoint is an open-source IGA platform with real enterprise deployments, an active community, and genuine IGA capabilities including provisioning, access certifications, role management, and policy enforcement. It's a credible choice for portfolio work, particularly compared to proprietary platforms that require vendor relationships or certification programs to access meaningfully. Identity hiring managers who know the field will recognize it; those who don't will see a working system with documented architecture.
What IGA concepts should an identity governance portfolio demonstrate?
The concepts that matter most for IGA hiring are: JML lifecycle automation with a documented source of truth, API-based integrations with appropriate authentication handling, role and entitlement design that demonstrates principle of least privilege thinking, and compliance reporting that answers the core governance questions. These translate directly to the work identity governance practitioners do regardless of which platform they're using.
How is MidPoint different from SailPoint or Saviynt?
MidPoint is open-source with a community edition available without a vendor relationship, which makes it accessible for self-directed learning. SailPoint and Saviynt are enterprise commercial platforms with extensive professional services ecosystems, more extensive connector libraries, and larger customer bases. The core IGA concepts — lifecycle management, access reviews, role management, compliance reporting — are present in all three. The platform-specific differences are primarily in connector coverage, UI polish, and the surrounding vendor ecosystem.












