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

Compare with Current View Page History

« Previous Version 8 Next »

Very rough requirements, not exactly matching the "user stories" metaphor of Scrum.

IPS topological and architectural requirements with phased plan here

  • Real Time Updates
    • When an end user updates a system of record (Moira, Touchstone), that change is reflected by the LDAP query, and therefore client applications, in real time.
  • No replication of user or group data.
    • This LDAP implementation will be a facade that appears to be an LDAP database but, in fact, fronts for proprietary interfaces without another LDAP data store.
    • In its final state, mapldap.mit.edu will have no data store.
  • Finiite integration context
    • We are providing LDAP connectors to more efficiently use off the shelf products within ISDA.
    • Requirements will continue to be derived based on Clearspace, Confluence, Alfresco, and Stellar, only.
    • A generic, reusable nature is a good goal but there is no requirement to design with intent to provide a community-wide service.
  • A developer accesses LDAP connectors without needing to understand the local Moira internals about proxies.
    • A system that calls the LDAP connector does not have to pass a Moira proxy along, unless standard LDAP provides an analogous metaphor.
  • A client application sends a user ID and a group and the system returns a positive or negative result about whether the user is in the specific group or not.
    • This works for groups where the developer or client application is not allowed to list every member of the group.
  • A client application sends a user ID and a group and the system returns an enumeration of that group's membership, subject to who the user is and the group's privacy attributes in the system of record (e.g. Moira's 'visible'/hidden' attributes).
  • A client application sends a user ID (presumably the currently authenticated user) and the system returns the groups that user belongs to
  • A client application is able to get all MIT users and their group affiliation, including all non-MIT/guest accounts and all affiliations and statuses.
  • The team must follow all existing business rules for users, group membership, status, etc. This project will not attempt to "fix" any business logic or processes related to managing user identity, other than providing a clean, real-time connection to identity information for client applications.
  • The Application Administrators must run LDAP on existing systems.
    • No new systems are requisitioned for this release.
    • They can use the existing web-services hosting environment, the existing console/instrumentation system, and others.
    • The timelines for Touchstone external users are the only dependency.
  • And end user must go to an external system (Moira, Accounts, Touchstone, Stellar) to administer users.
  • No labels