IBM Identity Manger: Adding a new attribute

Background

The documentation on this is lacking on this topic, and the example LDIF file provided is in a format that will cause idsldapmodify to fail with a painfully obtuse error message. So I'm documenting this here to help the next person avoid some headache.

Details

Here's the documentation on how to add an attribute. In there, it provides this LDIF file as an example:

dn: cn=schema changetype: modify add: attributetypes attributetypes: ( myAttribute-oid NAME ( 'myAttribute' ) DESC 'An attribute I defined for my LDAP application' EQUALITY 2.5.13.2 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 {200} USAGE userApplications ) - add: ibmattributetypes ibmattributetypes: ( myAttribute-oidDBNAME ( 'myAttrTable' 'myAttrColumn' ) ACCESS-CLASS normal LENGTH 200 )

However, if you try to import that LDIF file with the idsldapmodify command given, you'll get the following error:

ldapmodify: invalid format (line 5 of entry: cn=schema)

After a bit of pain, I figured out that the whitespace in the lines are the problem. You need to either concatenate the continued lines together OR have some white space at the front of the continued lines. Additionally, there should be a space in betwee "oid" and "DBNAME". So if you change the file to the following, you will no longer get the error:

dn: cn=schema
changetype: modify
add: attributetypes
attributetypes: ( myAttribute-oid NAME ( 'myAttribute' ) DESC 'An attribute I defined for my LDAP application'    EQUALITY 2.5.13.2 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15    {200} USAGE userApplications )
-
add: ibmattributetypes
ibmattributetypes: ( myAttribute-oid DBNAME ( 'myAttrTable' 'myAttrColumn' ) ACCESS-CLASS normal LENGTH 200 )
What about updating the objectclass?
That's what I was wondering! Simply adding an attribute doesn't really help you much until you add it as a MUST or a MAY attribute to an objectclass. IBM has an almost complete guide to doing that here, But it is incomplete. For one thing, the format of the data is wrong again. The long attribute values should all be on a single line, like this:
dn: cn=schema
changetype: modify
replace: objectclasses
objectclasses: ( 2.16.840.1.113730.3.2.2 NAME 'inetOrgPerson' DESC 'Defines entries representing people in an organizations enterprise network.' SUP 'organizationalPerson' Structural MAY ( audio $ businessCategory $ carLicense $ departmentNumber $ employeeNumber $ employeeType $ givenName $ homePhone $ homePostalAddress $ initials $ jpegPhoto $ labeledURI $ mail $ manager $ mobile $ pager $ photo $ preferredLanguage $ roomNumber $ secretary $ uid $ userCertificate $ userSMIMECertificate $ x500UniqueIdentifier $ mytest ) )
Additionally, where did that value for "objectclasses" come from?? Well, that came from this command:
ldapsearch -b cn=schema -s base objectclass=* objectclasses | grep \'inetOrgPerson\'
Running that, you will get a result similar to:
objectclasses=( 2.16.840.1.113730.3.2.2 NAME 'inetOrgPerson' DESC 'Defines entries representing people in an organizations enterprise network.' SUP organizationalPerson STRUCTURAL MAY ( audio $ businessCategory $ carLicense $ departmentNumber $ displayName $ employeeNumber $ employeeType $ givenName $ homePhone $ homePostalAddress $ initials $ jpegPhoto $ labeledURI $ mail $ manager $ mobile $ o $ pager $ photo $ preferredLanguage $ roomNumber $ secretary $ uid $ userCertificate $ userPKCS12 $ userSMIMECertificate $ x500UniqueIdentifier ) )
Modify that to include your new attribute, then put that into the LDIF file. Then run idsldapmodify to import that LDIF file into your server. After that, you'll have your new attribute added to the inetOrgPerson objectclass.

IDI Development: Promoting Code From TEST to PROD

Background

The documentation on this topic is slim on the gory details, so I figured I would write a little bit about it. 

Situation

If you have different TEST/DEV and PROD environments (as you should), you will be creating solutions in TEST/DEV, then you need to somehow get those solutions to PROD. There are two difference scenarios to consider at this point.

1. Solutions with no external properties files

This is the easy scenario. And the way to make it the easiest is if you add your PROD IDI Server to the list of Servers in your TEST/DEV CE (in the bottom left hand pane of your CE):

Adding a remote server is easy if you simply have all of the defaults in place and all servers are at the same version of IDI. If you've updated certificates and/or have different versions of IDI, it's harder. So for this post, I'm going to assume you're on the easy path. So to add a remote server, you just need to first add a server to create a new server document. To keep things simple, name it the same as the remote hostname. Then right-click that server and select "Open Configuration". In the configuration, point to the remote IDI server like so:

My remote server is named jazzsm9, and the IDI server is running on the default port of 1099. Just the first (Server API Address) field needs to be filled in. It will actually fill in the last field (ActiveMQ Management port) automatically for you based on the port you specify in the first field. once you add it, the server should show up with a green circle with an inscribed white triangle next to it, like this:

Now you can simply Export your solution (Project) directly from the CE to the remote server. 

To do this:

1. Right-click your project and select "Export..."

2. Select "IBM Security Verify Directory Integrator-> Runtime Configuration (e.g. rs.xml)"

3. On the dialog that follows, make sure to select "Server", select the appropriate server, and specify a name for the solution. The name you pick will be the name of the XML file created in that remote server's $SOLUTION_DIR/configs directory. 

Here's a link to a short video showing the process.

2. Solutions WITH external properties files

This process is more involved because you not only have to copy the solution over to the remote server, you ALSO MUST COPY OR CREATE THE EXTERNAL PROPERTIES FILES ON THE REMOTE SERVER. This is one of the important parts that the existing documentation leaves out. The project/solution contains REFERENCES to external properties files, but does not actually contain the properties files themselves nor the properties in those files. This means that you will have to either copy the properties files over to the other server in the correct location or create them in the correct location. This isn't a huge step, but it's one you need to keep in mind when promoting code from TEST to PROD, especially the first time you do it for a particular project/solution.