Feature Request

This is a feature request covering the eventual design of a feature.

Description

Important Notes:

1. Users should be able to apply attribute mappings in differing ways such as a header etc. Should reconsider the design with this in mind.

The idea is allow admins to map attribtues from the authentication backend to other elements within the application. For starters this would be useful to map specific attributes to specific claims in OIDC. This however could potentially be applied to other areas in the future such as access control (Remote-* headers).

Proposed Config Example:

attribute_mapping:
  default:
   - name: manager
     source: manager
     scope: profile
   gitea:
   - name: email
     source: alternateEmail
     scope: email
   - name: manager
     source: manager
     scope: profile
   custom_headers:
   - name: Remote-Manager
     source: manager
     
access_control:
  rules:
  - domain: example.com
    policy: bypass
    attribute_mapping: custom_headers
     
identity_providers:
  oidc:
    clients:
    - id: gitea
      attribute_mapping: gitea
      

Proposed User File Example:

users:
  john:
    displayname: "John Doe"
    password: "$argon2id$v=19$m=65536,t=3,p=2$BpLnfgDsc2WD8F2q$o/vzA4myCqZZ36bUGsDY//8mKUYNZZaR0t4MFFSs+iM"
    email: john.doe@authelia.com
    groups:
      - admins
      - dev
    custom_attributes:
      manager: Fred J

Rules/Points:

1. The mapping named default would set overrides for anything not specifically configured to use another mapping.
2. The standard values for all claims will be applied to all tokens unless override by the mapping.
3. Storage of attributes:
   1. The storage of user information will be refactored into a memory cache instead of being part of the session.
   2. The only things stored in the session after this date will be the username and any session locked information.
   3. The user cache will have a TTL which when expired will trigger the check of the authentication backend for updated information instead of handling this in the handlers package.
4. All attributes required by a mapping will be loaded when user information is requested if they are available. If the attributes do not exist they will be ignored for that user.
5. Mappings could potentially be restricted to specific scopes, so multiple clients with different scope options could share the same mapping without having all mappings apply.
6. We would have to restrict the potential mapping names so that important claims cannot be override. For example sub, iat, etc.

Use Case

Mapping attributes in a customized way.