Current SSO implementation too restrictive
d
dmitrif
Summary
Currently the SSO implementation is entirely gated behind the SSO gold plan. This makes sense for enterprise customers that do not wish to spend extra effort implementing it.
For those of us with shallower pockets, one would hope that it'd be possible to write your own plugin / implementation.
Currently due to the fact that it's impossible to override the admin backend (without forking), there is no feasible way to enable alternative auth strategies as passport is initialized with a localStrategy only.
For this reason, I ask that the Passport strategies are configurable outside of the EE Gold plan.
Why is it needed?
I'm frustrated that the extensibility of the auth system is only reserved for EE Gold plan.
Suggested solution(s)
I ask that the Passport strategies are configurable outside of the EE Gold plan.
Zachary Skalko
In addition to the points above and in the GitHub issue, there are a number reasons that an application might want to reconfigure both the built-in admin panel parts that are not currently customizable as well as the admin passport rules.
- In a production setting, we'd love to introduce Captcha to the admin login screen.
- An application living behind an API gateway may want to inform the gateway that the API routes are for administrative purposed via headers.
- I may want to introduce more password constraints, or forced password rotation for my admin users.
- I could introduce a new auth mechanism for machine to machine administration. Think HMAC signature or otherwise.
Generally, the fact that @strapi/admin is a dependency of @strapi/strapi instead of a peer dependency makes this rather difficult for a few reasons.
- Due to the front-end build, Strapi depends on the file structure in node_modules to be consistent. So something using something like [yarn add alias](https://classic.yarnpkg.com/lang/en/docs/cli/add/#toc-yarn-add-alias) won't work.
- NPM overrides or Yarn resolutions could work but there is inconsistent behavior with the way that these features work with private registries. A pattern that custom admin implementations might use.
- It is likely that only small modifications would need to take place. Strapi's monorepo pattern makes it very noisy to manage upstream changes.
So while I do think that SSO is one factor here, the fact that is is extremely difficult to bring a customized @strapi/admin package is the core issue.
Keith Richard
Thank you for adding this ticket. I would like to see this added to the community version. Security is not something that should be kept behind a paywall.