Auth Future Planning

This document outlines EGI's roadmap for authentication and identity management improvements. The current per-service account provisioning model works at our current scale but will not scale efficiently as the team and number of services grow. The long-term goal is centralized identity management with single sign-on (SSO).

Current State

Today, EGI manages accounts individually across each service:

Service	Auth Method	Identity Source
GitHub	GitHub account + org membership	GitHub identity
Slack	Email invitation	Slack identity
Vercel	Email invitation	Vercel identity
PostHog	Email invitation	PostHog identity
ERPNext	Local account	ERPNext identity
SuiteDash	Local account	SuiteDash identity
Email	Managed mailbox	Email provider

Pain Points

• Manual provisioning: Each service requires separate account creation and configuration
• Inconsistent MFA: Each service has its own MFA implementation; enforcement depends on per-service settings
• Deprovisioning risk: Revoking access requires touching every service individually; missed services create security gaps
• No centralized audit: Access reviews require pulling reports from each service separately
• Password fatigue: Team members manage separate credentials for each service (mitigated partially by MFA apps and password managers)

SSO Roadmap

Phase 1: Foundation (Current)

• Per-service accounts with consistent naming conventions
• MFA required across all services
• Quarterly access reviews
• Documented provisioning and deprovisioning procedures

Phase 2: Identity Provider Deployment

• Deploy a self-hosted identity provider (IdP)
• Configure SSO for services that support SAML or OIDC (GitHub, Vercel, Slack)
• Centralize user directory and group management
• Implement automated provisioning through the IdP

Phase 3: Full Integration

• All services authenticate through the central IdP
• Automated provisioning and deprovisioning based on IdP group membership
• Centralized MFA enforcement
• Unified audit logging across all services
• Self-service access requests through the IdP portal

Identity Provider Evaluation

EGI is evaluating self-hosted identity providers that align with our open-source-first approach and technical requirements.

Authentik

Authentik is a modern, open-source identity provider built with Python and Django.

Strengths:

• Modern UI with intuitive administration
• Built-in support for SAML, OIDC, LDAP, and SCIM
• Flow-based authentication engine (customizable login flows, MFA enrollment, password recovery)
• Application proxy for services that do not natively support SSO
• Docker-based deployment aligns with EGI infrastructure patterns
• Active development community and regular releases

Considerations:

• Newer project compared to Keycloak; smaller community
• Self-hosted requires infrastructure management and monitoring
• Documentation is good but less extensive than Keycloak's

Keycloak

Keycloak is a mature, open-source identity and access management solution maintained by Red Hat.

Strengths:

• Battle-tested in enterprise environments
• Comprehensive protocol support (SAML, OIDC, OAuth 2.0, LDAP, Kerberos)
• Extensive documentation and large community
• Fine-grained authorization services
• User federation for connecting to existing directories

Considerations:

• Java-based; heavier resource footprint than Authentik
• Admin UI is functional but less modern
• Configuration complexity is higher
• Overkill for small teams; better suited when EGI scales further

Evaluation Criteria

Criterion	Weight	Authentik	Keycloak
Ease of deployment (Docker)	High	Strong	Moderate
Protocol support (SAML, OIDC)	High	Strong	Strong
Administration UX	Medium	Strong	Moderate
Community and documentation	Medium	Growing	Mature
Resource footprint	Medium	Light	Heavy
Customizability	Medium	Strong (flows)	Strong (SPIs)
Long-term viability	High	Good	Strong

Current recommendation: Authentik is the preferred candidate for Phase 2 based on its modern architecture, lighter footprint, and alignment with EGI's Docker-based infrastructure. This recommendation will be revisited before implementation begins.

Centralized Access Goals

When the IdP is deployed, the following capabilities become available:

Automated Provisioning

• New team members are created in the IdP with their role and group memberships
• SSO-connected services automatically grant access based on IdP groups
• No more per-service manual account creation for SSO-enabled services

Automated Deprovisioning

• Deactivating a user in the IdP immediately revokes access across all SSO-connected services
• Dramatically reduces the risk of missed revocations during offboarding
• Service-specific accounts that do not support SSO still require manual revocation (tracked via the offboarding checklist)

Centralized MFA

• MFA is enforced at the IdP level, not per service
• One MFA enrollment covers all services
• Consistent MFA policy across the organization
• Hardware security key support managed in one place

Unified Audit Trail

• All authentication events (logins, failures, MFA challenges) logged centrally
• Cross-service access visibility in a single dashboard
• Automated alerting for suspicious activity (multiple failed logins, logins from unusual locations)
• Simplified quarterly access reviews

Implementation Timeline

This is a target timeline, subject to adjustment based on team capacity and priorities.

Phase	Target	Key Milestones
Phase 1 (current)	Ongoing	Naming conventions, MFA enforcement, quarterly reviews, documented procedures
Phase 2	TBD	IdP selected and deployed; GitHub, Slack, and Vercel connected via SSO
Phase 3	TBD	All services connected; automated provisioning; centralized audit

Next Steps

1. Finalize IdP selection (Authentik vs. Keycloak) based on a proof-of-concept deployment
2. Identify infrastructure requirements (hosting, DNS, TLS certificates)
3. Pilot SSO with one service (GitHub recommended as the first integration)
4. Document SSO configuration and rollback procedures
5. Gradually onboard remaining services to SSO