> > Yes, we removed the NoAuth module without replacing it. The project > determined that it was not worth continuing to keep it in the code, as the > value was limited and the end-goal of the module - transparently > authenticating users into Guacamole - was possible by several other more > secure means (SSO and parameter tokens, in particular). It's also true > that the header module is very simple - it accepts that a user has been > authenticated up-stream and relies on other modules to provide > configurations. This comes with a security caveat of its own - if you use > the header module it *must* be behind a reasonably secure front-end proxy > that won't allow someone to spoof the header that is then accepted by the > authentication module. There are warnings about this in the manual. > > I agree. On the other hand, even if we make FileAuthenticationProvider > work properly, JDBCAuthenticationProviderModule will still not work, as > it requires username/password for authentication against the database. So > if there is a need to stack JDBC/LDAP on the top of header authentication, > one needs to agree how to enable that. >
This is not accurate - I've used the Header module with the JDBC module repeatedly, and it works fine, even without a password being provided. The JDBC module will recognize users authenticated by any other module - LDAP, Header, CAS, OpenID, RADIUS - regardless of whether the module sets a password on the Credential object. The File handler does not currently behave that way. The LDAP module, when used to store connections, also relies on both the username and password to be available because it binds to the LDAP tree with the provided username and password. The JDBC module uses a fixed username and password to access the database, and accepts authentication from other modules matching via username only. -Nick >
