| adam responded: |
2011-12-09 14:20 |
Are there any exceptions or errors before this in the log? The NPE indicates that your server can't find the core module. Check the permissions in your deployment directory... LabKey needs permission to write to the file system to explode the modules. |
| |
| michael_stover responded: |
2011-12-12 09:42 |
Yes, tomcat didn't have permission to expand the modules. It's working now.
Now I have a bigger question. We have a need to use ldap authentication, but it's not via an email address. However, Labkey users appear to be intimately tied to using the email address as the principle. Lookups of users uses the email, all the authentication calls use the email and verify it as email.
To add a new principle field in place of email and make email a regular field of a User appears to be a major change to some core stuff. I'm looking for advice - have there been thoughts of disentangling login from email? I do not want a customized Labkey installation here that I have to always keep merging with the latest Labkey releases. I'd like to make a patch/modification that Labkey.com can be happy with. |
| |
| Matthew Bellew responded: |
2011-12-12 09:49 |
Does the user name in ldap match the user's email name in any way? Or are they completely unrelated? |
| |
| michael_stover responded: |
2011-12-12 10:08 |
The are completely unrelated, unfortunately. |
| |
| Matthew Bellew responded: |
2011-12-12 10:44 |
OK, we can talk about replacing the AuthenticationProvider with a subclass of LdapAuthenticationProvider etc. BUT, before going down that road...
The real problem here is that Robert@internal.ldap (ldap name) wants to log in as "Robert" and have LabKey send mail to "Bobby.Bobby@mail.com".
A sneaky operational way to do this is to have an SMTP server that is handles accepts mail using the LDAP name and forwards it to the correct email address. |
| |
| michael_stover responded: |
2011-12-12 10:51 |
Yes, that is exactly the real problem, and that problem lies in core code, not the authentication module. I'm not sure if I can get an operational solution - our Labkey is under University operations and is FISMA compliant and what I can get out of our IT is never certain. |
| |
| michael_stover responded: |
2011-12-12 10:54 |
Actually, if I can get an operational solution, I don't think I need any changes to Labkey. But, I'm having trouble getting answers around here...
I mostly wanted confirmation that this is indeed a thorny problem, and not one with a simple fix, and whether it's one you've all discussed before. |
| |
| adam responded: |
2011-12-12 11:01 |
Yes, it's non-trivial. We have discussed this (and related issues, like supporting multiple LDAP servers) with other clients and I believe I even wrote a spec for it, but in the end all the other clients have found operational workarounds that met their needs.
Adam |
| |