New features: Following features and enhancements are new in Release 1.1:
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 ...
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: |
Release 1.x >