User federation with external identity providers (LDAP, OIDC)

[gnieser]

Hello,

Currently, mosparo uses internal storage for user management. I think it would be a valuable addition to support user federation through external identity providers, especially in enterprise context, via LDAP and/or OIDC.

It would allow users to authenticate using their existing credentials (Active Directory, Keycloak, Azure AD, Okta, etc.)

Additionally, though more complex, it could also leverage user groups/roles from external providers and map them to mosparo’s permission model, further streamlining access control.

I’d be happy to discuss further configuration details and help refine the approach.
E.g.: ability to disable internal users to enforce federation and ability to re-activate a backup admin account in case the federation is broken.

Kind regards

[zepich]

Hi @gnieser

Thank you very much for your idea!

That's a great idea! My biggest problem here is deciding which of the possible solutions is the best. From my understanding/knowledge, we would have at least LDAP, OIDC, and SAML.

By biggest problem with the LDAP integration in Symfony (the framework we've used for mosparo) is that it is only compatible with one LDAP server, so if you use multiple (failover) servers in an enterprise environment, adding LDAP means that we would have to build the logic to handle multiple servers which is not a simple thing to do (we did it in a project for my employeer).

OIDC or SAML would not have this problem, but all these technologies require some work. From this perspective, I would try to integrate only one solution (at least as a start) to limit the complexity. Since OIDC is integrated more or less directly into Symfony, I prefer this one.

I think disabling the internal user system should be done with an environment variable. The process for this is that you install mosparo as it is for now (with the internal user management) and create an admin user there. After that, you can enable the external user management and (optionally) turn off the internal user management. In case of an emergency, you could re-enable the internal user management and log in with the admin user.

With this method, we can make sure that logging in via the internal system is completely blocked (if required, when the env variable is enabled).

What do you think?

Kind regards,
zepich

[gnieser]

Hi @zepich

Thanks for considering this suggestion.

By biggest problem with the LDAP integration in Symfony (the framework we've used for mosparo) is that it is only compatible with one LDAP server, so if you use multiple (failover) servers in an enterprise environment, adding LDAP means that we would have to build the logic to handle multiple servers which is not a simple thing to do (we did it in a project for my employeer).

I believe supporting failover in Symfony may not be a must-have. One could achieve failover with other means such as virtual IP or DNS failover A records.

OIDC or SAML would not have this problem, but all these technologies require some work. From this perspective, I would try to integrate only one solution (at least as a start) to limit the complexity. Since OIDC is integrated more or less directly into Symfony, I prefer this one.

I also would favor OIDC over SAML. Incidentally, supporting OIDC would allow to integrate with solutions such as Keycloak which in turn provide support for LDAP federation. It would provide a way to support LDAP indirectly (even if convoluted for someone would only have LDAP).

I think disabling the internal user system should be done with an environment variable. The process for this is that you install mosparo as it is for now (with the internal user management) and create an admin user there. After that, you can enable the external user management and (optionally) turn off the internal user management. In case of an emergency, you could re-enable the internal user management and log in with the admin user.

With this method, we can make sure that logging in via the internal system is completely blocked (if required, when the env variable is enabled).

I think it's great way to achieve the desired behavior. Maybe we would like to have a procedure for recovering a lost admin password as well.

Kind regards

[zepich]

Hi @gnieser

Thank you very much for your response.

I also would favor OIDC over SAML. Incidentally, supporting OIDC would allow to integrate with solutions such as Keycloak which in turn provide support for LDAP federation. It would provide a way to support LDAP indirectly (even if convoluted for someone would only have LDAP).

From my (limited) corporate sysadmin knowledge about MS infrastructures, ActiveDirectory should support OIDC since version 2016, so if somebody uses AD and wants to integrate it with mosparo, OIDC should work out of the box (like with Keycloak). All the modern enterprise solutions like MS Azure AD/Entra ID, Google Workspace, and so on should support OIDC anyway.

I think it's great way to achieve the desired behavior. Maybe we would like to have a procedure for recovering a lost admin password as well.

We could add a CLI command to reset the password of a user (could also help in a non-OIDC setup when you lost your password somehow, and the lost password functionality is not working). We may have to add a command to list the available users, too, since the owner may have forgotten the admin user's username.

I think we put OIDC integration on the task list for v1.5.

Kind regards,
zepich

[gnieser]

Hi @zepich

I'm not sure about how widely used is OIDC in Active Directory inside organizations. However I completely agree with you that OIDC is much more versatile.
Many thanks for taking this into consideration.

Kind regards