Page History

A1

Implement infrastructure within Grouper & Signet to enable independent extension of key internal events. Pre- and post-processing hooks will be provided for each "primitive API operation".

This would make many other tasks more feasible.

A2

Propagate group, membership, or privilege changes to the infrastructure and consuming applications. Depends on A1.

Includes support for email notification of changes.

Addresses (near) realtime & incremental provisioning needs.

A3

Build on XML import/export architecture to define functional services that could be wrapped as a Web service interaction (e.g., SOAP). Provide for wider integration of group & privilege services into applications and enterprise integration infrastructure. In particular, simpler or embedded UIs are made more feasible by reliance on this interface.

A4

Determine which subsets of native API capabilities should be exposed through more focused end points to facilitate access by applications to Grouper- and Signet-provided access management capabilities. Also investigate how facades may be used to manage access to underlying group and privilege management and query capabilities.

A5

Gain clarity on types of audit requirements to be supported by Grouper, and whether their support should be enabled per group, per naming stem, or categorically. Build on the hooks or change notification infrastructure of A1 and A2.

Develop an EDDY agent to send events into an external infrastructure that supplies persistence and analysis services.

A6

For Signet, support automatic activation of privileges when prerequisites are met, and automatic revocation of privileges when conditions are not met, typically based on changes in a person's status and affiliation.

For Grouper, automatically deactivate or reactivate groups and memberships.

A7

1. Identify/implement a framework in which combinations of I2MI components (currently Grouper API, Grouper UI, Signet API, Signet UI, Ldappc, and Subject source adapters) can be easily integrated (not just in a single JVM). This is largely an issue of managing configuration and 3rd party libraries.

2. To the greatest extent possible, ensure that I2MI components use same means for achieving same ends, using the same configuration files for common purposes.

3. Provide a demo Subject database common to all quickstart or demo packages.

A8

Complete the work that's underway. Includes utility wrappings to support command driven and scripted interactions.

Provide support for handling assignment & privileges changes that result from metadata changes.

B1

The hierarchy of naming stems in a deployment will change over time. Although the XML Import/Export tool supports prune & graft, for large changes that could take a while and be disruptive. Ability to logically "move" or "copy" a group or a selection of groups from one naming stem to another would be superior.

B2

Enable deletion of memberships or privileges held by subjects no longer resolvable in any subject source.

B3

Finalize the definition of v1.0 of the Subject API. Enhance the JNDI and JDBC reference implementations accordingly. Restructure how source adapters are configured and initialized to completely decouple the reference implementation from 3rd party implementations (especially, change the current role played by the SourceManager in this regard).

B4

Wait until the "Notification of changes" task is complete and then adapt Ldappc to propagate changes to groups and memberships. Provide configurable capability for assembling values of a privilege attribute.