December 2025 Improvements - Azure AD, Internal Networks, Startup Race Condition (#100)

* Allow internal IPs for OIDC configuration via extra flag.

Addresses issue #97

* Allow for internal IPs in OIDC configuration.

Addresses issue #97.

* feat: Add allowPrivateIPAddresses config option for internal networks

Adds a new configuration option `allowPrivateIPAddresses` that allows
OIDC provider URLs to use private IP addresses (10.x.x.x, 172.16-31.x.x,
192.168.x.x). This is useful for internal deployments where Keycloak or
other OIDC providers run on private networks without DNS resolution.

Security considerations:
- Loopback addresses (127.0.0.1, localhost, ::1) remain blocked
- Link-local addresses (169.254.x.x) remain blocked
- Default is false (secure by default)

Fixes #97

* feat: Support non-email user identifiers for Azure AD

Add userIdentifierClaim configuration option to support Azure AD users
without email addresses. This allows using alternative JWT claims like
"sub", "oid", "upn", or "preferred_username" for user identification.

- Default behavior uses "email" claim (backward compatible)
- Falls back to "sub" claim if configured claim is missing
- allowedUsers matches against the configured claim value
- allowedUserDomains only applies when using email-based identification

Fixes #95

* Race condition on traefik pod startup

When the plugin initializes and calls GetMetadataWithRecovery():

1. Checks cache first (if metadata is cached, returns immediately)
2. Creates a retry executor with startup-optimized settings (10 attempts, 1s delays)
3. Attempts to fetch metadata from the OIDC provider
4. If the fetch fails with a retryable error (connection refused, EOF, TLS/certificate errors, Traefik default cert), it waits and retries
5. After 10 attempts or on a non-retryable error, returns the error

This allows the plugin to handle the race condition where:
- Traefik initializes the plugin before routes are established
- Traefik serves its default certificate before loading real ones
- The OIDC provider pod isn't fully ready yet

Fixes issue #90

* Race condition on traefik pod startup

When the plugin initializes and calls GetMetadataWithRecovery():

1. Checks cache first (if metadata is cached, returns immediately)
2. Creates a retry executor with startup-optimized settings (10 attempts, 1s delays)
3. Attempts to fetch metadata from the OIDC provider
4. If the fetch fails with a retryable error (connection refused, EOF, TLS/certificate errors, Traefik default cert), it waits and retries
5. After 10 attempts or on a non-retryable error, returns the error

This allows the plugin to handle the race condition where:
- Traefik initializes the plugin before routes are established
- Traefik serves its default certificate before loading real ones
- The OIDC provider pod isn't fully ready yet

Fixes issue #90

* Headers too big and 431 responses

Added new option `minimalHeaders` to reduce the size of forwarded headers from the auth middleware to backend services.

  - When minimalHeaders: false (default): All headers are forwarded as before
    - X-Forwarded-User (always set)
    - X-Auth-Request-Redirect
    - X-Auth-Request-User
    - X-Auth-Request-Token (the large ID token)
    - X-User-Groups, X-User-Roles (if configured)
  - When minimalHeaders: true: Reduces header overhead
    - X-Forwarded-User (always set)
    - X-User-Groups, X-User-Roles (still forwarded if configured)
    - Custom templated headers (still processed)
    - Skipped: X-Auth-Request-Token, X-Auth-Request-User, X-Auth-Request-Redirect

Fixes issues #64 and #86

utilities.go

@@ -55,6 +55,51 @@ func (t *TraefikOidc) safeLogInfo(msg string) {
 // DOMAIN VALIDATION
 // =============================================================================
 
+// isAllowedUser checks if a user identifier is authorized based on the configured user identifier claim.
+// When using email as the identifier (default), it validates against allowedUsers and allowedUserDomains.
+// When using non-email identifiers (sub, oid, upn, etc.), it only validates against allowedUsers
+// since domain-based validation doesn't apply to non-email identifiers.
+//
+// Parameters:
+//   - userIdentifier: The user identifier to validate (email, sub, oid, upn, etc.).
+//
+// Returns:
+//   - true if the user is authorized, false otherwise.
+func (t *TraefikOidc) isAllowedUser(userIdentifier string) bool {
+	// If no restrictions are configured, allow all authenticated users
+	if len(t.allowedUserDomains) == 0 && len(t.allowedUsers) == 0 {
+		return true
+	}
+
+	// Check if user is explicitly allowed
+	if len(t.allowedUsers) > 0 {
+		_, userAllowed := t.allowedUsers[strings.ToLower(userIdentifier)]
+		if userAllowed {
+			t.logger.Debugf("User identifier %s is explicitly allowed in allowedUsers", userIdentifier)
+			return true
+		}
+	}
+
+	// For email-based identifiers, also check domain restrictions
+	// Only apply domain validation if using email as identifier AND identifier looks like an email
+	if t.userIdentifierClaim == "email" && strings.Contains(userIdentifier, "@") {
+		return t.isAllowedDomain(userIdentifier)
+	}
+
+	// For non-email identifiers with allowedUserDomains configured, log a warning
+	if len(t.allowedUserDomains) > 0 && t.userIdentifierClaim != "email" {
+		t.logger.Debugf("AllowedUserDomains is configured but userIdentifierClaim is '%s', not 'email'. Domain validation skipped for: %s",
+			t.userIdentifierClaim, userIdentifier)
+	}
+
+	// User not found in allowedUsers list
+	if len(t.allowedUsers) > 0 {
+		t.logger.Debugf("User identifier %s is not in the allowed users list", userIdentifier)
+	}
+
+	return false
+}
+
 // isAllowedDomain checks if an email address is authorized based on domain or user whitelist.
 // It validates against both allowed user domains and specific allowed users.
 // Parameters: