Requires a server to run the connector from (along with the associated maintenance, etc)
Only works with a specific list of “directory providers” (eg Okta, Active Directory)
An alternative (ideally in addition to the Directory Connector) would be for the server (both self-hosted and cloud versions) to support System for Cross-domain Identity Management (“SCIM”), which is an open specification (http://www.simplecloud.info/) for synchronizing user information (names, usernames) and group information (group names, group membership).
This would allow push based provisioning/deprovisioning directory between the identity provider (eg Okta, Azure Active Directory) and Bitwarden.
The crux of the features required for SCIM are already available in the Bitwarden Public API anyway, so, this seems to be just a matter of using the sample code above to adapt in a way that conforms to SCIM standard.
Would really love to see this implemented. That way, all the user provisioning could just be done without any on premises software, Okta or AzureAD could just take care of it in the cloud!
The need to maintain a system for the Directory Connector will probably be the reason why we’re choosing a competitor as password management solution for our 500+ users. It’s not only a nice-to-have but potentially a showstopper for most mid-size enterprises without dedicated SecOps-department imo.
SCIM (or functions of) are really necessary for and business with security requirements. Filters in DC are not enough, can’t exclude users based on attributes so AD guests are included. Cannot dynamically specify groups meaning central management isn’t possible.
Lack of this functionality is forcing us to choose another password manager for our corporate password store. Both the requirement to run an external service to perform sync, and in particular the lack of ability to manage membership from the IdP side make using the DC a non-starter.