Multi-Domain Protection

We have seen and heard the feedback from our users and we are acting on it. This feature is being prioritized. Allowing administrators to protect more than one root domain utilizing a single Authelia instance is going to be a difficult feature to implement but we’ll actively take steps to implement it.

Stages#

This section represents the stages involved in implementation of this feature. The stages are either in order of implementation due to there being an underlying requirement to implement them in this order, or in their likely order due to how important or difficult to implement they are.

Decide on a Method#

We need to decide on a method to implement this feature initially and how it will finally look to provide SSO between root domains.

UPDATE: The initial implementation has been decided as well as the SSO implementation.

Decide on a Session Library#

We’ve decided on moving away from using the current session library and plan on entirely implementing session logic internally.

Initial Implementation#

This stage is waiting on the choice to handle sessions. Initial implementation will involve just a basic cookie implementation where users will be required to sign in to each root domain and no inter-domain SSO functionality will exist.

See the SSO implementation for how we plan to address the sign in limitation.

SSO Implementation#

While the initial implementation will require users to sign in to each root domain and no SSO functionality will exist as outlined in the initial implementation, it’s possible via Identity protocols / frameworks like OpenID Connect 1.0 to perform Single-Sign On transparently for users.

This will very likely be implemented at the same time as OpenID Connect 1.0 Relying Party support.