Version 1.x Planning

[Luzifer]

As a systems operator, user and author of the nginx-sso software I'm not happy about several things in the present implementation. Also there are a lot of requests which cannot be addressed in the current code-base but should be implemented.

In order to solve this situation a breaking change is needed (breaking at least the configuration format) while retaining as much outward-facing APIs as possible. As a breaking change should not happen too often this needs to be done properly on the first take. Therefore lets plan how to do it.

[!IMPORTANT] So if you have other things you like to see in the v1.x release please open an issue for that and I'm gonna add it to the plan (if I see a fit for it!). If you have comments on and ideas for the plan, feel free to discuss in this issue and we'll improve the plan before tackling it.

---

Currently there is only one configuration of each auth-provider type (i.e. OIDC, LDAP, …) supported. This is an issue for myself requiring some users in the system using a different OIDC provider than the rest. Therefore the application should take an "infinite" number of providers of each type. (To support this also return-urls need to change to specifically select a single provider and not to ask all providers to validate the callback.)

• refs https://github.com/Luzifer/nginx-sso/issues/46

---

The "session cookie" doesn't fit into security criteria: It has an expiry time but the time is solely "enforced" by the life-time of the cookie. While this needs manipulation on the local system (and IMHO is not really a security issue) this should be addressed. The session cookie needs to be changed to a more "modern" format which addresses this. We therefore should switch to a JWT (likely we will still store that one in a cookie but a JWT is signed, possibly encrypted and brings the structure of validity times, …).

This token also should hold provider specific information as i.e. oAuth state parameters. (To support this also return-urls need to change to specifically select a single provider and not to ask all providers to validate the callback.)

• refs https://github.com/Luzifer/nginx-sso/issues/81
• refs https://github.com/Luzifer/nginx-sso/issues/49

---

A bit more provider-specific OIDC returns a complex structure changing from implementation to implementation. Some implementations do leave details out while others are providing extra information (like groups). Therefore the config (and the OIDC-provider) must support fetching certain fields (like the username) from i.e. JSON-Path expressions.

• refs https://github.com/Luzifer/nginx-sso/issues/86
• refs https://github.com/Luzifer/nginx-sso/issues/60

---

The login page hasn't aged very well and is kinda broken / not very usable on mobile devices. Also it loads remote resources (not fitting a security-related application like nginx-sso). Also it needs a proper way to do white-labeling the login page for corporations using nginx-sso.

• refs https://github.com/Luzifer/nginx-sso/issues/80

---

At the moment there is a hard-tied relationship between the authentication provider and the MFA provider which means only a few auth-providers even support MFA. This is broken by design and must be fixed. The MFA configuration therefore must be severed from the auth-provider configuration. There should be a way to still configure MFA for users inside the configuration (i.e. "When user luzifer logs in, they need to provide MFA of types […]") which applies to all providers yielding a user luzifer. Also providers should be able to hint at the login "hey, I found user foobar, they need to provide one of these MFA types: […]". In order to do so i.e. Crowd can use the attribute fields to store a JSON object, LDAP can provide a DN to the JSON object, ….

• refs https://github.com/Luzifer/nginx-sso/issues/23
• refs https://github.com/Luzifer/nginx-sso/issues/22

---

Not directly feature-related but to be tackled during this rewrite: The code-base is 6 years old and well, as every developer looking at their old code I'm asking myself "who wrote that crap?". This needs to be resolved and properly structured.