first version of the knowledge base :)
This commit is contained in:
64
30 - Systems/homelab/identity-management-patterns.md
Normal file
64
30 - Systems/homelab/identity-management-patterns.md
Normal file
@@ -0,0 +1,64 @@
|
||||
---
|
||||
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/)
|
||||
Reference in New Issue
Block a user