The identity portlets provide the following features:

CAPTCHA is an acronym for Completely Automated Public Turing test to tell Computers and Humans Apart. This is providing a mechanism to prevent automated programs from using different services. The User Portlet uses JCaptcha to provide a challenge-response.

-Djava.awt.headless=true

The registration page with captcha.

The captcha support can be enabled by changing the portlet preference 'captcha' to 'true'. If enabled, captcha will be used for the registration and lost password action.

...
<portlet>
...
	<display-name>User portlet</display-name>
...
	<portlet-preferences>
		<preference>
			<name>captcha</name>
			<value>true</value>
      	</preference>
	</portlet-preferences>
</portlet>
...

The lost password feature enables the end user to reset his password by entering his username.

The lost password page with captcha enabled.

The lost password feature can be enabled by changing the portlet preference 'lostPassword' to 'true'. If captcha is enabled it will be also used for verifying the lost password action.

...
<portlet>
...
	<display-name>User portlet</display-name>
...
	<portlet-preferences>
		<preference>
			<name>lostPassword</name>
			<value>true</value>
		</preference>
	</portlet-preferences>
</portlet>
...

The reset password feature is similar to the lost password feature, but it is used in the User Management Portlet to reset the password of a user. That means changing the password of a user is slightly simplified, because a random password will be generated and sent to the users e-mail address.

...
<portlet>
...
	<display-name>User management portlet</display-name>
...
	<portlet-preferences>
		<preference>
      		<name>resetPassword</name>
      		<value>true</value>
		</preference>
	</portlet-preferences>
</portlet>
...

JBoss Portal supports three different subscription modes by default:

Approve or reject pending registrations (jbp_identity_validation_approval_workflow).

The Identity Portlets use some metadata which can be easily changed in the main configuration file, which is located at jboss-portal.sar/portal-identity.sar/conf/identity-ui-configuration.xml as shown here:

<identity-ui-configuration>

	<subscription-mode>automatic</subscription-mode>
	<admin-subscription-mode>automatic</admin-subscription-mode>
	<overwrite-workflow>false</overwrite-workflow>
	<email-domain>jboss.org</email-domain>
	<email-from>no-reply@jboss.com</email-from>
	<password-generation-characters>a...Z</password-generation-characters>
	<default-roles>
		<role>User</role>
	</default-roles>

	<!-- user interface components -->
	<ui-components>
		<ui-component name="givenname">
			<property-ref>user.name.given</property-ref>
		</ui-component>
		<ui-component name="familyname">
			<property-ref>user.name.family</property-ref>
		</ui-component>
		...
</identity-ui-configuration>

Due to the differentiation between subscription-mode and admin-subscription-mode it is possible to require e-mail validation and approval for new registrations and e-mail validation only when a user is created in the user management portlet.

The email templates can be found in the folder: portal-identity.sar/conf/templates/
New languages can be added by creating a new file like: emailTemplate_fr.tpl

This example explains how to change optional properties to required properties, of course once this is done, we will also need to add the corresponding fields in the registration page.
Here are the modifications in portal-identity.sar/conf/identity-ui-configuration.xml, we simply changed the required element to true on our two fields corresponding to the given and family names.

<identity-ui-configuration>
...
	<!-- user interface components -->
		...
		<ui-component name="givenname">
			<property-ref>user.name.given</property-ref>
			<required>true</required>
		</ui-component>
		<ui-component name="familyname">
			<property-ref>user.name.family</property-ref>
			<required>true</required>
		</ui-component>
		...
</identity-ui-configuration>

Now that we changed those values to "required" we need to give a chance to the user to enter those values, here are the changes done in portal-identity.sar/portal-identity.war/WEB-INF/jsf/common/register.xhtml

...
	<h:outputText value="#{bundle.IDENTITY_GIVENNAME}"/>
  	<h:inputText id="givenname" value="#{manager.uiUser.attribute.givenname}"
  			required="#{metadataservice.givenname.required}"/>
  	<h:panelGroup />
  	<h:message for="givenname" />

  	<h:outputText value="#{bundle.IDENTITY_FAMILYNAME}"/>
  	<h:inputText id="lastname"  value="#{manager.uiUser.attribute.familyname}"
  			required="#{metadataservice.familyname.required}"/>
  	<h:panelGroup />
  	<h:message for="lastname"/>
...

That's it - from now on the given name and family name will be required on registration. We dynamically obtain the values from the descriptor. Now if i just wanted to make them back to optional, i would change the values only in the descriptor, letting the user enter or not those values.

If the data to enter is a choice instead of a free-text value, you can also define those in the descriptor like shown here:

<identity-ui-configuration>
...
	<!-- user interface components -->
		...
		<ui-component name="interests">
			<property-ref>portal.user.interests</property-ref>
			<values>
				<value key="board">snowboarding</value>
				<value key="ski">skiing</value>
				<value key="sledge">sledging</value>
			</values>
		</ui-component>
		...
</identity-ui-configuration>

In portal-identity.sar/portal-identity.war/WEB-INF/jsf/common/profile.xhtml - change inputText to a selectOneMenu:

	...
	<h:outputText value="#{bundle.IDENTITY_INTERESTS}"/>
	<h:selectOneMenu id="interests" value="#{manager.uiUser.attribute.interests}"
		required="#{metadataservice.interests.required}">
	<f:selectItems value="#{metadataservice.interests.values}" />
	</h.selectOneMenu>
  	<h:panelGroup />
	<h:message for="interests"/>
...

For localizing dynamic values it is also possible to use the resource bundle. This can be done by adding the key with a prefix (to i.e. Identity.properties) like in the following listing. The key will be stored in the users property and is used to identify the element. The value of the configuration file will only be used if no localization information is found.

...
IDENTITY_DYNAMIC_VALUE_BOARD=localized snowboarding
IDENTITY_DYNAMIC_VALUE_SKI=localized skiing
IDENTITY_DYNAMIC_VALUE_SLEDGE=localized sledging
...

step 1: add a new property to profile-config.xml e.g. a dynamic property called gender:

...
   <property>
      <name>user.gender</name>
      <type>java.lang.String</type>
      <access-mode>read-write</access-mode>
      <usage>optional</usage>
      <display-name xml:lang="en">Gender</display-name>
      <description xml:lang="en">The gender</description>
      <mapping>
         <database>
            <type>dynamic</type>
            <value>user.gender</value>
         </database>
      </mapping>
   </property>
...

step 2: add the property to the identity-ui-configuration: (portal-identity.sar/conf/identity-ui-configuration.xml)

...
	<ui-component name="gender">
		<property-ref>user.gender</property-ref>
		<required>true</required>
		<values>
			<value key="male">Male</value>
			<value key="female">Female</value>
		</values>
	</ui-component>
...

step 3: add your custom ui-component to the profile page: (portal-identity.sar/portal-identity.war/WEB-INF/jsf/profile.xhtml)

...
	<h:outputText value="#{bundle.IDENTITY_GENDER}"/>
	<h:selectOneMenu id="gender" value="#{manager.uiUser.attribute.gender}"
			required="#{metadataservice.gender.required}">
		<f:selectItems value="#{metadataservice.gender.values}" />
	</h.selectOneMenu>
  	<h:panelGroup />
	<h:message for="gender"/>
...

Illustration of the relationship between the configuration files.

The JSF-View in more detail:

By default not all values of the user profile will be displayed on the View profile page. For customization it is possible to add further properties to the page by editing the file: portal-identity.sar/portal-identity.war/WEB-INF/jsf/profile/viewProfile.xhtml

By default requests (e.g. e-mail validation and registrations) expire after some time in the validation state. Therefore it is not required to add additional maintenance mechanism to invalidate a request. The default expiration time is 2 days, but is quite easy to change the timing by editing the duedate attribute in the process definition. changes in: portal-identity.sar/conf/processes/*.xml

<process-definition>
...
  <state name="validate_email">
  	  <timer name="time_to_expire" duedate="2 days" transition="timedOut" />
  </state>
...
</process-definition>

When migrating from former versions of JBoss Portal the Identity User Portlets won't be displayed by default, but windows can be created on basis of the existing Portlet Instances which are deployed by default. (The instances names being IdentityUserPortletInstance and IdentityAdminPortletInstance.)