65 lines
2.2 KiB
Markdown
65 lines
2.2 KiB
Markdown
---
|
|
title: Identity Management Patterns
|
|
description: System-level identity management patterns for self-hosted and homelab environments
|
|
tags:
|
|
- identity
|
|
- authentication
|
|
- architecture
|
|
category: systems
|
|
created: 2026-03-14
|
|
updated: 2026-03-14
|
|
---
|
|
|
|
# Identity Management Patterns
|
|
|
|
## Summary
|
|
|
|
Identity management patterns describe how users, devices, and services are authenticated and governed across a self-hosted environment. Strong patterns reduce credential sprawl and make account lifecycle management more consistent.
|
|
|
|
## Why it matters
|
|
|
|
As services multiply, local account management becomes a source of weak passwords, missed offboarding, and inconsistent MFA coverage. A system-level identity pattern helps centralize trust while preserving operational fallback paths.
|
|
|
|
## Core concepts
|
|
|
|
- Central identity provider for users
|
|
- Federated login to applications through OIDC or SAML
|
|
- Strong admin authentication for infrastructure access
|
|
- Separate handling for service accounts and machine credentials
|
|
|
|
## Practical usage
|
|
|
|
A practical identity pattern often looks like:
|
|
|
|
```text
|
|
Users -> Identity provider -> Web applications
|
|
Admins -> VPN + SSH key or hardware-backed credential -> Infrastructure
|
|
Services -> Scoped machine credentials -> Databases and APIs
|
|
```
|
|
|
|
Supporting services may include:
|
|
|
|
- MFA-capable identity provider
|
|
- Reverse proxy integration for auth-aware routing
|
|
- Secrets management for service credentials
|
|
|
|
## Best practices
|
|
|
|
- Centralize user login where applications support it
|
|
- Require MFA for administrative and internet-exposed access
|
|
- Keep service credentials scoped to one system or purpose
|
|
- Maintain documented break-glass and recovery procedures
|
|
|
|
## Pitfalls
|
|
|
|
- Treating shared admin accounts as acceptable long-term practice
|
|
- Leaving old local users in place after federation is introduced
|
|
- Using one service credential across many applications
|
|
- Forgetting to protect the identity provider as critical infrastructure
|
|
|
|
## References
|
|
|
|
- [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html)
|
|
- [NIST Digital Identity Guidelines](https://pages.nist.gov/800-63-3/)
|
|
- [Yubico developer documentation](https://developers.yubico.com/)
|