Tag Archives: OpenDJ

LDAP secondary group memberships with OpenDJ and Ubuntu 12.04

As a follow-up to this post, let’s now configure OpenDJ and Ubuntu to use LDAP for assigning secondary groups to user accounts.

This is a quick guide intended for testing only, and we are assuming the setup here has been followed. One change is that we are using Ubuntu 12.04 x86 as the client system.

 

First, let’s create a new test group in OpenDJ. We assign it the structural object class namedObject, and the auxiliary object class posixGroup. The group GID number is 130, and we add a memberUid entry, with the UID of an existing LDAP account:

Adding a new group in OpenDJ

Now, on our test Ubuntu 12.04 x86 client, we modify /etc/ldap.conf, adding the following entry:

nss_schema rfc2307bis

This enables rfc2307bis LDAP schema support for PAM (OpenDJ uses the rfc2307bis schema by default).

 

Next, again in /etc/ldap.conf we uncomment the nss_base_group setting in the section headed with the comment “RFC2307bis naming contexts”, and give it the value as shown:

nss_base_group ou=Groups,dc=example,dc=co,dc=nz

Obviously you would modify the domain components to suit.

 

We now restart the nscd service, and verify that the secondary group information can be retrieved for an LDAP user:

itadmin@turrican2:/etc$ sudo /etc/init.d/nscd restart
 * Restarting Name Service Cache Daemon nscd                             [ OK ] 
itadmin@turrican2:/etc$ 
itadmin@turrican2:/etc$ id davek
uid=1004(davek) gid=50(staff) groups=130(testgroup),50(staff)

We can see that the secondary group testgroup with the GID number of 130 is successfully retrieved from LDAP for this user.

Advertisements

Fun with JSPWiki skins

I really love JSPWiki. It’s super-easy to install, doesn’t require any additional configuration for a back-end database, the native interface is quick and fast to use, and it just runs and runs. Great software.

If there’s one area however where it’s lacking, it’s in a nice selection of bundled good-looking themes. But hey, it’s free and open source software, so one is really in no position to complain – and new skins can be created using entirely standard and familiar HTML and CSS.

It’s worth noting the difference between JSPWiki templates and skins – described at http://www.jspwiki.org/wiki/JSPWikiSkinDesign

After a bit of tinkering with CSS and the bundled “Smart” theme, I came up with this:

JSPWiki - modified "Smart" theme

Not the stuff of professional web design, but a definite improvement on the default theme, in my humble opinion.

Enable LDAP authentication with Nuxeo

Authenticating Nuxeo users against an LDAP directory is straightforward but for a bug which I encountered.

The instructions for enabling LDAP authentication are here: http://doc.nuxeo.com/display/ADMINDOC/Using+a+LDAP+directory. I am using Tomcat in my case, with OpenDJ as the LDAP server.

The bug I encountered is here: https://jira.nuxeo.com/browse/NXP-6574

And, the workaround I had to implement to get LDAP authentication up and running is detailed here: http://answers.nuxeo.com/questions/701/ad-ldap-connection-issues.

With this in place, LDAP authentication works as expected.

Enable secure LDAP container based authentication with JSPWiki

A quick follow up on my post here. I will describe below the steps needed to enable secure LDAP authentication (both LDAPS and HTTPS). This is not intended for production use, obviously.

I’m using the same platform and environment described here, and also using this as the starting point for the following.

 

Verify that the LDAPS connection handler is enabled in OpenDJ

This can be checked using the OpenDJ Control Panel GUI, and modified if necessary using the CLI dsconfig utility.

 

Switch to the secure LDAP port in the GlassFish JSPWiki security realm

Make sure you are using the ldaps:// URL prefix, and specify the secure port number (1636 in this example):

Enable LDAPS in GlassFish

 

Enable security for the relevant GlassFish HTTP network listener port

Our JSPWiki application is listening over port 8080, configured in GlassFish under http-listener-1. Enable security for this port:

Enabling security for the GlassFish http-listener-1 network listener

 

Enable HTTPS connections to JSPWiki

This is performed via modification of the JSPWiki web.xml file. In a default state, the web.xml file contains the following entries which enable the use of SSL connections:

<user-data-constraint>
           <transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>

Ensure these exist in web.xml under the container managed authentication section.

 

Export the OpenDJ SSL certificate and import it into the JSPWiki JKS keystore

The keytool CLI utility is used for this step.

First, we export the OpenDJ certificate (which has a default alias of server-cert) to a file:

dave@mymachine:~/OpenDJ/config$ pfexec keytool -export -alias "server-cert" -keystore ~/OpenDJ/config/keystore -file /tmp/server-cert.cer
Enter keystore password:  

Certificate stored in file </tmp/server-cert.cer>

Next, we import the certificate file into the keystore of the GlassFish domain running our instance of JSPWiki, which in this example is at /opt/glassfishv3/glassfish/domains/domain1/config/cacerts.jks:

dave@mymachine:~/OpenDJ/config$ pfexec keytool -import -v -trustcacerts -alias "server-cert" -keystore /opt/glassfishv3/glassfish/domains/domain1/config/cacerts.jks -file /tmp/server-cert.cer 
Enter keystore password:  
Owner: CN=mymachine, O=OpenDS Self-Signed Certificate
Issuer: CN=mymachine, O=OpenDS Self-Signed Certificate
Serial number: 
Valid from: 
Certificate fingerprints:
	 MD5:  
	 SHA1: 
	 Signature algorithm name: SHA1withRSA
	 Version: 3
Trust this certificate? [no]:  yes
Certificate was added to keystore
[Storing /opt/glassfishv3/glassfish/domains/domain1/config/cacerts.jks]

 

Modify the jspwiki.baseURL value

This is required as the URL prefix will have changed from http:// to https://. This modification is performed in the jspwiki.properties file.

Assuming my existing jspwiki.baseURL value is:

http://192.168.1.1:8080/ITProjects/

This would need to be changed to:

https://192.168.1.1:8080/ITProjects/

 

Restart the GlassFish domain, and test LDAP logins…

…and if you don’t observe secure logins working as they should, leave a comment.

Container based authentication with JSPWiki, GlassFish and OpenDJ

In this blog entry I am going to describe configuring JSPWiki to use container based authentication to authenticate LDAP users existing in an OpenDJ directory. I am using GlassFish as my web application container, so this can be considered an alternative solution to using Tomcat, for example as described here.

 

I am running JSPWiki version 2.8.3, deployed in GlassFish Open Source Edition 3.1.1 (build 12) on OpenIndiana oi_151 x86. OpenDJ is version 2.4.4, and I am using Java 6 update 26.

I am assuming prior basic familiarity with installing, configuring, and managing GlassFish and OpenDJ. Our starting point will be a freshly deployed instance of JSPWiki, for which the initial first-run setup procedure has taken place and without any configuration to the JSPWiki configuration files.

This is an insecure setup intended for testing purposes.

 

Create user and admin groups for JSPWiki in OpenDJ

I have created the Groups OU under my Base DN, and within it created the groups wiki-admin and wiki-users.

Members of the wiki-admin group will be authorized with full permissions in JSPWiki once authenticated. Members of the wiki-users group however will have a lesser set of permissions, suitable for regular day-to-day use of the wiki. You can use LDIF commands if you wish to create the directory entries, however, I just use OpenDJ’s super-easy GUI to do the work. For example:

JSPWiki groups in OpenDJ

 

Create an LDAP security realm in GlassFish

This can be performed in the GlassFish admin BUI. Note that we perform this step under the Configurations -> server-config node in the BUI (not the Configurations -> default-config node):

GlassFish server-config node

I have created the LDAP realm JSPWikiUsers with the following settings:

GlassFish LDAP security realm settings

Some observations on the above can be noted here:

  • The search-bind-dn and search-bind-password properties may be optional for your OpenDJ installation: they are required in my case because I have disabled anonymous access to my OpenDJ server
  • The port used for access to your OpenDJ server may not necessarily be 1389 – change this as necessary.

 

Change the JACC provider from default to simple

I found that if this step is not performed, LDAP group lookup from GlassFish to OpenDJ will plain just not work.

Navigate to the Configurations -> server-config -> Security node of the GlassFish admin BUI and make the setting as illustrated:

GlassFish - set the JACC provider to Simple

 

This should be all the configuration needed in GlassFish using the admin BUI, so we can now proceed to making the required modifications to the following JSPWiki deployment descriptor and policy files:

  • web.xml
  • jspwiki.policy
  • glassfish-web.xml

 

In the following steps, we are assuming that JSPWiki has been deployed to the domain1 domain, and the path to the deployment descriptor and policy configuration files is:

/opt/glassfishv3/glassfish/domains/domain1/applications/JSPWiki/WEB-INF

 

(Also, in my case no changes needed to be made at all to the jspwiki.properties file.)

 

Enable container based authentication in the web.xml file

In the web.xml file (in its unmodified state in JSPWiki v2.8.3), look for the section near the end of the file which begins with the following comment:

<!--  REMOVE ME TO ENABLE CONTAINER-MANAGED AUTH

 

Simply uncomment the section and replace it with the following:

<security-constraint>
       <web-resource-collection>
           <web-resource-name>Administrative Area</web-resource-name>
           <url-pattern>/Delete.jsp</url-pattern>
       </web-resource-collection>
       <auth-constraint>
           <role-name>wiki-admin</role-name>
       </auth-constraint>
   </security-constraint>
      
   <security-constraint>
       <web-resource-collection>
           <web-resource-name>Authenticated area</web-resource-name>
           <url-pattern>/Edit.jsp</url-pattern>
           <url-pattern>/Comment.jsp</url-pattern>
           <url-pattern>/Login.jsp</url-pattern>
           <url-pattern>/NewGroup.jsp</url-pattern>
           <url-pattern>/Rename.jsp</url-pattern>
           <url-pattern>/Upload.jsp</url-pattern>
           <http-method>DELETE</http-method>
           <http-method>GET</http-method>
           <http-method>HEAD</http-method>
           <http-method>POST</http-method>
           <http-method>PUT</http-method>
       </web-resource-collection>

       <web-resource-collection>
           <web-resource-name>Read-only Area</web-resource-name>
           <url-pattern>/attach</url-pattern>
           <http-method>DELETE</http-method>
           <http-method>POST</http-method>
           <http-method>PUT</http-method>
       </web-resource-collection>

       <auth-constraint>
           <role-name>wiki-admin</role-name>
           <role-name>wiki-users</role-name>
       </auth-constraint>
   </security-constraint>

   <login-config>
       <auth-method>FORM</auth-method>
       <realm-name>JSPWikiUsers</realm-name>
       <form-login-config>
           <form-login-page>/LoginForm.jsp</form-login-page>
           <form-error-page>/LoginForm.jsp</form-error-page>
       </form-login-config>
   </login-config>

   <security-role>
       <description>
           This logical role includes all authenticated users
       </description>
       <role-name>wiki-users</role-name>
   </security-role>

   <security-role>
       <description>
           This logical role includes all administrative users
       </description>
       <role-name>wiki-admin</role-name>
   </security-role>

 

Modify the jspwiki.policy file

This will allow users in the wiki-admin LDAP group to be granted full permissions upon authenticating to JSPWiki.

Look for the following section at the end of the jspwiki.policy file (in its unmodified state in a JSPWiki v2.8.3 installation):

// Administrators (principals or roles possessing AllPermission)
// are allowed to delete any page, and can edit, rename and delete
// groups. You should match the permission target (here, 'JSPWiki')
// with the value of the 'jspwiki.applicationName' property in
// jspwiki.properties. Two administative groups are set up below:
// the wiki group "Admin" (stored by default in wiki page GroupAdmin)
// and the container role "Admin" (managed by the web container).

grant principal com.ecyrd.jspwiki.auth.GroupPrincipal "Admin" {
    permission com.ecyrd.jspwiki.auth.permissions.AllPermission "*";
};
grant principal com.ecyrd.jspwiki.auth.authorize.Role "Admin" {
    permission com.ecyrd.jspwiki.auth.permissions.AllPermission "*";
};

 

And modify it to read:

// Administrators (principals or roles possessing AllPermission)
// are allowed to delete any page, and can edit, rename and delete
// groups. You should match the permission target (here, 'JSPWiki')
// with the value of the 'jspwiki.applicationName' property in
// jspwiki.properties. Two administative groups are set up below:
// the wiki group "Admin" (stored by default in wiki page GroupAdmin)
// and the container role "Admin" (managed by the web container).

// grant principal com.ecyrd.jspwiki.auth.GroupPrincipal "Admin" {
//     permission com.ecyrd.jspwiki.auth.permissions.AllPermission "*";
// };
// grant principal com.ecyrd.jspwiki.auth.authorize.Role "Admin" {
//     permission com.ecyrd.jspwiki.auth.permissions.AllPermission "*";
// };
grant principal com.ecyrd.jspwiki.auth.authorize.Role "wiki-admin" {
    permission com.ecyrd.jspwiki.auth.permissions.AllPermission "*";
};

 

Create the glassfish-web.xml file

The primary purpose of this file will be to map the security roles we defined in the web.xml file to the JSPWiki groups we created in OpenDJ. The file should be created at:

/opt/glassfishv3/glassfish/domains/domain1/applications/JSPWiki/WEB-INF

 

The glassfish-web.xml file should contain the following only:

<!DOCTYPE glassfish-web-app PUBLIC "-//GlassFish.org//DTD GlassFish Application Server 3.1 Servlet 3.0//EN" "http://glassfish.org/dtds/glassfish-web-app_3_0-1.dtd">

<glassfish-web-app>
 <security-role-mapping>
        <role-name>wiki-admin</role-name>
        <group-name>wiki-admin</group-name>
 </security-role-mapping>
 <security-role-mapping>
        <role-name>wiki-users</role-name>
        <group-name>wiki-users</group-name>
 </security-role-mapping>
</glassfish-web-app>

 

Restart the GlassFish domain, and test LDAP logins to JSPWiki

First, restart the domain either using the asadmin utility or the GlassFish admin BUI. Then test LDAP logins to JSPWiki.

In my case, we can observe that logging in as a user that is a member of the wiki-admin group in OpenDJ, I do indeed have full permissions in JSPWiki:

JSPWiki LDAP admin user

Whereas logging in as a user that is a member of the wiki-users group in OpenDJ, I am restricted from certain destructive actions:

JSPWiki LDAP standard user