Reference‎ > ‎Meeting Minutes‎ > ‎

Minutes: 2009-10-12

Notes from Monday, October 12th, 2009 OpenPTK Owners Meeting


  • Scott Fehrman
  • Derrick Harcey
  • Terry Sigle


  • Update on V2 development progress
  • Open issues Review
  • Identify tasks from the wiki that need to be created as issues
  • Tasks and priorities
  • Design Discussion
    • Client API
    • Authentication (client validation)
    • Authorization


Update on V2 development progress

Scott described the status of the server development status. Refactoring of xml and JSON was completed to support changes needed for the client library. Bidirectional conversion of xml and json, and less configuration of the converter options. A decision was made to use a different xml parser: stax. This has made the code required much simpler and added automatic escaping of the content. This is now being used for both the inbound and outbound REST. This is bundled with the java 6. If Java 6 is not used, additional jar file must be bundled.

Sample code for the client API for all operations.

Ported the tag library for the new client API. A new tag for a connection was created. create, read, update, and search are updated, password samples not yet updated..

Updated the command line ant build process. Shell scripts to run the test harness are available.

CLI enhancements now uses an interactive console, all operations are functional (using the 1.x API). This is now using the Jline ( open source package for the interactive shell for the new console. This is on hold until the client API is completed so if can be migrated to use it.

Started considering options of the packaging for the downloads.

Started an UnboundId Service for LDAP. Open discussion on where to put the service.

Authentication refactoring has been complete to use the openptk.xml file. There are several configuration options. One example is the ability to setup global defaults for authentication.

For each client configured in the openptk.xml file, authenticators, each with authentication levels, are defined. These are iterated over in order as chaining for the authentication. A default client name is configured to allow a global clientname to be used if one is not supplied to the server. This global configuration will typically be used for enabling anonymous access.

Client validation design is in process. This development has started but has several issues to resolve.

The authorization design documentation has been started. This design has been planned for a long time and will leverage the session types (ANON, USER, SYSTEM) which is already in place and allow the authorization of:

  • inbound requests
  • outbound responses

A design page has been updated with the requirement details for the authorization

Scope of control for fine grained authorization.

User interface - the user interface refactoring and layout has been significantly updated.

  • Accordian for search results
  • tabbed interface for user details
  • modal dialogue for orgtree like viewing of reporting information
  • Cross browser: config interface tabbed layout of Context, Engine, and Clients resources will drill down

work yet to be done on the server UI:

  • migrate to prototype events for all user interaction
  • migrate to prototype object for all subjects
  • add validation logic everywhere

Response Codes and Error Handling for all operations in both REST and the web ui.
Error response codes need to be address globally consistently. In some cases, more detail is requires.

suggestion: add an additional wiki page for error conditions and a sub document for REST, and other type.

Open issues Review

Identify tasks from the wiki that need to be created as issues

Agreed to migrate existing Developer Task List to be issues on

Design Discussion

  • Client API
  • Authentication (client validation)
  • Authorization

The packaging of the client framework will require refactoring of the framework to minimize a client deployment. Several jar files will be used to distinguish between the client, common, and server portions of the framework.

DNS Server forwarding strategy - Status

Server Hosting of is being setup in the AWS Cloud this week. A notice will be sent to the owners when this is ready.