IJC password setup?

Dear IJC experts,





Another question. I have set up a number of users on a Mysql backed database with ROLE_USER privileges using the IJC database security. I can see the password hash in IJC_SECURITY_USERS.





Is it possible to set a default password for these users without doing it manually through the IJC gui? I have tried copying the password hash from one user to another but that doesn't seem to work.





David

David,





Yes, the passwords and encoded with a salt which means that 2 identical passwords for different users and encrypted differently.





The security configuration is configurable, and it should be possible to remove the salt (with a small reduction in the level of security). If you want to do this then I would need to remind myself how to do it, but it should be a simple configuration change. But you would need to set up all passwords again, which may be a problem.





Also, it would be nice to know more about this need. Maybe we can make future changes in IJC to make this easier. You are wanting to add multiple users at once, and set them all up with a default password and the same set of roles? So just wanting to avoid having to go through adding each user individually?





Tim

Hi Tim,





Yes, you have essentially grasped the problem.





I am trying to set up a number of databases which I would like the general users to be able to use on a read-only basis. I would be happy for them to all use a single anonymous account - but this causes problems with multiple users using the same database at the same time. Therefore I am setting up individual IJC and Mysql accounts for all of my users.





My lab is principally a linux-based lab, but I would like Windows and OSX users to be able to use the databases. I have my usernames in /etc/passwd and I am able to write a script to add these directly to the mysql database. However, this leaves me with the default password problem. I am trying to avoid resetting them manually (although it is not really a very big job).





LDAP is probably the best solution to all of this, but I confess to finding all of the LDAP documentation opaque.





The other difficulty I am having is with the general complexity of distributing a database configuration to multiple users (across different platforms!). It would nice to have a single file (rather than a directory structure) that would provide all the pre-configured information to connect to a remote database. It would be nice if this file could be placed in a shared directory and 'double-clicked' to open the appropriate database.





Regards





David

I think LDAP is your best solution. It would avoid the need to duplicate security information. We can help you get his configured (either here or offline).





For deployment we have some big improvements coming in IJC 2.3 which will allow centralised configuration of projects and connections. Combined with the Java Web Start installation all a user will need to do is click on the launcher in a web page and IJC will start with everything pre-configured (projects, connections, licenses, forms, lists. queries...).





Tim

Hi Tim,





I have bitten the bullet set up an LDAP server and imported my user/password data. I can use the LDAP server to log into a Suse 10.3 box so I think it is working OK.





However, I am not able to log into IJC using LDAP. I get:





org.acegisecurity.BadCredentialsException: Bad credentials; nested exception is javax.naming.AuthenticationException: [LDAP: error code 49 - Invalid Credentials]


Caused by: javax.naming.AuthenticationException: [LDAP: error code 49 - Invalid Credentials]





when I try to log in as myself 'david'.





Below are some of the details.





Do you have any suggestions?





Cheers





David





Slapd.conf


---------





loglevel -1


database bdb


suffix "o=comp.chem"


checkpoint 1024 5


cachesize 10000


rootdn "cn=Administrator,o=comp.chem"


# Cleartext passwords, especially for the rootdn, should


# be avoid. See slappasswd(8) and slapd.conf(5) for details.


# Use of strong authentication encouraged.


rootpw "{SSHA}rKJNbXr76CHF8JwgzGjUHKjjwM2xVlWTYvR4"


# The database directory MUST exist prior to running slapd AND


# should only be accessible by the slapd and slap tools.


# Mode 700 recommended.


directory /var/lib/ldap


# Indices to maintain


index objectClass eq








IJC connection


-------------


<!-- Specifies which username/password is needed to login. LDAP must use:





IJC_USERNAME_PASSWORD Use a different username/password from the one used to


connect to the IJC database. This allows a single database


account to be used, but still have different login names


for each user which is a requirement for multi-user acccess


-->


<bean id="authenticationPolicy" class="java.lang.String">


<constructor-arg value="IJC_USERNAME_PASSWORD"/>


</bean>





<!-- defines that the password is not encoded -->


<bean id="passwordEncoder" class="org.acegisecurity.providers.encoding.PlaintextPasswordEncoder">


</bean>





<!-- as we are not encodeing password we don't need a salt -->


<bean id="saltSource" class="com.im.df.impl.db.persist.NullSaltSource">


</bean>





<!--


Add extra accounts that you want to use in addition to those from LDAP


e.g. to provide special admin accounts etc.


Make sure you have at least one account that has full access rights





Syntax: each user on a separate line (at least one role must be defined)


username=password,[enabled|disabled],ROLE1[,ROLE2...]


-->


<bean id="extraUserDetailsService"


class="org.acegisecurity.userdetails.memory.InMemoryDaoImpl">


<property name="userMap">


<value>


admin=admin,ROLE_USER,ROLE_EDIT_DATA,ROLE_EDIT_SCHEMA,ROLE_ADMIN


</value>


</property>


</bean>





<bean id="extraAuthenticationProvider"


class="org.acegisecurity.providers.dao.DaoAuthenticationProvider">


<property name="userDetailsService" ref="extraUserDetailsService"/>


</bean>








<bean id="initialDirContextFactory"


class="org.acegisecurity.ldap.DefaultInitialDirContextFactory">


<constructor-arg value="ldap://192.168.2.131:389/o=comp.chem"/>


<property name="managerDn"><value>cn=administrator,o=comp.chem</value></property>


<property name="managerPassword"><value>{SSHA}JNbX6CHF8JwgzGjUHKjjwM2zVlWTYvR4</value></property>


</bean>





<!-- userSearch specifies how the user's DN is found in the LDAP server.


-->


<bean id="userSearch"


class="org.acegisecurity.ldap.search.FilterBasedLdapUserSearch">


<constructor-arg index="0">


<value>ou=People</value>


</constructor-arg>


<constructor-arg index="1">


<value>(uid={0})</value>


</constructor-arg>


<constructor-arg index="2">


<ref local="initialDirContextFactory" />


</constructor-arg>


<property name="searchSubtree">


<value>true</value>


</property>


</bean>








LDAP logfile


------------





Mar 14 15:48:21 alpha slapd[22714]: daemon: read active on 16


Mar 14 15:48:21 alpha slapd[22714]: connection_get(16)


Mar 14 15:48:21 alpha slapd[22714]: connection_get(16): got connid=6


Mar 14 15:48:21 alpha slapd[22714]: connection_read(16): checking for input on id=6


Mar 14 15:48:21 alpha slapd[22714]: daemon: epoll: listen=7 active_threads=0 tvp=zero


Mar 14 15:48:21 alpha slapd[22714]: daemon: epoll: listen=8 active_threads=0 tvp=zero


Mar 14 15:48:21 alpha slapd[22714]: do_bind


Mar 14 15:48:21 alpha slapd[22714]: >>> dnPrettyNormal: <cn=administrator,o=comp.chem>


Mar 14 15:48:21 alpha slapd[22714]: <<< dnPrettyNormal: <cn=administrator,o=comp.chem>, <cn=administrator,o=comp.chem>


Mar 14 15:48:21 alpha slapd[22714]: do_bind: version=3 dn="cn=administrator,o=comp.chem" method=128


Mar 14 15:48:21 alpha slapd[22714]: conn=6 op=0 BIND dn="cn=administrator,o=comp.chem" method=128


Mar 14 15:48:21 alpha slapd[22714]: ==> bdb_bind: dn: cn=administrator,o=comp.chem


Mar 14 15:48:21 alpha slapd[22714]: bdb_dn2entry("cn=administrator,o=comp.chem")


Mar 14 15:48:21 alpha slapd[22714]: => bdb_dn2id("cn=administrator,o=comp.chem")


Mar 14 15:48:21 alpha slapd[22714]: <= bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30989)


Mar 14 15:48:21 alpha slapd[22714]: send_ldap_result: conn=6 op=0 p=3


Mar 14 15:48:21 alpha slapd[22714]: send_ldap_result: err=49 matched="" text=""


Mar 14 15:48:21 alpha slapd[22714]: send_ldap_response: msgid=1 tag=97 err=49


Mar 14 15:48:21 alpha slapd[22714]: conn=6 op=0 RESULT tag=97 err=49 text=


Mar 14 15:48:21 alpha slapd[22714]: daemon: activity on 1 descriptor


Mar 14 15:48:21 alpha slapd[22714]: daemon: activity on:


Mar 14 15:48:21 alpha slapd[22714]: 16r

I will try to reproduce this environment and test it.





Tim

I think the basic problem is related to the password encryption.


In slapd.conf you specify:


rootpw "{SSHA}rKJNbXr76CHF8JwgzGjUHKjjwM2xVlWTYvR4"





This stores the password in encryped form.


When you authenticate you need to provide the password in its original form.





You can easily test this:





1. Create encrypted password:





[root@wrkstn1 etc]# slappasswd


New password:


Re-enter new password:


{SSHA}KpVNpAPH158ei9iqLefyQe/x43ctQf4R





2. Paste the encrypted password into slapd.conf and restart slapd:


rootpw {SSHA}KpVNpAPH158ei9iqLefyQe/x43ctQf4R





3. Test using command line ldapsearch





[root@wrkstn1 ~]$ ldapsearch -H ldap://localhost -D cn=Manager,dc=example,dc=com -W -b dc=example,dc=com -x


Enter LDAP Password:


<enter password>





You should see some results which verfies that your credential are correct.








4. Configure IJC.





<bean id="initialDirContextFactory"


class="org.acegisecurity.ldap.DefaultInitialDirContextFactory">


<constructor-arg value="ldap://localhost:389/dc=example,dc=com"/>


<property name="managerDn"><value>cn=Manager,dc=example,dc=com</value></property>


<property name="managerPassword"><value>secret</value></property>


</bean>





where secret is the pasword you chose.








Then hopefull this should work.





Tim

Hi Tim,





Aha! That is the problem. I am sure I tried every other possible combination. Of course, IJC can't regenerate a password from a hash - unless it knows something that other people don't.





I am not that happy about the idea of storing the LDAP manager password as a cleartext though. Does IJC need the manager password or can we potentially use a read-only LDAP login?





Thanks for the help.





David

Yes, you should be able to use a different account. As long as the account can query the user information in the directory it should work. It can be a non-privileged account with read-only access.





The LDAP setup is highly configurable. There would probably be a number of ways that this could be configured.





Tim