Author: Aaron Sheffey (aaronsheffey@yahoo.com)
Table of Contents
Introduction
Modify iPlanetAMUserService
Update the Data Source Configuration
Modify the LDAP
Test
Introduction
OpenSSO enables the creation of custom User Attributes which can be used by downstream business applications. This tutorial targets the embedded OpenDS installation included as the default LDAP in OpenSSO.
Modify iPlanetAMUserService
OpenSSO stores its configuration data in the LDAP under ou=services. Service iPlanetAMUserService contains the information on what to display in the User Profile screens in the Admin Console; updating the service exposes the custom attribute(s) on this screen for display and/or updates.
- Locate the iPlanetAMUserService configuration file, called amUser.xml. This file is located in the OpenSSO application configuration directory. With the default install of OpenSSO on Windows, this file will be located in C:\Documents and Settings{your name}\opensso\config\xml.
- Back up the file.
- Add new AttributeSchema elements to the file, inside the <User> element, as follows. Note that the name property, which will be the Attribute name in the LDAP, must conform to LDAP naming standards. Camel case is the safest. The i18nKey property is the label which shows on the User Profile screen.
| <AttributeSchema name="myAttributeName" type="single" syntax="string" any="display" i18nKey="My Attribute Name"> </AttributeSchema> |
- Save and close the file.
- Locate and enable the famAdminTools.zip file which is included with opensso. It will be located in the \tools directory in the OpenSSO install root.
o Unzip the file.
o Run setup.bat. You will be prompted for the location of the OpenSSO application configuration directory. Enter "C:\Documents and Settings{your name}\opensso".
o Subdirectory \opensso\bin under the unzip directory will be created; the tools are there.
- Use famadm.bat to reload iPlanetAMUserService. First, delete the service. Note that -f points to a file containing the amAdmin user's password.
| ssoadm delete-svc -u amadmin -f pwd -s iPlanetAMUserService |
- Then, add it back in:
| ssoadm create-svc -u amAdmin -f pwd --xmlfile c:\DOCUME~1{your name}\opensso\config\xml\amUser.xml |
- In the OpenSSO Admin Console, look at the User Profile (Access Control > {your Realm} > Subjects) page for any user; the new Attribute field should show up. Trying to enter any values in this field will throw a null pointer exception, as the Attribute has not yet been set up in the Data Source configuration (next step).
Update the Data Source Configuration
This step bridges the User Profile screen to the LDAP user store.
- In the OpenSSO Admin Console, go to Access Control > Data Stores > embedded.
- In the LDAP User Object Class field, add the name of the new Object Class you will be creating in the LDAP.
- In the LDAP User Attributes field, add the name(s) of the new Attributes you will be creating in the LDAP.
- Check to see if the LDAP Bind DN field is populated. If not, enter the DN for your LDAP. In this case, using the embedded OpenDS, the DN is cn=Directory Manager. Also enter the password for the DN, which is password.
- Click Save to save. Now the form fields exposed by the service will be passed back to the user store LDAP.
Modify the LDAP
At this point, OpenSSO is set up to pass the new Attribute(s) back to the LDAP. However, the Attributes 1) don't exist yet in the LDAP, and 2) aren't bound to any Object Classes in the LDAP. Both of these actions need to be done.
- Confirm that you have direct access to the LDAP. I've been using Apache Directory Studio - its free and easy to use.
- Create a new LDIF file to update the LDAP. Note that LDIF syntax is extremely particular; for example, the empty lines at the end is on purpose. Apache Directory Studio validates LDIFs, which is very helpful. It should look something like this:
dn: cn=schema
changetype: modify
add: attributeTypes
attributeTypes: ( 2.16.840.1.113730.3.1.9990
NAME 'myAttribute'
DESC 'Some description of the attribute'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
X-ORIGIN 'Some identifying text for your Attribute' )
-
add: objectClasses
objectClasses: ( 2.16.840.1.113730.3.2.9999
NAME 'my-object-class-name'
DESC 'Class to hold my custom user attributes'
SUP top
AUXILIARY
MAY ( uid $ myAttribute )
X-ORIGIN 'Some identifying text for your object class' )
- I'm in no way an expert on LDIF files, but as best as I can tell, the details are as follows: the SYNTAX OID value for the Attribute points is the same as the one in the OpenSSO OpenDS LDIF (am_remote_opends_schema.ldif), which is located in C:\Documents and Settings{your name}\opensso\ directory. The Object Class is a child of the top Object Class, and, following the pattern in the OpenDS LDIF, references the uid Attribute, in addition to the new custom Attribute.
- In Apache Directory Studio, load your LDIF file (File > Open File), connect the file to your LDAP (click the Browse button in the editor), and click the green arrow button to run the LDIF. The Attribute(s) and Object Class will be added to the LDAP, with the Attributes bound to the Object Class.
- The LDAP is now set up to accept the values from the Admin Console and to persist them.
Test
- Since we are using the embedded OpenDS instance, restart the app server hosting OpenSSO. This action restarts both the OpenSSO application as well as the embedded OpenDS LDAP server.
- Update a user with the new Attribute.
Comments (5)
Feb 05, 2009
JonS421 says:
I am using Sun Java System Directory Server in my test environment but this was ...I am using Sun Java System Directory Server in my test environment but this was the only source I found, so I thought I would add some info I found while trying to figure this out –
The LDIF file with the <AttributeSchema> for Sun Java Directory Server corresponding to am_remote_opends_schema.ldif is in the same location and called ds_remote_s1ds_schema.ldif
The long numbers are "ASN.1" identifiers which start with a unique organization ID (OID) (in this case for Sun Microsystems). If you are going to make additional new LDAP attributes of your own you can / should apply for an OID. There are many preexisting attributes from other organizations to choose from, also.
The localization file for decoding the i18nKey code values is located in the web container directory for OpenSSO, on my test glassfish installation this is <app server deploy directory>/domains/domain1/applications/j2ee-modules/opensso [This is documented in OpenSSO Dev Guide under localization]
Does anyone know if there is a way to extend the user-editable profile attributes through the opensso control center, assuming the attribute is pre-existing in the directory server schema?
May 15, 2009
songjing says:
Thanks. It work. I have a sub-ream that using standalone openDS, by follow abo...Thanks. It work.
I have a sub-ream that using standalone openDS, by follow above guide, I'm able create the custom attribute and store the value.
However, later I found out, only user with admin privilege can edit this custom attribute only. Can I make this attribute like other user own attributes (e.g. email, postal address) that not admin user also can modify from opensso UI (http://<ip>:<port>/opensso/idm/EndUser)?
I face below error message:
Permission to perform the edit operation denied to uid=.....
The problem I face is that because:
Here the policy log record:
UserSelfCheckCondition.getConditionDecision: Is attributes
[pscsg-user-ui-skin-name] subset of config attrs:
[iplanet-am-user-password-reset-question-answer,
userpassword, givenname, postaladdress, cn, telephonenumber,
sunIdentityServerDeviceStatus,
sunIdentityServerDeviceKeyValue, mail, sn, preferredlocale,
iplanet-am-user-password-reset-options, description]
amPolicy:05/15/2009 05:23:58:449 PM GMT+08:00:
Thread[WebContainer : 0,5,main]
UserSelfCheckCondition.getConditionDecision: attributes
check:false
How to make the attributes check become true to make the
custome attribute (pscsg-user-ui-skin-name) become subset of
config attrs?
May 18, 2009
songjing says:
I just discover the value pass to UserSelfCheckCondition.getConditionDecision is...I just discover the value pass to UserSelfCheckCondition.getConditionDecision is get from:
ou=SelfWriteAttributes,ou=Policies,ou=default,ou=OrganizationConfig,ou=1.0,ou=iPlanetAMPolicyService,ou=services,o=sunamhiddenrealmdelegationservicepermissions,ou=services,<domain>
This policy is using sunAMDelegationService which is not available in UI.
And this policy only can get modify under sunamhiddenrealmdelegationservicepermissions, that means even U create a your own policy for your realm and add in the value via ldap browser, you not able modify it from UI as well. That is because sunAMDelegationService is not available for UI.
The problem is, by modify SelfWriteAttributes under sunamhiddenrealmdelegationservicepermissions, that means when I upgrade opensso, all setting will be gone and need reset again.
Actually configure allow self write attribute should be very basic setting via UI.
Oct 13
JanVdB says:
The fix mentioned above works in Express Build 7, but not in Express Build 8. Ap...The fix mentioned above works in Express Build 7, but not in Express Build 8. Apparantly, when using Express Build 8, you also have to modify the value under: ou=SelfWriteAttributes,ou=default,ou=default,ou=OrganizationConfig,ou=1.0,ou=sunEntitlementIndexes,ou=services,o=sunamhiddenrealmdelegationservicepermissions,ou=services,dc=aca-it.be,dc=be and add your attributes there as well.
Sep 25
jimball says:
I needed to add custom attributes to an identity in order to map a domain identi...I needed to add custom attributes to an identity in order to map a domain identifier back to a legacy identifier, so old applications could still be logged into with old identifiers, and with it all held on the user details and all editable over the opensso UI.
Your article is top work.
Just wanted to add some clarification (gotchas) for opensso express 8.
1) On windows, any command you've give for the ssoadm only seem to work if the path to the amUser.xml doesn't contain any spaces, same goes for the path to the ssoadm tool and to the password file you need to make prior to using it (at least this was true for me)
2) ssoadm is really picky about the sequence of input flags for the create-svc command, the path to the XML needs to go first, then the username, and finally the password file
3) The format of the LDIF you gave didn't work for me, I had to seperate every modification in the file with a "-"
Like so:-
dn: cn=schema
changetype: modify
add: attributeTypes
attributeTypes: ( 2.16.840.1.113730.3.1.9990 NAME 'systemALogin' DESC 'Legacy Identifier for systemA' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'My Company' )
attributeTypes: ( 2.16.840.1.113730.3.1.9991 NAME 'systemBLogin' DESC 'Legacy Identifier for systemB' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'My Company' )
-
add: objectClasses
objectClasses: ( 2.16.840.1.113730.3.2.9999 NAME 'legacyLogin' DESC 'Class for holding legacy login identifiers' SUP top AUXILIARY MAY ( systemALogin $ systemBLogin ) X-ORIGIN 'Legacy application identifier class' )
-
So, empty line at the end of the file, () enclosing braces on the entries, and modify "add" record seperators of "-", including the one before the space at the ned of the file. Heinous syntax indeed.