Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Design Meeting - 2008-11-05

Attendees

1. Dave Steiner ~steiner
2. Nancy Mond
3. Dmitriy Kopylenko
4. ~battags

Functional Goals

Term Definitions

  • System of Record - Authoritative source of information. Responsible for providing accurate information.
  • Downstream System - Systems that are fed from the OpenRegistry. Rutgers is looking at scoping this to only include systems that things belong to the Identity Infrastructure. Other systems that need data should look to standard APIs such as LDAP.

Design Goals

  • OpenRegistry will be an open standard-based system. Standards such as SOAP, REST, etc. should be used wherever there will be interaction with non-OpenRegistry Systems.
  • OpenRegistry will be loosely coupled. This means that common interfaces will be provided that can be used to substitute components.
  • A Database Abstraction layer will be utilized to abstract the database specific needs.
  • System will be extensible and general enough that deployers can utilize extension points to add their own additional needs and capabilities to it without modifying the system source code for common use cases.

Open Questions

  • Are we going to have a Business Rules repository? Business Rules seem like a generally useful thing to have at the University but may be outside the scope of identity data (one can imagine non business-rules identity-data). The OpenRegistry system may benefit from having a pluggable rules engine system that can use an external University-defined Business Rules Repository/engine but may also just rely on something such as a rules engine.
  • Permissions Repository - hold all permission data and push out to system as needed? i.e. populate LDAP ACLs from permission data Permissions should include privacy information.

Implementation Details

  • Messaging Queue for downstream systems to poll for retrieving updates. This may be a system such as LDAP or a deprovisioning tool watching for specific items.
  • Audit Log should be specific enough that we can track redo, undo and troubleshoot, whether its automatic or manual.