Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

Design Meeting - 2008-11-05

Attendees

1. ~steiner
2. ~nmond
3. ~dima767
4. ~battags

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.
  • Batch, Real-time, and Web Interface. Real-time could be REST, SOAP, JMS, etc. Web Interface is a UI for entering data in real time, using the OpenRegistry as a system of record.

Full Scope

  • Support updates via: batch, real-time (system-to-system), web interface (manual input)
  • Perform following input processing: 
    • normalization
    • reconciliation
    • generate attribute data based on rules
    • populate repositories based on rules
    • provide identifier assignment for new individuals
  • Provide services:
    • accept data from SORs
    • expose data to downstream systems feeding identity infrastructure
  • Provide permssion model for privacy policy enforcement
  • Provide audit capability that may be used for trouble shooting and manual/mechanized error correction.

Release 1 Scope

  • Focus on Guest Management
    • Is Real-time Interface needed at this point?
    • Batch and Web UI appear needed
    • Input Processing may be simpler
  • No labels