Quickly setup OpenLDAP on Oracle Linux 5

Sometimes you need an LDAP directory for testing but don't need a heavy duty directory like OID, DSEE or OUD. In those cases OpenLDAP suits your needs and it's a quick and easy install.

Last night someone pinged me and asked for help doing just that. I set it up, took some notes and thought I'd share them here.

[root@dogwoodvm ~]# yum install openldap-servers
Loaded plugins: rhnplugin, security
This system is not registered with ULN.
ULN support will be disabled.
Setting up Install Process
Resolving Dependencies
--> Running transaction check

...etc...

Installed:
  openldap-servers.x86_64 0:2.3.43-12.el5_5.3                                                                                                          

Dependency Installed:
  libtool-ltdl.x86_64 0:1.5.22-7.el5_4                                                                                                                 

Complete!

You can find the config files in /etc/openldap

[root@dogwoodvm ~]# cd /etc/openldap/
[root@dogwoodvm openldap]# ls
cacerts  DB_CONFIG.example  ldap.conf  schema  slapd.conf

Make a backup of slapd.conf and then edit the original.
Duplicate these lines and then comment out one of the pair:

#suffix         "dc=my-domain,dc=com"
#rootdn         "cn=Manager,dc=my-domain,dc=com"

Then edit the duplicates you made to reflect your environment. I want the root of my directory to be "dc=oracleateam,dc=com" and the super user account needs to be inside that root. So my config looks like:

suffix          "dc=oracleateam,dc=com"
rootdn          "cn=Manager,dc=oracleateam,dc=com"

You will also need to pick and set the password for that account. A few lines later you'll see this:

# Cleartext passwords, especially for the rootdn, should
# be avoided.  See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
# rootpw                secret
# rootpw                {crypt}ijFYNcSNctBYg

By default the OpenLDAP RPMs ship with the password disabled. In order to allow the administrator to connect and manage the directory contents you need to add a line like so:

rootpw          ABcd1234

If this were a real environment you wouldn't want to put the password in the clear there, but since this is just for testing it's fine. If you want to be more secure even for testing use the slappasswd account to hash the password before pasting it into the slapd.conf file.

Side note: I always use the password ABcd1234 for my test environments - it's 8 characters long, contains uppercase letters, lowercase letters and numbers. It's a weak password but it meets virtually every default password policy I've encountered.

Save the file and then start the OpenLDAP server:

[root@dogwoodvm openldap]# service ldap start
Checking configuration files for slapd:  config file testing succeeded
                                                           [  OK  ]
Starting slapd:                                            [  OK  ]

If you want the OpenLDAP server to start automatically on boot use chkconfig to do that:

[root@dogwoodvm openldap]# chkconfig --level 35 ldap on
[root@dogwoodvm openldap]# chkconfig --list ldap
ldap                0:off     1:off     2:off     3:on     4:off     5:on     6:off

Once you've done that you need to actually create the directory root objects inside the directory. To do that you can use a graphical LDAP editor or just use the command line ldapmodify tool.

[root@dogwoodvm openldap]# yum install openldap-clients
Loaded plugins: rhnplugin, security
This system is not registered with ULN.
ULN support will be disabled.
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package openldap-clients.x86_64 0:2.3.43-12.el5_5.3 set to be updated
--> Finished Dependency Resolution
... etc ...
Installed:
  openldap-clients.x86_64 0:2.3.43-12.el5_5.3                                                                                                          

Complete!

Then use ldapmodify to create the entries.
Run the command:

[root@dogwoodvm openldap]# ldapmodify -D 'cn=Manager,dc=oracleateam,dc=com' -w ABcd1234 -x

Then paste the entry in

dn: dc=oracleateam,dc=com
changetype: add
objectClass: dcObject
objectClass: organizationalUnit
dc: oracleateam
ou: rootobject
description: LDAP Admin

and hit return to leave a blank line. The command should come back and tell you that it's adding an entry, like so:

adding new entry "dc=oracleateam,dc=com"

Then create the Organizational Units (ou) for People and Groups if you want them by pasting these in and hitting return after:

dn: ou=People, dc=oracleateam,dc=com
changetype: add
objectClass: organizationalUnit
ou: People
description: Users

dn: ou=Groups, dc=oracleateam,dc=com
changetype: add
objectClass: organizationalUnit
ou: Groups
description: Groups

Hit ctrl-d to exit and you're done.

OIM 11g Event Handler example

This post shows an example of a post process event handler in OIM. The example is simple and it shows how the user profile can be updated from the event handler based on the information that is provided by OIM to the event handler.

Use case description: a UDF is created in the user profile and it will hold the user's 'Director'. To simplify the use case, the 'Director' will be the 'manager's manager'. In other words, the UDF will be populated with the information from two levels up in the management chain, the value to be used is the director's login.

The first step is to create the UDF that will hold the data. An authorization policy is also needed, otherwise it will not be possible to update the UDF using the APIs. All the steps below must be done in OIM logged as system administrator.

Creating the UDF:

5 minutes or less: User/Role API and SSL

This short post follows up Couple of things you need to know about the User/Role API. Now imagine that your LDAP identity provider is SSL enabled in 1-way mode (the server authenticates to the client, but the client does not authenticate to the server).

Now you need to tell Weblogic server how to validate the LDAP server certificate. And this is accomplished by adding the LDAP server CA certificate to the configured Weblogic trust store. If we’re talking about a self-signed certificate, simply add the certificate itself to the trust store. And there are a couple of options for the trust key store: Command Line, Custom Trust, Java Standard Trust or the OOTB Demo Trust. So far, so good. By adding the certificate to one of these options, Weblogic is all good to talk to the identity provider in SSL mode.

However, the User/Role API is not directly tied to Weblogic, so don’t expect it to take whatever is configured for the server. By default, as a standard Java-based client, the User/Role API looks for the standard Java $JDK_HOME/jre/lib/security/cacerts file, unless you tell it to look elsewhere, by informing the java system properties

javax.net.ssl.trustStore=<path_to_trust_store_file>
javax.net.ssl.trustStorePassword=<trust_store_password>

Relying on the original cacerts file may be dangerous in case you upgrade your JDK. If you need to leverage the existing certificates there, make a copy of the file and use the copy. Then simply tell the User/Role API where to read it from using the properties mentioned above.

Five Minutes or less: OpenID

Most of the technical people I work with know what SAML is and how it works and how the federation protocols for SAML work (SP initiated, IdP initiated, Browser Artifact, Browser POST). OpenID is much less well known.

So here's what you need to know about OpenID in five minutes or less.

In OpenID there are three parties:

• The user and their browser.
• The Relying Party (sometimes abbreviated to RP) is the web site that's asking the user to authenticate. In SAML this is the Service Provider.
• The OpenID Provider (sometimes abbreviated OP) is the web site that's going to vouch for the user. In SAML this is the Identity Provider

Many people use the SAML and OpenID terms interchangeably when talking about the OpenID parties but I'll try to remember to stick with the right ones for this post.

OpenID works a whole lot like SAML's SP Initiated Browser POST authentication except for these differences:

1. All user interactions are via HTTP GET
2. The RP and OP communicate directly with each other via HTTP

Here's a simplified view of the flow:

I've broken the flow into three stages:

1. Choose OP
2. Login @OP
3. AuthN

Note: these are my own divisions and names; the OpenID standard doesn't break the flow up and doesn't have names for what I call stages.

Stage 1: Choose OP
The first step in the OpenID flow is the user telling the Relying Party which OpenID Provider they would like to use, often though the NASCAR style row of buttons. Under the covers each of those buttons corresponds to a URL and when you click the button the HTML form is actually submitting the URL to the Relying Party's web site. In some cases the site will allow you to enter a URL of your choosing.

When you send the URL to the site the Relying Party checks to see if it "likes" the OpenID Provider (usually by checking against a list of providers). If the URL looks OK the RP makes an special HTTP request, called an XRDS request, to the OP. The OP returns back a bunch of data describing the OP including the features and functionality that the OP offers.

A couple of other things happen here, but in the interest of time I'm going to skip over them.

If everything looks OK the RP redirects the user to the OP with an Authentication Request (via an HTTP GET with the data in the query string).

Stage 2: Login @ OP
When the user sends their Authentication Request to the OP the OP makes the user login. If the user has already logged in to the OP then that step might be skipped.

After the user has authenticated to the OP the OP generates an authentication response for the RP and redirects the user back to the RP.

Stage 3: AuthN
Finally... the user presents that authentication response to the RP (via an HTTP GET). The RP checks it out and if it's "good" then the user is considered logged in.

Finally the RP returns the content, application or whatever it is that they were trying to do at the RP in the first place.

How many connections do I need from the WebGate to the OAM Server?

Someone just asked the question:

My question is that, if we have 2 oam servers and assign 1 as Max Number of Connections for each server, does this mean that the webgate can handle only 2 connections at a time? Do we need to increase this value to enable the webgate to serve more parallel requests?

There is a relationship between the WebGate to OAM Server connections and the user to web server connections but it's not 1-to-1.

When a request comes into the web server the WebGate needs to figure out a few things:

1. is the resource is protected by OAM?
2. has the user already authenticated?
3. if yes to both should the user be allowed to see the resource?

Generally speaking the WebGate needs to send each question to the OAM Server and wait for an answer. That answer comes back from the OAM Server in milliseconds - the vast majority of which is actually the round trip time through the network to the OAM Server... there's nothing we can do about that pesky speed of light (damn you Einstein!).

Incidentally the connections the WebGate uses are opened when the WebGate gets started and are managed as a pool - when there are spares that haven't been used for a while they get shut down. When more are needed they get opened. The docs talk about how all of this works in pretty good details.

Many people start out thinking "if I want to support 100 concurrent users I'm gonna to need at least 100 connections from the WebGate to the OAM server."
Those people are wrong.
Plus they really shouldn't say "gonna" as it's not an actual word.

Consider these use cases

• a web server where you have hundreds of unprotected resources. In that case the first time someone requests the resource the WebGate will discover that it's unprotected. After that the WebGate knows the answer to question 1 and it doesn't need to talk to the OAM server for that resource again.
• a web server on which users keep reloading the same resource over and over during a session, for example if they're making mostly JSON or REST calls via JavaScript in an AJAX app. In that case after the first request by that user the subsequent requests will come out of the WebGate's cache.
• a web server mostly serving up very large files for download. In that case the answer from the OAM Server comes back in milliseconds but the download takes 20 minutes.
• or even 99% of the web servers out there on the internet where the user loads a page and then reads through the content for a few minutes before clicking again to read the next page or story.

In short: there's no good hard and fast rule about the number of connections you need from the WebGate to the OAM Server. Only testing your web site under representative load will help you figure out what the right numbers are.

And in that way the WebGate to OAM connection pool is a whole lot like connection pools from the Web Server to the App Server or from the App Server to the Database. And by a "whole lot like" I mean exactly the same.

Using the OIF Business Process Plug-in

There are a few extension points in OIF that allow you to easily extend or tweak the product's behavior. The one you're most likely to use is the Business Process plug-in.

I recently completed a PoC where OIF was the Identity/OpenID Provider and the customer wanted to send a bunch of attributes along to the Service Provider/Relying Party. All that is out of the box behavior. What's not OOTB is that they wanted to prompt the user to fill in any values that weren't in the LDAP directory before the user was sent back to the SP/RP.

The Business Processing plug-in gives you the opportunity to do that.

Using the nsstools to manage SSL stores for curl

While working on today's research project I also needed to test with curl. Sadly in my environment curl was built with NSS support which caused me some grief. I had never used NSS-enabled apps before and didn't know how to deal with their certificate and private key database.

I do now.

SSL/TLS fun with client certificate authentication

Today's adventure was a question about limiting SSL connections.

The customer's problem statement was along the lines of

I want to make SSL connections, using client certificate auth (i.e. two-way ssl) and have the server accept only one certificate. Can I put the one cert I want in the "trusted CA list" to do that?

I thought the answer was "no, that's not how you do that" but I wasn't 100% sure so off I went on a research project...