Following features and enhancements are new in Release 1.1:

• New forgotten Password Architecture
• Configurable Timeouts
• Dynamic Attributes
• SPML Client-side Authentication
• Disable mis-configured Services and Contexts
• Remove Dependancies On "default" Context
• Added support for SPML objectclasses
• Context ID added to messages

New Forgotten Password Architecture:

Problem

The previous release used a two-step process to handle forgotten password. The first step called the Service to obtain the Forgotten Question. These questions were then presented to the user (UML / Portlets / Samples) and the user would provide the answers. The second step involved contacting the Service a second time to obtain the answers to the questions. Then the users responses were compared with the second response. This was fine as along as the the first and second calls to the Service always returned the same related data. This did not work when the Service randomly returned different questions/answers each time it was contacted. This was the case with the Sun Identity Manager, it was configured to randomly return different questions/answers.

Solution

The Framework was modified. When the Consumer-Tier application (UML / Portlets / Samples) now initiate the forgotten password process, the Framework makes a single call to the Service and it stores both the questions and answers internally. When the user responds to the questions, the APIs compare the users input to the answers that are internally stored.

Configurable Timeouts:

Problem

Some Operations for certain Services were getting timeouts from the infrastructure. Handling of the timeouts, and related Exceptions were not ideal.

Solution

The Framework was enhanced to support the configurable timeouts per Operation, per Service. Configuring the timeout values is done by setting values in the openptk.xml file. If no default timeout is set, then 5000 milliseconds will be used. This new feature uses the Java concurrent facility to implement timeouts.

To enable this feature, the classname must be set to org.openptk.provision.common.TimeoutContext for each Context.

<Context id="Person-SPML" classname="org.openptk.provision.common.TimeoutContext">
  <Subject id="Person"/>
  <Service id="SPML">
    <Properties>
      <Property name="url" value="http://sample.openptk.org:80/idm/servlet/rpcrouter2"/>
      <Property name="objectclass" value="user"/>                    
    </Properties>
  </Service>
  <Query type="EQ" name="MemberObjectGroups" value="All People"/>
</Context>

To set a Service timeout value that will be inherited by all of its Operations, set a Service level Property

<Service id="SPML" ...>
   <Properties>
      <Property name="timeout" value="5000"/>
   ...
</Service>

To set a Operation timeout value (within a Service), add the timeout argument to the Operation.

<Service id="SPML" ...>
  <Properties>
    <Property name="timeout" value="5000"/>
    ...
  </Properties>
  <Operations>
    <Operation type="create" />
    <Operation type="read" timeout="2000"/>
    <Operation type="update"/>
    <Operation type="delete"/>
    <Operation type="search" timeout="2000"/>
    <Operation type="passwordChange" timeout="8000"/>
    <Operation type="passwordReset" timeout="8000"/>
  </Operations>
  ...
</Service>

In the above example, the follow logic will be used ...

• The default timeout for Service will be 5 seconds.
• The create Operation_ will inherit the default value, 5 seconds.
• The read Operation will use a smaller value, 2 seconds.
• The update Operation will inherit the default value, 5 seconds.
• The delete Operation will inherit the default value, 5 seconds.
• The read Operation will use a smaller value, 2 seconds.
• The passwordChange Operation will use a larger value, 8 seconds.
• The passwordReset Operation will use a larger value, 8 seconds.

Dynamic attribute definition:

Problem

The Attributes defined in a given Subject and a given Service may not match. There were runtime issues when a Service would define a given Attribute that the Subject did not have. This issue led to the creation of multiple (similar) Subjects that matched a given Service. This quickly became difficult to manage and limited the idea of re-useable Subjects.

Solution

The Framework, during initialization, will evaluate the defined Contexts and determine the "run time" set of available Attributes. The Subject (for a given Context) may have 15 Attributes defined. The Service (for the same Context) may only have 10 Attributes defined. At most, the Context could not have any more than 10 Attributes available at run-time. The actual available Attributes for the Context will be the "intersection" of the defined Service Attributes and Subject Attributes. Only the Attributes (names) that match between the Service and Subject will be available to the Context.

SPML Client-side Authentication:

Problem

The SPML Service supports the standard SPML APIs. This API does not address access control (Authentication) to the SPML interface. Sun's Identity Manager supports the standard SPML API by storing the credentials of a "proxy user" on the deployed server. For many organizations this is a security issue. There are requirements to support client-side authentication the the SPML service.

Solution

Sun's Identity Manager implements the standard SPML capabilities and offers an extension this standard by providing a SPML implementation that supports client-side authentication. A new Service was created that sub-classes the SPML Service. The new Service is called org.openptk.provision.spi.SpmlSunService. To leverage this feature create a Service that uses this class:

<Service id="SPML-Sun"
         classname="org.openptk.provision.spi.SpmlSunService"
         description="SJS Identity Manager Lighthouse client"
         sort="lastname,firstname">
   ...
</Service>

Configure a Context to use the Service and then set Properties that define the client-side "proxy-user" accountId and Password:

<Context id="Person-SPML-Sun" classname="org.openptk.provision.common.TimeoutContext">
  <Service id="SPML-Sun">
    <Properties>
      <Property name="user.name" value="SPML-Proxy"/>
      <Property name="user.password" value="password"/>  
      ...           
    </Properties>
  </Service>
  ...
</Context>

Disable mis-configured Services and Contexts:

Problem

The Framework configuration file (openptk.xml) can be modified to include collections of Services and Subjects that are combined to create multiple Contexts. It was possible to configure Services and Contexts that could not be used (for various reasons). Run time errors occurred when applications tried to access an invalid Context.

Solution

During initialization of the Framework, Services and Contexts are checked to ensure that their Framework and Service classes can be found and instantiated. If either a Service or Context does not pass basic requirements, the Service and/or Context will not be created and thus unavailable to applications. Note: These tests do not validate / check the actual "back end" infrastructure. A Context and Service can still be initiated and have a related infrastructure that is off-line.

Remove Dependancies On "default" Context:

Problem

The Framework used the "default" Context for some core internal feature ... it was assumed that the "default" Context would always be properly configured and available. When the Disable mis-configured Services and Contexts feature was added, it was possible that the "default" Context may not get initiated. Without a "default" Context, the Framework would not start.

Solution

The Framework's core features were re-written to no longer depend on a "default" Context.

Support for SPML objectclasses:

Problem

The Framework did not explicitly specify and objectclass for SPML operations, and therfore, used the "default" SPML objectclass defined on ther server. This did not allow the ability to operate on objectclasses other than the default in the openptk through SPML (examples: user, speperson, BasicUser, role).

Solution

The SPML Service was enhanced to no longer depend on a "default" SPML objectclass. If an objectclass property is supplied in the Context definition in the openptk.xml file, it will be used for all operations on that context. Note: This is not used for the change password and reset password operations since they are extended operations and do not use the objectclass. For this reason, the speperson objectclass does not currently support change password and reset password. A subclass of the SPML service will be created for a future release which will support SPE change and reset password.

Context ID added to messages:

Problem

Messages sent to Consumer Tier applications and written to log files do not contain information about the Context (context id). It was hard to debug problems that are Context specific issues.

Solution

The Context ID has been added to many of the debug / info methods that output information. The Context ID will make it easier to determine if a problem might be related to the Context that is being used.

Resolved Issues:

Known Issues: