Feature #56429
openmgr/dashboard: Remote user authentication (e.g. via apache2)
0%
Description
Description¶
Authenticate users using a header from a trusted reverse proxy in front of the mgr dashboard.
This enables cluster administrators to instantly use many other ways to authenticate users, for example, using apache2 auth modules:
- LDAP
- OpenID Connect
- TLS client certs
- MFA
- External auth requests
This greatly eases integrating the Ceph Dashboard into existing environments, such as non-SAML SSO portals, specific MFA methods, or just simple authentication with LDAP.
Target persona¶
Context¶
A revers proxy, such as apache2, handles the actual authentication. It adds some configurable header to all requests to the mgr/dashboard, for example X-Remote-User: username. There are many authentication methods already available for e.g. apache2.
Many plugins also support passing extra headers, such as groups, which could be used to pass roles to mgr/dashboard, e.g. `X-Remote-Roles: block-manager, cephfs-manager`. This would allow for automatic user creation (or just keeping the current in-memory is possible), to greatly ease onboarding for new users, as all manual set up steps can be skipped.
mgr/dashboard would have to accept these headers from a trusted reverse proxy source. A setting could specified trusted IP ranges, e.g. ::1/128, 127.0.0.0/8. The header would only be accepted if the connection comes from a source in that range.
Design¶
Example: LDAP¶
┌───────────┐ ┌───────────┐ ┌───────────┐ ┌───────────────┐
│ │ │ │ │ │ │ │
│ Browser │ │ Apache2 │ │ LDAP │ │ mgr/dashboard │
│ │ │ │ │ │ │ │
└─────┬─────┘ └─────┬─────┘ └─────┬─────┘ └───────┬───────┘
│ │ │ │
┌┴┐ │ │ │
│ │ GET / │ │ │
│ ├────────────────────────┬┴┐ │ │
│ │ │ │ │ │
│ │ Unauthorized │ │ │ │
│ ├────────────────────────┴┬┘ │ │
│ │ │ │ │
│ ├─────┐ │ │ │
│ │ │request username │ │ │
│ │ │and password │ │ │
│ ├─────┘ │ │ │
│ │ │ │ │
│ │ GET / │ │ │
│ │ Authorization: ... │ │ │
│ ├────────────────────────┬┴┐ check user/pass │ │
│ │ │ ├──────────────────────►┌┴┐ │
│ │ │ │ │ │ │
│ │ │ │ OK: contains groups │ │ │
│ │ │ │◄──────────────────────┴┬┘ │
│ │ │ │ │ │
│ │ │ │ GET / │
│ │ │ │ X-Remote-User: john │
│ │ │ │ X-Remote-Role: block-manager, cephfs-manager │
│ │ │ ├────────────────────────────────────────────────►┌┴┐
│ │ │ │ │ ├──┐
│ │ │ │ │ │ │check source
│ │ │ │ │ │ │create user
│ │ │ │ OK │ │◄─┘
│ │ OK │ ├─────────────────────────────────────────────────┴┬┘
│ ├────────────────────────┴┬┘ │
└┬┘ │ │
│ │ │
Additional Info¶
Examples of other dashboards or web UI consoles providing the same functionality
- https://icinga.com/docs/icinga-web-2/latest/doc/05-Authentication/#external-authentication
- https://grafana.com/docs/grafana/next/setup-grafana/configure-security/configure-authentication/auth-proxy/
Files
Updated by Nizamudeen A almost 2 years ago
- Status changed from New to Need More Info
Updated by Jan Graichen almost 2 years ago
Hello, How can I help? What information do you need?
Updated by Jan Graichen over 1 year ago
Hello, please tell me what kind of additional information do you need. Are there any question regarding the feature?
Updated by Jan Graichen 9 months ago
How can I provide you with more details about this request? We would love to add our SSO to the Ceph dashboard too.
Updated by Jan Graichen 8 months ago
Hello, please tell me how I can help you with this request. What information are needed? Do you need any examples?
Updated by Richard Scott 5 months ago
This is an interesting proposal, though on your diagram i notice you would like the user to be created on the dashboard, even with the SAML integration, this is something that is not yet done as you will need to assign the new user to a role, this is something I would like to see implemented. So when a user login’s from SAML or indeed your proposal, it passes in member groups as well as the username, and the dashboard has a group to role mapping allowing the new user to be created and granted the necessary role.
Given the enterprise use of CEPH, i am amazed that the SSO of the dashboard is still so manual. I appreciate that the majority of CEPH maintenance tasks should be conducted via the CMD line, but in the growing toolsets of organisations, GUI’s are becoming more prominent for day-to-day tasks and this limitation makes no sense.
Updated by Jan Graichen 5 months ago
Hello Scott,
Yes, having users auto-created (or not at all because all user details are transmitted in every request via the headers) as well as X-Remote-Role would be nice, but I would already be thrilled just to have all the auth mechanisms from e.g. apache2 available to log in.
Given the enterprise use of CEPH, i am amazed that the SSO of the dashboard is still so manual. I appreciate that the majority of CEPH maintenance tasks should be conducted via the CMD line, but in the growing toolsets of organisations, GUI’s are becoming more prominent for day-to-day tasks and this limitation makes no sense.
Yes, I agree. We do not even configure much via the dashboard, but it is essential for debugging and monitoring for us, and as such, actually would need the same SSO as other dashboards and monitoring panels at least.
Delegating that to an already existing implementation (e.g. httpd) would enable a lot of integration right out the box.
Updated by Ernesto Puerta 5 months ago
Just a hint for the Dashboard team (Nizam, Avan) if they decide to implement this.
Currently the Dashboard supports an abstract auth class (AuthManager), which technically supports pluggable implementations (however it defaults to the LocalAuthenticator, and the SAML back-end is implemented outside this scheme, which breaks this nice design).
By refactoring that, we would simplify the development of new auth back-ends, and potentially encourage users to develop and contribute their own implementations (as they don't need to know much about Ceph Dashboard internals, but just regular Python skills).
class BaseAuthentication(ABC):
@abstractmethod
def __init__(self):
...
@abstractmethod
def get_user(self, username):
...
@abstractmethod
def authenticate(self, username, password):
...
@abstractmethod
def authorize(self, username, scope, permissions):
...
And then a concrete implementation:
class ApacheAuthentication(BaseAuthentication):
...
Updated by Jan Graichen 2 days ago
- File ceph-login.png ceph-login.png added
Hello Ernesto,
This interface seems to imply that a username and password is entered on a login page and passed to the auth backend?
This might work for local users, and maybe an LDAP/AD backend, but will be impossible for any SSO or external auth. One of the major points with SSO is to not enter clear text passwords into every application, but to delegate to an IdP. This IdP can further impose restrictions such as MFA, enforcing group memberships, permissions, etc.
With the proposed external authentication, Apache would pass a header with the user identifier to the Ceph dashboard. There is no password involved.
There would two ways to do that:
- The whole Ceph dashboard is proxied, authenticated, and authorized by Apache, and every request will carry an
X-Remote-Userheader. This could replace the session cookie for authentication and authorization. - Only a specific endpoint, for example
/auth/xyz, has authentication configured in Apache. Other dashboard paths would only be proxied. The Ceph dashboard would have to do regular authentication as now, e.g. check the session cookie. If a session isn't authenticated, the user could be redirected to a login page as it of now.The dashboard could be configured to support many auth methods, including local auth, and list them on the login page:
If only one SSO method is enabled, the user could be directly redirected to that, e.g.
/auth/oidcor/auth/ldap. Otherwise, the SSO buttons could redirect to different paths, such as/auth/oidcor/auth/ldap.Apache would handle authentication on these paths, and, after authentication, pass the request through to the Ceph dashboard with `X-Remote-User` and `X-Remote-Role` (and possible more, e.g. for email). Ceph could take this data, lookup or create the user, assign roles, and set up a session cookie. All other requests would take the session as now.
This would cover most cases:
- Any SSO method available
- MFA enforcement on the reverse proxy or IdP
- Multiple authentication paths
- Role assignment
- User onboarding
- Good UI
This wouldn't even be specific to Apache and Apache-compatible auth modules. Many other reverse proxies support similar things:
- Nginx (or any nginx based ingress controller on Kubernetes) with
auth_requestand, for example, vouch-proxy or nginx-ldap-auth - caddy-security
- dex
Updated by Jan Graichen 2 days ago
- File ceph-login-sso1.png ceph-login-sso1.png added
- File ceph-login-sso2.png ceph-login-sso2.png added
If SSO should be the primary login method, and the local login is only needed for emergencies (Network/IdP down), the login form could be hidden by default:
| A | B |
|---|---|
 |
 |
Another alternative could be only showing the login form when a parameter is given, e.g. /#/login?sso=0.