Standalone LDAP

What we will cover in the next few pages is how to configure WebSphere Application Server to use a standalone LDAP registry. The difference between a standalone LDAP repository and Federated Repositories is that the WAS administrative IDs and User ID’s are both referenced from the same LDAP server. If the LDAP service is down, then you will not be able to log into the WAS Console and application authentication will not work

As far as LDAP servers go, there are many products in the marketplace and your organization will have a solution from one of the big vendors, such as Microsoft’s ADAM, which is a light-weight implementation of Active Directory or IBM’s Tivoli Directory Server. These are just two very common commercial LDAP implementations. However, we are using the Open Source ApacheDS server which we created earlier in this guide.

Configuring the Standalone LDAP Server

We have already created a federated repository, which is defined as the current repository in Global Security as seen below in Security > Global Security.

• Click the Available realm definition list box and choose Standalone LDAP registry
  

• Click Configure
  

You will now the see the Global security > Standalone LDAP configuration page

The Primary administrative use is wasadmin, this user must exist in the LDAP directory in this configuration. We have also chosen LDAP Server to be Custom.

• Enter the LDAP server configuration values as required.
  

We can use the exact same details we used I the Federates repositories example, there are specified in the table below.

Next we have to complete the Security section located on the right-hand side of the page. In this section we have two fields to fill in. Bind distinguished name (DN) is the name which WebSphere will use to connect to LDAP for name searches. The Bind password is the password for this user. Fill in these fields with the values below, which we configured in Apache DS earlier.

Note: If no name is specified for the Bind distinguished name (DN), the application server binds anonymously. The LDAP server must be setup to allow anonymous binding.

Also, you can see at the top of the screen this message

We must go back to Global Security screen, and set Standalone as the current configuration when we are done with this page.

Testing the connection

Once you have filled out the details, click Apply to save, then click Test Connection

A default set of predefined filters exist, which are provided for each LDAP server that the WebSphere supports. You can modify these filters to fit your LDAP configuration.

It is also recommended that we configure Additional properties

In the Global security > Standalone LDAP registry > Advanced Lightweight Directory Access Protocol (LDAP) user registry settings page, change the User Filter and Group Member Id Map to fields as per the entries below.

• Change the User Filter field to the value below
  

The User filter field contains an LDAP string, which provides the LDAP search filter which is used to obtain information about users from an LDAP directory server.

Note: Since we hand crafted our LDAP directory, we know that our users all have inetOrgPerson for objectClass OR and account objectClass, both have uid as an attribute.

• Change the Group Member ID Map to the value in the table below
  

The Group Member ID Map field sets the syntax for user-to-group membership when LDAP is scanning for users belonging to which groups.

Note: Since we hand crafted our LDAP directory, we know that our groups have groupOfNames for objectClass, but could also have groupOfUniqueNames, so I have added an OR condition.

Note: We make these changes because ApacheDS uses slightly different object classes and the default ones are customized for IBM LDAP servers, hence the change. We have only changed the entries required, the other fields are fine as they are.

Note: Each LDAP type, will present pre-configured entries in this page. When in doubt, you will be best to resort to IBM products if you can, however, we have proven that we can use other Open source tooling such as Apache DS. However, it does take some knowledge and you can’t just accept defaults.

• Click Apply, and Save
  
• When back on the Global security > Standalone LDAP registry page click OK, then Save to complete the page and return back to Global security
  

• In the Available realm definitions section, select Standalone LDAP registry and click the Set as current button.
  

You will see the User Account repository will be updated as follows:

Click Apply

If your LDAP Bind username and password are correct and the LDAP server is running the Result will be a follows, as long as all the authentication is correct, and the Primary Administrative user ID can be located in the directory.

Click Save, then restart the server.

Next time we log into the server we will be asked for a username and password.

Note: You will also be prompted for a username and password to stop a running WAS instance when Global Security is enabled.

Congratulations, you have now learned the core fundamentals of securing WAS using a standalone LDAP server for both administrative users and application users.

Review of Security.xml

I think this is a good time to quickly review the security.xml settings for this Standalone LDAP configuration. The security.xml can be found in:

For example:

Looking at the userRegistries stanza contained within security.xml you will see the LDAP Filter settings we have specified. Below is a sample from my configuration.

You should see within the searchFilter section the user filter we configured earlier, for example: userFilter==”(&(uid=%v)(|(objectclass=inetOrgPerson)(objectclass=account)))” This file is very useful, as you can edit it when things go wrong with your WebSphere administrative logins.

You now have configured WebSphere to use an LDAP registry.

To learn more about the courses available from The Middleware Shop, please go to http://www.themiddlewareshop.com/products to see a full list of the current courses available.

Consulting

If you or your organization require support in architecture, performance tuning, automation or simply advice, then please contact me via my support site and request a conversation, where we can discuss your requirement.

About Steve

Steve is a seasoned passionate technology professional, strategist and leader.

An expert in technical communications, and adept in almost all forms of Internet and mobile related technology, Steve has time and time again proven his tenacity to improve systems around him and deliver.

Steve has worn many hats during his career such as Chief Technical Officer, Founding Member of several business ventures, Programmer, Systems Administrator, Architect, Blogger and Published Author to name a few.

Due to 20 years Industry experience in Middleware, Programming, Networks and Internet Technologies, He combines systems knowledge with efficient working methods and inter personal skills required to build effective relationship with clients and colleagues alike. Exceeding typical expectations in any role undertaken, Steve is certain to become a valuable asset within any organisation He joins.

Key Skills

• Leadership (Team, Project, Business, People).

• Architecture (Solutions, Information, Technical, Applications).

Simply, I help you deal with CANETI: Constant And Never Ending Technological Innovation

Specific IBM WebSphere skills:

WebSphere Application Server (WAS Base, WAS ND & Liberty Profile & Liberty Runtime)

• Automation
• Security, SSL
• Dev Ops
• Architecture
• Performance Tuning

Middleware Integration Skills:

• .NET programming, and Architecture
• Java Programming, and Architecture
• SOA, SOAP, and XML messaging
• JBoss Fuse, WMQ, IIB, Mule

Integration Skills:

• SOA
• Process Improvement
• ICD’s
• Messaging Architecture
• Governance

General Digital Architecture & Governance

• Lightweight Architectures
• Digital Strategy, platform stacks for example IAAS, PAAS, SAAS
• PCI DSS

Industry Qualifications & Recognition

• TOGAF 9.1
• IBM Champion 2013