Mix/combine `AUTH_METHOD` options

[pbordon]

Exist the possibility to login in a mixed method: LDAP or simple user registration, defined by user?

[ssddanbrown]

Hi @pbordon, Would you be able to provide insight into the environment where you'd want this within and the benefits this would bring?

[pbordon]

In my organization, we have internal users, connected to an AD and external users, which are many and vary over time. Therefore I wanted to implement the login via LDAP for internal users and for external users to register separately.

[ssddanbrown]

Updating this to be generic to methods, and merging similar issues into this.

[abulgatz]

Any plans to add this to your roadmap or implement this? Internal SSO with guest access seems pretty common.

[ssddanbrown]

@abulgatz Probably not anytime too soon, to be totally honest. It's high-risk, low demand, low target audience, high support & maintenance. Therefore it doesn't look worth including at this time.

[Fabsky]

I'm in the same case, I mean I've contents for internal users (azure), and content for customers (self register)

[mfatfhg]

Hi, I have opened #4401 and because it was closed, I would like to continue the discussion here.

One of the reasons why we would like to see this features was:

So, I understand that its not a high level feature request on your roadmap. In our opinion, the ability to authenticate with different types of identities (local db users, oidc, ldap) is somethink like industry standard and should be possible.

On of the reasons is the following: Typically, OIDC providers are services in the cloud (if you use SAAS IDPs it might be auth0, or if you self host a IDP, it might be located on a remote site of your company).

If you only allow OIDC at the same time, you cant login to bookstack anymore if you dont have WAN/Internet connectivity anymore. And because we would like to use bookstack as documentation system for emergency manuals too, we would like to have the possibility to login with different types of accounts ( local db accounts or maybe ldap accounts from a local Active directory) as fallback method.

A admin should always have the possibility to access a system in case of technical problems (bad WAN/Internet connectivity).

This was answered by @ssddanbrown with the following argument:

Okay. Could always flip the auth method in an emergency.

This would be like changing the electronic door locks against bearded locks in case of power failure before entering the building.

And changing a config only to access your documentation system is not what you want to do in an emergency situation. And not everyone who need access to the system in such a situation has the ability or possibility to do this.

[ssddanbrown]

@GitTH Like this:?

Open image here


Third party auth sources work alongside primary auth options, so you may be able to use Azure/Google third party options alongside standard email auth.

[simonpa71]

Plus one for this feature request. LDAP may work or not, but I would like to configure a local Admin access anytime. Gitea has this feature, and it makes it easy to configure an admin for mainenance and config, without depending on LDAP, while importing local users with LDPAP. My scenario is simpler than generic mix and match, and could be a starting point.

[CamaroSS]

This feature would be very useful. This way we would be able to sign in from our internal system using SAML2 and have external accounts who sign in using email and password.