Add configurable user attribute mapping from OIDC claims

[aaronlippold]

Overview

Different OIDC providers use different claim names for user attributes, which can make it challenging to integrate with various identity providers. This enhancement would add configurable mapping between OIDC claims and Vulcan user attributes.

Current Limitation

• The application expects specific claim names (e.g., email, name)
• Different providers may use different claim names for the same information:
  • Email: email vs mail vs preferred_username vs upn
  • Name: name vs display_name vs full_name vs given_name + family_name
  • Username: preferred_username vs sub vs user_name
• This requires code changes to support new providers with different claim structures

Proposed Enhancement

Add a configuration section in vulcan.yml to map OIDC claims to user attributes:

oidc:
  client_id: xxx
  client_secret: xxx
  discovery_url: https://example.okta.com/.well-known/openid-configuration
  claim_mapping:
    email: mail                    # Map 'mail' claim to email attribute
    name: displayName             # Map 'displayName' claim to name attribute
    username: preferred_username   # Map 'preferred_username' to username
    # Or support complex mappings:
    name:
      format: "{given_name} {family_name}"  # Combine multiple claims

Benefits

• Flexibility to work with any OIDC provider without code changes
• Easier integration with enterprise identity providers that use custom claim names
• Reduced maintenance burden when adding support for new providers
• Better support for providers that structure claims differently

Technical Considerations

• Would need to update the OmniAuth callback handler to use the mapping configuration
• Should support both simple mappings (claim -> attribute) and complex mappings (combining multiple claims)
• Need to handle cases where expected claims are missing
• Should provide sensible defaults that work with common providers

Example Use Cases

1. Azure AD: Often uses upn for email instead of email
2. Custom Enterprise Providers: May have completely custom claim structures
3. Providers using nested claims: Some providers nest user info in sub-objects

Implementation Notes

• The mapping should be applied in the omniauth_callbacks_controller.rb
• Should maintain backward compatibility with existing configurations
• Could provide pre-defined mappings for common providers as templates

Related to the OKTA authentication fixes PR that added OIDC discovery support.