ShinyProxy use LDAP without manager account?

ShinyProxy
#1

I’m trying to wrap my head around how ShinyProxy uses LDAP. It looks like SP needs a manager account in order to bind with the LDAP server and ask the server who is a member of each group. And then compare that with the log in name. This seems odd since an LDAP login typically returns the groups to the client. Anyone know why this design decision was made? SP seems very thoughtfully engineered so I’m sure there’s a solid reason, I just don’t know it. I notice that JupyterLab logs in users without any manager account binding first.

One of the challenges presented by having to have a manager name and password in the yml is that I can’t check the yml into our internal version control repo as we have a policy of “no passwords to any accounts anywhere in version control.” Is there any way to abstract away the manager password? Maybe set it in an environment variable or some such?

If I opt out of any group level permissions is it possible to not have to use a manager account? I’ve read through all the docs and can’t see how to do this. FWIW I’m using Active Directory LDAP.

Another work around for me would be to have the manager dn and password just set to the user who’s logging in. All users can query our LDAP, but we don’t allow anonymous interrogation.

Thanks for your help!

#2

I don’t know the design reason but the sensitive configuration section in https://www.shinyproxy.io/security/ might help to protect the passwords.

#3

Ok, that’s pretty helpful. I had read that article, I thought. But I had totally missed that last bit on sensitive info.

1 Like
#4

so I’ve gone down the rabbit hole in trying to grok Spring LDAP just a little bit.

Looking at the Spring Security docs makes me think there’s some set method (at least at the Spring level) to allow Active Directory interrogation using only the user identity without the manager role. This is what I would ideally like to do. Anyone know if that’s exposed in ShinyProxy?

Emphasis below added by me to point out what I’m talking about.

12.3.5 Active Directory Authentication

Active Directory supports its own non-standard authentication options, and the normal usage pattern doesn’t fit too cleanly with the standard LdapAuthenticationProvider. Typically authentication is performed using the domain username (in the form user@domain), rather than using an LDAP distinguished name. To make this easier, Spring Security 3.1 has an authentication provider which is customized for a typical Active Directory setup.

ActiveDirectoryLdapAuthenticationProvider

Configuring ActiveDirectoryLdapAuthenticationProvider is quite straightforward. You just need to supply the domain name and an LDAP URL supplying the address of the server [20]. An example configuration would then look like this:

> <bean id="adAuthenticationProvider"
> class="org.springframework.security.ldap.authentication.ad.ActiveDirectoryLdapAuthenticationProvider">
>     <constructor-arg value="mydomain.com" />
>     <constructor-arg value="ldap://adserver.mydomain.com/" />
> </bean>
> }

Note that there is no need to specify a separate ContextSource in order to define the server location - the bean is completely self-contained. A user named “Sharon”, for example, would then be able to authenticate by entering either the username sharon or the full Active Directory userPrincipalName, namely sharon@mydomain.com. The user’s directory entry will then be located, and the attributes returned for possible use in customizing the created UserDetails object (a UserDetailsContextMapper can be injected for this purpose, as described above). All interaction with the directory takes place with the identity of the user themselves. There is no concept of a “manager” user.

By default, the user authorities are obtained from the memberOf attribute values of the user entry. The authorities allocated to the user can again be customized using a UserDetailsContextMapper. You can also inject a GrantedAuthoritiesMapper into the provider instance to control the authorities which end up in the Authentication object.