Before editing the<conf-dir>/config/xml/amUser.xml file make sure you make a copy of this original file. In case you mess up the customization process you can revert back to the original configuration using this original schema file. Using your favorite editor add packt-services-user-status, packt-services-user-location, and packt-services-user-blog attributes at the end of the file just before the</User> element. You will notice in the following code listing here that there are some attribute schema element properties that need to be defined for each attribute schema. These properties determine what kind of values an attribute can accept, whether to display for the end user and a value can be null for that attribute.

The following code must be compliant with the jar://com/sun/identity/sm/sms.dtd. Make sure you appropriately close the tags to arrive at a well-formed XML document:

<AttributeSchema name="packt-services-user-status"
type="single_choice"
syntax="string"
any="required|filter|adminDisplay"
validator="RequiredValueValidator"
i18nKey="cust100">
<ChoiceValues>
<ChoiceValue i18nKey="cust200">Active</ChoiceValue>
<ChoiceValue i18nKey="cust201">Inactive</ChoiceValue>
</ChoiceValues>
<DefaultValues>
<Value>Inactive</Value>
</DefaultValues>
</AttributeSchema>
<AttributeSchema name="packt-services-user-location"
type="single"
syntax="string"
any="display|filter"
OpenSSO services, customizingattributes, adding to amUser.xmli18nKey="cust101">
</AttributeSchema>
<AttributeSchema name="packt-services-user-blog"
type="single"
syntax="string"
any="display"
i18nKey="cust102">
</AttributeSchema>

Updating the XML schema file alone is not sufficient to make the new attributes a part of the OpenSSO User Service. At this point the OpenSSO server still uses the old schema that exists in the configuration store. Unless the configuration store is updated with the new values, your custom attributes will not show up in the console. So the existing service schema must be removed first. It can be removed by using the ssoadm.jsp or ssoadm CLI tool. There is no provision in the administrative console to remove the service. You can use the delete-svc subcommand to remove any existing service from the server. Invoke the following command to remove the User Service:

./ssoadm delete-svc -s iPlanetAMUserService -u amadmin -f /tmp/.passwd_of_amadmin

This will remove the existing User Service schema from the server.

The updated user schema must be loaded now. It can be accomplished by using the create-svc sub command of the ssoadm utility. To add the updated User Service schema that contains the custom attributes, execute the updated user schema file. It is located in /export/ssouser/opensso/config/xml/amUser.xml file. This process will update the configuration store with that latest schema for the User Service. In the multiple OpenSSO servers that share the same replicated configuration, you just perform the above step once. There is no need to execute in all of the servers as the configuration information is automatically replicated to all the servers. Here is an example:

./ssoadm create-svc -X /export/ssouser/opensso/config/xml/amUser.xml -u amadmin -f /tmp/.passwd_of_amadmin

The new attributes that have been added to the User Service require a human readable label to be shown in the console. This label is a localizable string (i18nKey) which is stored in a property file stored as part of the OpenSSO web application. This property file name is amUser_locale.properties where locale is the current localized environment. For the English locale, it would be amUser_en.properties. An appropriate label should be added for each property that is added to the amUser.xml. If the value is empty then that attribute will not be displayed on the console. It is very important to match the i18nKey values that you supplied in the amUser.xml. For instance, the following screenshot has the i18nKey property. cust101 value is supplied for the property packt-services-user-location, so you should supply a meaningful string that will relate to this property. In this case, it is aptly labeled as Packt Services User Location. This file can be located under the WEB-INF/classes directory. Some of the application servers may not let you modify directly under the web application deployment directory. In such scenarios, you can generate a new opensso.war after making the customizations:

cust100=Packt Services User Status
cust101=Packt Services User Location
cust102=Packt Services User Blog Entry
cust200=Status Active
cust201=Status Inactive

Even though the user schema is updated with latest schema changes, the custom user attributes will not be available to the newly created users until the custom attributes and object classes are added to the specific realm's data store configuration properties as shown in the following screenshot. You need to manually edit the existing data store configuration properties. This will instruct the IdRepo sub system that the new attributes need to be added whenever a new user is created or their attributes are to be retrieved along with these custom attributes.

The use case requires the packt-services-user-location and packt-services-user-blog to be self-modifiable for the users who possess these attributes as part of their profile. As a security precaution only certain attributes are writable by the end user of the OpenSSO server. The administrator can override these, based on the privileges assigned to the administrator. If there is a need to permanently make certain profile attributes writable by the normal user, the administrator must update the default delegation policies. This can be accomplished by editing the appropriate policies. Follow these simple steps in sequence:

./ssoadm create-policies -u amadmin -f /tmp/.passwd_of_amadmin -X /tmp/exported_delegation_policy.xml -e /sunamhiddenrealmdelegationservicepermissions

That is all. Now the user's location and blog entry attributes can be written by the end user from their profile page.

After completing the customization steps as previously discussed above, if you did not see any errors in the process, then you are successful in completing the customization process. Now restart the OpenSSO server. Once the server is up and running, log in as a top level administrator and try to create a new user identity from the Subjects | User tab. In the New User creation page you should see the Packt Services User Status attribute with a default value Active (set as the default value by the amUser.xml) as shown in the following screenshot. The other two attributes will also show up in the console, but those will not mandate a value to be set at the time of the user creation. It is because they are not required as per the schema definition.

Let us test as a normal user. Log out from the server and log back in as a normal user, Indira Thangasamy with password secret12. When you inspect the end user profile page, two new attributes Packt Services User Location and Packt Services User Blog Entry are displayed, and it is an editable text box as shown in the following screenshot: