We hope you'll join us for our 4/23 webinar on using data tables to apply reference ranges and AE codes in OC4. For more information and to register, visit https://register.gotowebinar.com/register/2882170018956684555

[Developers] OpenClinica, Linux, JBoss, and LDAP

Hi Darin,
Thank you for your help with this, and your careful notes. We will
integrate this into our developing knowledge base shortly, in the
meantime I want to respond to your questions.
Questions:
>> >>1) Is OpenClinica role authorization managed through JAAS or is it
being
done internally? In my limitted testing, it seemed like users had to be
in LDAP for authentication, but their roles had to be in both LDAP and
PostgreSQL.
Roles are managed internally. Authentication normally takes place
through a tomcat security realm, however authorization is handled
internally.
>> >>2) Are there plans to extend the OpenClinica user maintenance
interface
so that LDAP users can be added, deleted, modified, and their group
access changed?
Adding a more fine-grained security mechanism is on the roadmap but is
not likely to be a near term addition to the software. We have evaluated
the NCICB's Common Security Module and it's User Provisioning Tool as
possible options, and even used it in other projects, but have postponed
integration for the time being.
>> >>3) Are there non-technical concerns about LDAP? If so, can they be
mitigated with business processes? Perhaps there are regulatory
limitations that make LDAP less desirable. For instance, OpenClinica
requires users to have eight character (or longer) passwords. This might
be hard to guarantee in an LDAP configuration, since different
departments may have authority for maintaining OpenClinica and LDAP.
We do not know of any specific concerns, however we have not done
extensive analysis yet. Many public and private clinical research
organizations already use commercial implementations of LDAP for
authentication for other information systems being used in regulated
systems. A centralized system for authentication - controlled by
adequate standard operating procedures - sounds like good clinical
practice to me.
Thanks,
Jaron
..................................
Jaron Sampson
Software Engineer, Akaza Research
One Kendall Square
Bldg. 400, 4th Fl
Cambridge, MA 02139
tel: 617.621.8585 x.15
fax: 617.621.0065
cell: 505-590-7553
-----Original Message-----
[mailto:[email protected]] On Behalf Of Darin S. Morley
Sent: Monday, December 11, 2006 10:39 PM
To: [email protected]
Subject: [Developers] OpenClinica, Linux, JBoss, and LDAP
I have successfully deployed OpenClinica 2.0 in JBoss 4.0.3 on Linux
(FedoraCore 6) and configured it to authenticate and authorize through
LDAP. If you're trying to use OpenClinica with Linux, JBoss, and/or
LDAP, the following may be helpful to you. If you are part of the Akaza
OpenClinica development team, I have a few questions at the end of this
that I'd like to get your feedback on.
If you have already followed the installation instructions for deploying
OpenClinica with Tomcat, then these instructions should get you up and
running in JBoss. If you're running on Windows, this should provide some
inspiration for running OpenClinica in JBoss and/or getting LDAP
authentication working on that hardware.
Environment:
Here are the versions of the various components I used:
Linux (FedoraCore 6)
PostgreSQL 8.1
Java 1.5
JBoss 4.0.3
OpenClinica 2.0
OpenLDAP 2.3.19
The JBoss installation directory was /opt/jboss and I used the default
server (/opt/jboss/server/default).
Setup:
1) Get all the packages and install them. Configure JBOSS_HOME,
JAVA_HOME, etc. Setup JBoss and LDAP.
2a) Setup PostgreSQL. I was able to use yum to install the Linux RPM
packages. You probably don't need all of these, but here's what I've got
installed:
postgresql.i386 8.1.4-1.1 installed
postgresql-contrib.i386 8.1.4-1.1 installed
postgresql-devel.i386 8.1.4-1.1 installed
postgresql-docs.i386 8.1.4-1.1 installed
postgresql-jdbc.i386 8.1.407-1jpp.4 installed
postgresql-libs.i386 8.1.4-1.1 installed
postgresql-pl.i386 8.1.4-1.1 installed
postgresql-python.i386 8.1.4-1.1 installed
postgresql-server.i386 8.1.4-1.1 installed
pgadmin3.i386 1.4.3-6.fc6 installed
2b) Update your pg_hba.conf. It's probably at:
/var/lib/pgsql/data/pg_hba.conf
By default PostgreSQL uses "ident" for authentication and you want it to
use "md5" instead. The end of the file should be changed to look
something like this:
# TYPE DATABASE USER CIDR-ADDRESS METHOD
# "local" is for Unix domain socket connections only
local all all md5
# IPv4 local connections:
host all all 127.0.0.1/32 md5
# IPv6 local connections:
host all all ::1/128 md5
host all all 168.192.1.1/32 md5
2c) Copy your PostgreSQL driver to JBoss's default server directory.
Put "postgresql-8.1-407.jdbc3.jar" in: /opt/jboss/server/default/lib
3) Configure the JBoss server.
You may want to change your log4j.xml file so that you get more logging.
I've included mine within the attached .zip file. Just copy it to
/opt/jboss/server/default/conf
Copy the "openclinica-login-config.xml" file from the attached .zip file
to /opt/jboss/server/default/conf.
This .xml file tells JBoss how to authenticate and authorize users when
they login. It specifies a JNDI name for the security realm
(OpenClinicaRealm) in the JBoss server. There are two s defined
in the file: 1) for PostgreSQL authentication (currently commented out)
and 2) for LDAP authentication. If you just want to use PostgreSQL
authentication and authorization, uncomment that and comment
out the LDAP .
The PostgreSQL defines the hash algorithm (MD5) and encoding
(hex) used to secure passwords in the database, the JNDI name of the
database where user details will be found, and the SQL query strings for
getting a user's password and roles, which are:
SELECT passwd FROM user_account WHERE user_name=?
SELECT role_name, 'Roles' FROM study_user_role WHERE user_name=?
Essentially, the LDAP does the same thing, just differently.
You may want to use the attached .ldif files to setup your LDAP schema.
You will also have to change the property to point to your LDAP server.
You may want to change the root LDAP entry to correspond to your
organization. The hashed passwords should be "12345678"; however, if you
have login problems you may need to generate those hashes on your LDAP
server.
*** I would strongly recommend that you get OpenClinica working in JBoss
using PostgreSQL for authentication and authorization BEFORE trying to
integrate with LDAP. You'll have to figure out for yourself how to setup
an LDAP server; however, the .ldif files should help. I'd also recommend
taking a look at:
http://docs.jboss.org/jbossas/jboss4guide/r1/html/ch8.chapter.html#d0e19
199
Finally, I've found Peter Harrison's _Linux Quick Fix Notebook_ to be
helpful getting LDAP configured on both servers and clients.
4) Deploy the service connections.
Put "postgres-ds.xml" and "openclinica-login-config-service.xml" in the
default server's deploy directory: /opt/jboss/server/default/deploy
postgres-ds.xml specifies the JNDI name (SQLPostgres), connection URL,
and credentials for connecting to the PostgreSQL server.
openclinica-login-config-service.xml just tells the JBoss server to go
look in conf/openclinica-login-config.xml (the file from step #3 above)
for the JAAS authentication details.
You could take the contents of "conf/openclinica-login-config.xml" and
copy them into "conf/login-config.xml". If you did that, you would NOT
need "openclinica- login-config-service.xml" or "conf/login-config.xml;
however, with those two files you can change your security configuration
without modifying the JBoss configuration file. Though it does come at
the cost of two additional configuration files, I think this is more
maintainable than trying to remember (or annotate) what's been changed
in JBoss's conf/login-config.xml. It's also the approach recommended in
the O'Reilly book: JBoss at Work.
5) Deploy the .war.
JBoss won't handle the OpenClinica.war file correctly, so extract the
contents into a directory named "OpenClinica.war"--the ".war" in the
directory name is important.
Move your new "OpenClinica.war" directory to the default server
(/opt/jboss/server/default/deploy).
You should now have: /opt/jboss/server/default/deploy/OpenClinica.war
6) Copy the .jar files
Copy the following .jar files to OpenClinica.war's lib directory
(/opt/jboss/server/default/deploy/OpenClinica.war/WEB_INF/lib):
commons-beanutils.jar
commons-collections-3.1.jar
commons-dbcp-1.2.1.jar
commons-digester.jar
cos.jar
jstl.jar
pgdev.306.jdbc3.jar
poi-2.5-final-20040302.jar
standard.jar
Most of these .jars come in OpenClinica's lib/deps directory. You'll
have to get the collections .jar from Apache. Also, some of these may
not be required--I didn't do extensive testing.
7) Copy the web.xml
Copy web.xml in the attached .zip to
/opt/jboss/server/default/deploy/OpenClinica.war/WEB-INF replacing the
one that's there.
I've made a couple of changes to the web.xml. First, I completed the
security roles section. There were several roles listed in that were not defined in tags.
Next, I added a for SQLPostgres. This tells JBoss that
the application container should manage database connection.
8) Copy the context.xml file
Copy context.xml in the attached .zip to
/opt/jboss/server/default/OpenClinica.war/WEB-INF
This is essentially the OpenClinica.xml file that is distributed with
the 2.0 release. The "propertiesDir" parameter has been changed to work
with the JBoss environment and the , , and
tags have been removed. Those three tags specify the
database, but we're doing that elsewhere now. The tag is not
working.
9) Copy the jboss-web.xml
Copy jboss-web.xml in the attached .zip to
/opt/jboss/server/default/OpenClinica.war/WEB-INF
This file binds the data source (java:/SQLPostgres) to the local
OpenClinica JNDI environment name (java:comp/env/SQLPostgres). It also
specifies the security realm (java:/jaas/OpenClinicaRealm) to use.
10) Run it
cd into /opt/jboss/bin and type run.sh
Fire up your web browser and go to: http://localhost:8080/OpenClinica
Login with root and 12345678 (or whatever you've changed the password
to)
That should do it!
Questions:
1) Is OpenClinica role authorization managed through JAAS or is it being
done internally? In my limitted testing, it seemed like users had to be
in LDAP for authentication, but their roles had to be in both LDAP and
PostgreSQL.
Roles are managed internally. Authentication normally takes place
through a tomcat security realm, however authorization is handled
internally.
2) Are there plans to extend the OpenClinica user maintenance interface
so that LDAP users can be added, deleted, modified, and their group
access changed?
Adding a more fine-grained security mechanism is on the roadmap but is
not likely to be an immediate addition to the software. We have
evaluated the NCICB's Common Security Module and it's User Provisioning
Tool as possible options, and even used it in other projects, but have
postponed integration for the time being.
3) Are there non-technical concerns about LDAP? If so, can they be
mitigated with business processes? Perhaps there are regulatory
limitations that make LDAP less desirable. For instance, OpenClinica
requires users to have eight character (or longer) passwords. This might
be hard to guarantee in an LDAP configuration, since different
departments may have authority for maintaining OpenClinica and LDAP.
As far as I know there would not be, however we have not done extensive
analysis yet. Many public and private clinical research organizations
already use commercial and open-source implementations of LDAP for
authentication for other information systems being used in regulated
systems. A centralized system for authentication - controlled by
adequate standard operating procedures - sounds like good clinical
practice to me.
--
Darin S. Morley
[email protected]
617.216.2320
ATT12575.txt
This discussion has been closed.