Posts Tagged ‘Identity Manager’

All Java is Not Created Equal

Tuesday, January 31st, 2012

***NOTE: As with all Tips and Tricks we provide on the IDMWorks blog, use the following AT YOUR OWN RISK.  We do not guarantee this will work in your environment and make no warranties***

The what:

Java & CA Identity Manager V12.5

The issue:

I got hung up with a version of Java 6.29 that should have worked with CA IDM V12.5 but on Windows, the IDM install was completing yet the JBoss startup hung on Analytics everytime.

The symptoms:

On Windows, CA IDM did not load thoroughly enough to do a clean uninstall. In the boot log there were errors abound specific to  ‘unzipping jar files’ but not much more to go on.

I replaced JBoss with a new download from a known good load to no avail.

I thought perhaps the Java version was incorrect. I uninstalled and reinstalled Java 6.27 but this only appeared to cause more problems.

The Solution:

In an effort to not have to wipe the box to change the Java install, I renamed the folder containing 6.27 to 6.29 and reset the Java Home variable.
The IDM console started up correctly utilizing the lower version of Java from the higher named Container.
The product release notes did say Java 6.X but this does not always guarantee compatibility.

Questions, comments or concerns? Feel free to reach out to us at IDMWorks.

Novell IDM Best Practices: Don’t Forget the Small Stuff

Monday, October 17th, 2011

Don’t Forget the Small Stuff

When developing a Novell IDM driver its easy to get focused on requirements and lose track of the little things that can come back to bite you later on. The perfect example of this is the DirXML-Associations attribute.

This handy little attribute is typically automatically set by a driver to establish a relationship between an object in eDirectory and the object in the driver’s connected system.  When this value is set for a specific driver it allows future changes to be processed more quickly and efficiently.  These relationships are stored in eDirectory on the object and consist of the unique identifiers from the connected systems; for example, the Microsoft Active Directory driver leverages the Active Directory’s GUID value for the account to create the association in eDirectory.

The problem is that once these associations are created there are only two ways of getting rid of them.  The most obvious way is to delete the associated object in eDirectory.  If the object holding the values is deleted then it goes without saying that the values are deleted.  This method doesn’t require any additional coding or consideration in the driver.

The other method is to remove the association value from the attribute in eDirectory either manually (not recommended) or programmatically by creating a policy in the driver that contains the Remove Association action.  This means that someone has to create a policy or policies that contain a number of conditions to determine if/when an association should be removed.  The only thing is that in the course of requirements gathering and design these use cases and conditions are overlooked and not documented and therefore do not get implemented.

More often than not requirements simply dictate that a driver is not to delete objects out of eDirectory.  The natural instinct is to create a simple policy that checks to see if the current transaction is a delete event and if so to do a simple veto action.  The veto action will stop the transaction from processing through the driver to eDirectory and will result in the eDirectory object being unchanged, including the driver association.

So what’s the issue with keeping a driver association in eDirectory after the object/account/record has been deleted out of the connected system?  Well, simply put, it causes errors! This is because of how the driver detects and uses the association values in the DirXML-Associations attributes for more efficient transaction processing its a problem to have an association for a driver that points to a nonexistent record.

The result is that when an transaction for an object in eDirectory in such a state processes through the associated driver the driver will use the invalid association as its target reference.  This causes the transaction to result in an error because the target reference no longer exists.  The obvious result of this is that no changes are made in the target system.

On the flip side of things, if an unassociated object/account is created/modified in the target system and the driver attempts determines that the record in questions matches are previously associated eDirectory record the driver will attempt to merge the records and create a new association in eDirectory with the new account.  This causes an issue too.  An eDirectory object is only allowed to have one association per driver and since the driver already has an association for the old record on the eDirectory object the merge process will fail and the driver logs will record an error along the lines of “Object already associated“.

In either case the obsolete associations in eDirectory essentially defeat the purpose of having an identity management system.  Removing an association through driver policies is simple to do and can go a long way in developing a system that delivers reliable identity management capabilities between the various connected systems.  So the next time you are planning a driver or get a requirement that demonstrates the use case where the relationship between eDirectory and a connected system is being destroyed remember to clean up the association.

Questions, comments or concerns?  Feel free to reach out to us at IDMWorks.

Tips & Tricks: CA SiteMinder User Directory Tuning

Monday, August 29th, 2011

***NOTE: As with all Tips and Tricks we provide on the IDMWorks blog, use the following AT YOUR OWN RISK.  We do not guarantee this will work in your environment and make no warranties***

Today I thought I add a few tips & tricks related to CA SiteMinder Directory Services Tuning, as usual, any questions or comments you might have can be added below.

Adding Additional Directory Connection Pools

A major tuning parameter of the Directory Services is enabling additional directory connection pools. For each Policy Server and smsuserdirectory object defined a ldap connection pool is created.  In addition, for Load Balancing, an additional pool is created for each load-balanced LDAP server object.

To enable the additional pools for the LDAP server object, you can define the same directory server host as a load-balanced server. The result is the connection pool for the same logical host can double or triple the number of connection pool entries for a single directory object.

Measuring Directory Performance

In past deployments it has been shown that doubling the connection pool increases performance.
It is recommended that a monitoring tool be used to evaluate the overal performance gain.


Enabling the SiteMinder profiling logs and specific LDAP component categories can accurately measure the policy servers directory performance.
The following log entry from an Identity Manager policy evaluation shows the time in milliseconds taken to execute a user attribute lookup from a role membership rule.

The log entries below uses a time stamp of hh.mm.ss.ms. The ms or milliseconds portion is only enabled when the above PreciseTime data field is used.

As you can see from the highlighted text in the log entries below, this lookup returned in 8 milliseconds.

[04/16/2008][11:25:34.192][IMS6LdapRules.cpp:539][7728][Enter function
CIMSDsLdapProvider::findManagedObjects][CIMSDsLdapProvider::findManagedObjects][][][][][][][][]
[04/16/2008][11:25:34.192][IMS6DsLdapProvider.cpp:6527][7728][Additional filter: (location=Charlotte)
.][CIMSDsLdapProvider::ConstructSearchFilter][][][][][][][][]
[04/16/2008][11:25:34.192][IMS6DsLdapProvider.cpp:6564][7728][Constructed filter:
(&(objectclass=top)(objectclass=person)(objectclass=organizationalperson)(objectclass=inetorgperson)(location
=Charlotte)) .][CIMSDsLdapProvider::ConstructSearchFilter][][][][][][][][]
[04/16/2008][11:25:34.192][IMS6DsLdapProvider.cpp:2893][7728][Search Root:
uid=wcotton,ou=people,ou=Dealer,ou=NeteAuto,dc=ca,dc=com, Search Filter:
(&(objectclass=top)(objectclass=person)(objectclass=organizationalperson)(objectclass=inetorgperson)(location
=Charlotte)), LDAP scope: 0, IMS scope 3][CIMSDsLdapProvider::FindIMSObjects][][][][][][][][]
[04/16/2008][11:25:34.200][SmDsLdapProvider.cpp:2039][7728][Ldap Search callout
succeeds.][CSmDsLdapProvider::Search][(Search) Base:
'uid=wcotton,ou=people,ou=Dealer,ou=NeteAuto,dc=ca,dc=com', Filter:
'(&(objectclass=top)(objectclass=person)(objectclass=organizationalperson)(objectclass=inetorgperson)(locatio
n=Charlotte))'. Status: 1 entries][][][][][][][]
[04/16/2008][11:25:34.200][IMS6DsLdapProvider.cpp:2917][7728][Number of DNs returned
1][CIMSDsLdapProvider::FindIMSObjects][][][][][][][][]
[04/16/2008][11:25:34.200][IMS6LdapRules.cpp:578][7728][Leave function
CIMSDsLdapProvider::findManagedObjects][CIMSDsLdapProvider::findManagedObjects][][][][][][][][0]

As always, questions, comments or concerns?  Feel free to reach out to us at IDMWorks.

Novell IdM – Implementing Remote Loader on Microsoft Windows

Tuesday, August 2nd, 2011

When implementing Novell’s (or NETIQs) Identity Manager product there are times when a certain connector(s) must be run on the MS Windows platform. If Meta-Directory Engine is running on a Linux (or other non-Windows) platform the requirement is the use of the Remote Loader. When asked if it is better to run the Remote Loader on a Windows Domain Controller or simply on a Windows Member Server, the answer is to run it on a Member Server for several reasons:

  1. Most organizations maintain a very controlled environment particularly when it comes to what is installed on Domain Controllers.  Most organizations will not allow a service such as the Remote Loader (RL) to run on said Domain Controllers.  As a result it is generally required, due to policy, to run the Remote Loader on a Member Server.  
  2. Additionally, through experience, we have found over the years that due to patching and security controls that take place specific to Domain Controllers it becomes more efficient, in terms of over-arching stability, to run the RL on a Member Server.  
  3. Lastly, the separation of duties between the Active Directory team and the Identity Management team generally makes life easier to manage the RL if it is running on a Member Server (i.e. less political).

Another advantage of running the RL on a Member Server is the ability to run the RL in a clustered environment. Member Servers may be configured in a Microsoft cluster with instrumental registry keys for password synchronization configured as a clustered resource.  This will allow the Domain Controllers to communicate with the clustered resource for password synchronization to the Identity Vault and it will allow the Identity Vault to do the same.  This is a configuration that is supported by both Novell and Microsoft and is considered to be the best way to provide password synchronization failover.

Questions, comments or concerns?  Feel free to reach out to us at IDMWorks.

The Novell Acquisition Conundrum

Wednesday, July 27th, 2011

With the recent purchase of Novell there has been a lot of discussion as to whether or not purchasing Novell technology is a good investment for your business.  There are legitimate concerns that an organization must take into consideration when investing in technology from a company that has just been acquired.

  • Will the technology continue to be developed and sold?
  • Who will provide support?
  • Will the quality and functionality of the product be maintained by the new organization?

As an old school Novell Identity & Access Management solutions SME I’d like provide a little perspective based on my own experience with Novell over the years.

The first thing I want to point out is this is not the first major merger Novell has been through.  In 2001 when Novell merged with Cambridge Technology Partners (CTP) there were many of the same questions.  While Novell was the company acquiring CTP it was not a typical merger as a large portion of CTP upper management was being infused into the combined company (including CTP CEO Jack Messman).  Many of the same challenges that Novell faces today were faced during that merger in terms of educating management on what the product offerings were and what the benefit to the customers that those offerings provided.  There was also the combination of sales force and education of said sales force.  Additionally there was the merging of the company cultures that is a challenge whenever any two organizations combine.  Obviously each merger is different and successfully merging once does not guarantee the same result the second time but there is experience within the organization in merging that hopefully will lead to success this time around.

But what about your organization?  Is Novell technology a good investment?  The technology produced by Novell is still a potentially good investment.  Novell produces a number of excellent technologies including SLES and ZenWorks however I’d like to stick with what IDMWorks implements and that is the Identity Manager suite of products.  Novell IDM is a very mature product that has a multitude of implementations.  Novell technology has a large, well established community of expertise.  There are many Novell partners (such as IDMWorks) which can implement and provide support for Novell technology.  Additionally Novell IDM solutions are largely based on industry standards such as XML, SAML, REST, and ECMAScript so we can train internal staff to self-support your Novell solution.

While a merger always puts a question mark over a company there is a good history at Novell with best-in-class technology offerings that has wide support in the industry.

But feel free to reach out to us at IDMWorks and we can talk options, fit or not, Novell or another vendor, as a vendor agnostic IAM services firm we can and will present a case for a multitude of options.  Get to know peace of mind.

Novell Identity Manager Workflows – Combo Box Iteration

Tuesday, June 14th, 2011

**NOTE: As with all Tips and Tricks we provide on the IDMWorks blog, use the following AT YOUR OWN RISK.  We do not guarantee this will work in your environment and make no warranties***

Identity Workflows…over the years we have seen a number of workflows developed.  Most were pretty straightforward.  There was a request form, an approval form or two, and an entitlement/role/resource activity action before closing out the workflow.  Every once in a while there might even have been an integration activity thrown in along the way to just make things interesting.  But from time to time there is a requirement that users can select multiple items from a picklist and then the workflow has to perform separate actions for each item selected.

This is a bit more challenging.

There isn’t a predefined activity in Designer to do anything remotely along the lines of a action based per item picklist.  As a result you must build this process manually.

So let’s take a look at how to do this in Novell IdM.

First the good news!  This is not an overly complex process but does have a few pieces to it as seen below:

  1. Determine where in the workflow you want to start this process and add a “Mapping” activity.
  2. Map the expression “flowdata.getObject(‘<fieldName>’).size()” to a new flowdata element.  This will be used to get our max count index or upper range.
    1. flowdata.getObject(‘<fieldName>’)” will return all of the items selected in the specified field.*Side note: depending on your version of Designer the “getObject” method may not be obvious but it can be manually entered using the proper casing to achieve the desired results*
    2. The “.size()” method will actually return the count of the items returned from the first part of the call so when put all together the “flowdata.getObject(‘<fieldName>’).size()” expression will return a count of only the selected items in the selected field.
  3. In the same “Mapping” activity set a value of ‘0‘ (zero) to a new flowdata element.  This element will be used as the counter element to show how many iterations have been completed.
  4. Next add a “Condition” activity.  This activity will compare the current counter value to the upper range to determine if another iteration is needed.  If the counter is less than the upper range (true) then continue iteration otherwise exit the loop to the next desired activity (false) .
    1. Sample: “flowdata.get(‘Counter‘) < flowdata.get(‘UpperRange’)”
  5. Along the “true” path from the “Condition” activity add another “Mapping” activity.  Map the expression “flowdata.getObject(‘<fieldName>’).get((flowdata.get(‘<counterName>’))*1)” to a new flowdata element.  This will get the value of the selected item at the current counter index, or position.
    1. Just like in the first mapping, the “flowdata.getObject(‘<fieldName>’)” expression will only return the selected values in the specified field.
    2. The “.get()” method will allow you to specify a position, or index, in the array of values from the first method to return a single value from the list.
    3. The “(flowdata.get(‘<counterName>’)*1)” expression will retrive the value of the current iteration count and multiply it by 1 to provide an integer value for the “.get()” method part of the expression.  This means that the string value of ‘0′ multiplied (*) by the integer of 1 will result in an integer of 0, which in an array of values means the first value.
  6. Now that you have the selected value you can perform whatever action is needed.  Most commonly I have granted entitlements, roles, and/or resources based on the selected value using the proper activity for the version of IDM being used.
    *Side note: Pretty much all supported versions of IDM and Designer at the date of this blog’s publication have an entitlement activity.  With IDM 4.0 and Designer 4.0 there is a “Role Request” activity for granting and revoking roles but resources must be individually granted or revoked using the “Integration” activity and the User Application WSDL which has the necessary web methods to perform the desired action.  Now in IDM 4.0.1 and Designer 4.0.1 Novell added a “Resource Request” activity that is similar to the other activities which make it very easy to grant/revoke resources through a workflow.

    1. After performing the desired action(s) it is time to increase the count.  To do this we need another “Mapping” activity.  In this activity map the expression “((flowdata.get(‘<counterName>’)*1)+1)+”" ” to the same flowdata element that was originally set to ‘0‘ back in Step 2, that way we keep the same flowdata variable name as our counter.
    2. Connect the “Mapping” activity from Step 7 to the “Condition” activity from Step 4 to complete the iteration loop.  This means that with each iteration the counter will go up by a value of 1 and as long as that counter value is less than the value of the number of selected items this loop will occur.  Once those values are equal or the counter is somehow greater the loop will exit and the workflow will follow the “false” path laid out from the “Condition” activity.

    And yes, you can add additional activities within the iteration loop.  It is very common to have various “Log” activities sprinkled through the loop outputting things like the current counter value, the current selected item value, etc.

    “Um…I think there is a flaw in your logic.  If I have three items selected wouldn’t I need my counter to be greater than 3 and not equal to 3 before exiting the loop?” No! While the “.size()” method gives you count of 3, this is just the count of items selected but when you iterate through the item list the list is actually considered an array so the first item starts at position 0, not 1 like counting does.  This means that the selected values of a pick list are read like this:

    1. List Item 1 = Array Index 0
    2. List Item 2 = Array Index 1
    3. List Item 3 = Array Index 2

    This means that as long as our index counter is less than our object count we can continue but once our counter is equal to or greater than our object count we need to stop.  If we had a count of three and tried to access Array Index 3 in the example above the workflow would encounter an error because no value of Array Index 3 will be found and the workflow would terminate.

    So as you can see it isn’t a difficult process to do, it just requires some careful mapping and pathing to make sure things go where they need to go and in the proper order.

    Questions, comments or concerns?  Feel free to reach out to us at IDMWorks.

    CA 12.5 SP6 Connector Express Group Membership via Virtual Attributes

    Tuesday, May 31st, 2011

    ***NOTE: As with all Tips and Tricks we provide on the IDMWorks blog, use the following AT YOUR OWN RISK.  We do not guarantee this will work in your environment and make no warranties***

    The CA RCM documentation is not very clear about how Reverse Association works and provides no guidelines on how to work with Virtual attributes, how they are mapped or controlled in Provisioning Manager.  Group membership provisioning from the account or user side can be accomplished in CA RCM Connector Express using Virtual attributes .  What this means is that if you have a user class (User Account)  and group class (Groups) you can provision the group member attribute with account members:

    In the above example, when the group membership is added to the user in the group membership attribute on the user, than the group member attribute is updated with the user account as well.  This is accomplished doing the following steps:

    1.  Map the User class. The user class contains an attribute that contains the DN of the group, in this example this is Group Membership, the type is Flexi-DN and the attribute may or may not be multi-valued
    2.  Map the Group class.  The group class contains a multi-valued attribute (Member) that contains the DN of the user(s).
    3.  Create the account to group direct association.  The user account physical attribute Group Membership the attribute that stores the DN of the group.  The Match attribute is the Groups naming attribute that is mapped as the required name for the group.

    4.  Create account to group reverse association.  The groups class group attribute must be a virtual attribute which is given a new account attribute name that does not exist in the group class, in this case I made the virtual attribute ‘vMember’ so that it is easily understandable.  The match user account attribute is the required Account ID attribute.

    5.  When you complete this, a brand new attribute will appear in the group attribute listing with the virtual attribute name.  In figure 1 you can see the vMember attribute in the group class and this attribute was created by using the reverse association step above and not created manually.
    6.  Repeat the group to account direct association.  Follow the same steps used for account to group with the values reversed and the groups member attribute and account Account ID attribute used.
    7.  Repeat the group to account reverse association.  The virtual attribute to create will be virtual of the group member (Group Membership) attribute which will be created in the account class.  the match groups attribute will be the name of group class.

    The completed associations should look like figure 1.  Two virtual attributes were created, the vMember created by the reverse association on the account class and vGroup Membership created by the reverse association on the group class.  You do not need to modify the virtual attribute in any way except to verify that the attribute is multi-valued.

    When you have completed the connector express configuration, created the new endpoint, and acquired the new endpoint you are ready to work with target in Provisioning Manager.  After you have Explored and Correlated the endpoint and mapped the endpoint on the Endpoints tab you can work with account and group membership as follows (notice the vGroupMembership and Group Membership tabs):

    • The Group Membership tab represents the users group membership in the users account (member) attribute.
    • The vGroupMembership tab represents the users group membership in the groups member  (Group Membership) attribute

    By adding the same searched group  in both these tabs you can provision the user account with a group membership and modify the group member attribute with the user account in the same operation.

    Membership is the attribute that stores the DN of the group.  The Match attribute is the Groups naming attribute that is mapped as the required name for the group.

    As always, questions, comments or concerns?  Feel free to reach out to us at IDMWorks.

    Novell IDM Entitlement DN & Stylesheets

    Tuesday, May 10th, 2011

    Entitlements can be a bit quirky in driver policies.  Drivers have the ability to add an entitlement from that driver to an object but they don’t have the ability to add a different driver’s entitlement or remove an entitlement through policy.  When a situation occurs where entitlements have to be added or removed that can’t be done through policy that’s when you call in stylesheets.  Stylesheets are flexible and powerful tools in the driver’s toolbox but they are not as user friendly and require advanced developer knowledge over standard policies.

    Stylesheets can suffer from an annoying issue if they contain hard coded object DNs in the XML.  The issue is that when the stylesheet is migrated from one environment to the next the object DN(s) aren’t detected correctly after migration.  I have seen it a number of times where an object DN is the same in a QA and Production environment, the stylesheet tests fine in QA, but when migrated to Production the stylesheet doesn’t execute correctly. And the odd thing is in this situation that when you review the driver logs the DN is correct in both the input doc and the stylesheet.

    The quick and dirty fix is just to copy the desired object DN from the input doc in the log, paste it in the stylesheet, and restart the driver.  Even though the values are the same this process corrects the issue and after a driver restart the stylesheet will operate as expected.

    There is a better approach to avoid this issue. As with most values, it is better to use variables instead of hard coding values like object DNs in your logic.  The cleaner, more reliable solution is to create a Global Configuration Variable (GCV) on the driver, or driver set depending on your needs, for each of the DNs and then just reference the GCVs in the stylesheets.  This allows the stylesheet to be migrated between environments without risking the DN values should they be different between environments or DN value recognition for hard coded values.

    Below is an example of how to reference a GCV in a stylesheet:

    <xsl:when test=”(component[@name='volume'] = ‘~Entitlement_DN_GCV~‘)”>

    Notice that the GCV is within the single set of quotes ( ‘ ).  This is a string value so when the GCV is translated to the actual value it will need to be treated as a string.  The key symbol here is the tilde ( ~ ) that encapsulates the GCV name.  This character symbolizes the use of a GCV so the driver engine knows to substitute the GCV name with the value stored in that GCV on the driver or driver set.

    And regardless of whether you are using stylesheets or policies it is always better to use GCVs for these types of values and avoid hard coding values.  It just makes life easier.

    As always, questions, comments or concerns?  Feel free to reach out to us at IDMWorks.

    CA Identity Manager High Availability & JBoss Clustering

    Thursday, April 21st, 2011

    Over the course of the last few years I have seen configurations of  CA Identity Manager for High Availability without using Application Server clusteringThis is no longer an accepted practice. My understanding is that CA will be publishing an official technical note to debunk the old practice.  As such I’d recommend the following:

    CA Identity Manager 12.x uses caching for transactions. The utilization of this feature can cause synchronization issues if the application is setup in a high availability mode without application server clustering.

    An example I can give is a project I was involved with using JBoss as the CA IdM application server.   As such I will be addressing JBoss clustering in this entry.

    JBoss uses a Hypersonic database to manage internal JMS data (JMS Queues).  JBoss uses the JMS queues for tracking tasks and processes within the application.  It is recommended to use a shared MS SQL database for the JMS database.  There are documents available online which explain how to migrate from Hypersonic to MS SQL.  In my example we opted to use the same MS SQL infrastructure used by Identity Manager to house the JMS database. In simplified terms, the steps to accomplish to clustering of IdM on JBoss is as follows:

    1. Create a new SQL database (JBOSS_JMS)
    2. Create a user/owner for this DB (jbossjms)
    3. Migrate JBoss to SQL from the Hypersonic DB
    4. Bring all services back up and test to ensure the migration was successful
    5. Follow the procedures in the IdM documentation to configure JBoss clustering

    Note: It is not recommended to configure both the migration and clustering all at once. It would be much easier to troubleshoot one major change at a time.

    As always, questions, comments or concerns?  Feel free to reach out to us at IDMWorks.

    Password Management in Novell Identity Manager

    Tuesday, March 29th, 2011

    Novell Identity Manager integrates tightly with Novell eDirectory. Part of the benefit of eDirectory is the inherent security built around passwords.  But there are times that Novell’s native tools for managing passwords do not meet the specific needs of the deployment. So let’s briefly explore the options you have for managing passwords within the framework of Novell’s Identity Manager.  For the purposes of this article password management is defined as the ability for a user to set a password, set challenge/response questions and use those challenge response questions to reset a forgotten password.

    The first option, and probably the easiest to implement, is to use Novell’s Role Based Provisioning Module (RBPM) formerly known as the User Application.  This tool is easily deployed and fully supports all of the password management functionality.  It is can be branded and is fully supported by Novell.  The drawback to the RBPM is that it may be more than some organizations need when they are looking for just password management.  Additionally an organization may have an existing portal deployment that they want to integrate password management into. RBPM may not be the best fit for these organizations.

    Another option is to utilize Novell’s Password Management Framework from their custom development group.  This is a fully functional password utility that is specifically tailored to an organization.  It is supported via Novell’s custom development group and fully supports all of the password management functionality.  The disadvantage of this solution is the additional costs associated with the purchase, development and support of the solution.  It can be integrated into an organizations existing portal solution and is fully supports branding specific to an organization.

    If the functionality of Novell’s Password Management Framework (PMF) is what an organization is looking for but they do not wish to make the additional investment in product, support, etc… then a viable option is an open source project called PWM (available at https://code.google.com/p/pwm/).  This solution is very comparable to Novell’s PMF.  An organization may deploy it as is or customize it for their needs.  The advantage of this solution is the reduced product costs.  The disadvantage of this solution is that the organization is essentially self supporting themselves with this solution.  Just as the solutions above PWM fully supports all of the password management functionality.

    In RBPM 3.7 there is also a forgotten password web service that is available (http://server:port/warcontext/pwdmgt/service?wsdl).  This is a good way to access basic password reset functionality.  This service does not support all of the password management functionality.  However it is a good option for organizations familiar with writing to web services and only need the basic forgotten password operations.

    For organizations that desire the web service approach but need fuller functionality than what the basic web service interface provides there is in RBPM 3.7 REST services available.  The functionality for the REST services is contained in a war file (RIS.war) that sits separate from the User Application and provides access to much more than just the password management features.  The REST services are fully documented in Novell’s RBPM 3.7 online documentation.  This solution can be integrated into an organizations existing portal framework or can be used to build a fully functional site that exposes specific functionality that an organization needs.

    There are other options for integrating with Novell’s Identity Management solution for password management that utilize Novell’s APIs.  But in the opinion of this consultant the above listed methods are the most cost effective options and provide the functionality that most organizations need.

    As usual if you have questions, comments or concerns feel free to reach out to us at IDMWorks.