mirror of
https://github.com/BookStackApp/BookStack.git
synced 2026-02-05 16:49:47 +03:00
[Feature Request]: Possibility to allow SAML and LDAP-Login as AUTH_METHODE at the same time #2478
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @dringewald on GitHub (Nov 6, 2021).
Describe the feature you'd like
It would be useful to use both SAML and LDAP at the same time as "AUTH_METHODE".
This is especially useful for people who have an Active Directory and Active Directory Federation Services (AD FS) on windows in use.
It could look like this: AUTH_METHODE="ldap|saml2".
If a user already has an account created via LDAP, the account should be mapped with the existing one when using SAML. This is only possible if the provided attribute (for example the email) is the same with the existing mail in bookstack. For now a login with SAML is blocked if the user was previously created via LDAP.
Describe the benefits this feature would bring to BookStack users
Furthermore, you would have a fallback without having to switch back to the other one, should something go wrong, for example because one of the services has failed. This would give redundancy to the whole login. In addition, there are rarely use cases that only allow one of the two methods. When using an AD FS system, there is always an Active Directory behind it. It is therefore easy to fall back if something goes wrong.
Additional context
No response
@ssddanbrown commented on GitHub (Nov 6, 2021):
Hi @Holt31, Thanks for your request.
Can you describe your scenario a little further? Are you intending to use SAML2 and LDAP against the same AFDS system? Is there a particular challenge you're facing that this would solve? You mention redundancy but that seems a bit overkill to be worth our implementation, especially if using the same ADFS system since we're only talking redundancy at a very specific level if so.
Just trying to understand the problem rather than this specific idea of implementation since adding such a feature would raise a bunch of additional scenarios and problems to consider & address.
This is not true if usage of the external_authentication_id is aligned. If they're both using email address a switchover should be fairly painless.
@dringewald commented on GitHub (Nov 7, 2021):
Thanks for the fast reply.
I have actually 2 scenarious.
Scenario 1 (which I'm using now):
I have my Domain Controller and my AD FS-Server on seperate servers. (technically the AD FS-Server is a replicating domain controller) Since both Domain Controllers are replicating with each other, they both have the same data. One of them doesn't have an open LDAP-Port, so I can't use LDAP on this one. I'm using AD FS for that. Now I want to have LDAP as Fallback, when AD FS isn't working.
Scenario 2 (which I like to implement):
I have an MS 365 Account, where you can use SAML for authentication (Azure Active Directory).
I'm using an onpremise Active Directory to sync Users into the Azure AD.
I want to use the SAML from Azure AD and the LDAP of the Onpremise at the same time..
So basically both scenarios are actually the same thing.
Thanks for mentioning it.
I tested it again and noticed that I used the "sAMAccountName" attribute for the external ID when using LDAP and I'm using the "userPrincipalName" attribute for the authentication against AD FS. Since these two differ it makes sense, that a login wasn't possible before. When I changed the ldap attribute to userPrincipalName the login worked.
@userbradley commented on GitHub (Dec 10, 2021):
Bumping this too, as I'm using jumpcloud for LDAP, and also office 365 through jumpcloud for SSO.
@ssddanbrown commented on GitHub (Nov 8, 2022):
I'm closing this to collapse this into #2715, which I've made into the auth-method abstract issue for combining auth options.