I am using Keycloak as the IDP. I have multiple Orgs configured under my install of Bitwarden.
Keycloak wants a unique ID per client, and the SSO configuration for each org generates the same SAML SP Entity ID.
Currently this is not the way our configuration is setup to work. The SP Entity ID is fixed upon the hosting environment itself. If that’s self-hosted or cloud based, it uses the root site URL for the SSO service + /saml2.
Explanation
Could this be done? Absolutely! I’ll work with the team to get a card on our backlog/board, but essentially it would entail adding another server-level configuration option OR org setting (would have to determine if we want to support this via our Cloud platform as well), which would override the handling of SP EntityID generation (which the plumbing is actually already in place for):
See:
The code here generates the SSO configuration profile hot-loaded for handling SSO requests
The code here generates the UI where you can view and copy the SP EntityID
These are the only 2 places that is used. Now, I do remember there was a reason we weren’t using it that way, because we did originally and then fell back on the more generic flavor of the SP EntityID that was universally global to the server. For the life of me I cannot remember why, because the ACS URL, etc. certainly have the Organization ID embedded in them and are unique which is used in mapping handlers and validating nonce/state on the Assertion, etc. Not sure why it would matter if the SP EntityID had the OrgID in there or not; but for some reason it did before (will have to re-investigate); the metadata URL for download is the more specific Org URL as well.
Options
If you are self-hosting and are comfortable with code + Docker compose, you could modify this code yourself to simply pass the additional scheme argument to the BuildSaml2ModulePath() method calls, where scheme = name | organizationId.ToString() (essentially the Organization ID). Modifying those 2 lines of code linked above will give you a “hard-coded” way of resolving this today w/o the optionality/configurability of turning that SP EntityID generation on/off (and then of course you would need to manually update/maintain your instance from code, which can be a bit much for some folks).
Conclusion
Let me know if you have any questions on any of this. As I said I’ll get with @tgreer to round this up in our backlog so there’s some visibility for the team and we’ll work through discussions on the same internally.
Thanks for the detailed response! No questions after that
With that said.
I couldn’t program my way out of a cardboard box.
You definitely wouldn’t want to run any of my code on any system you care about