Vision
The next generation of the collaboration platform will do far more than wikis or chat. ISDA wants to use the Clearspace product from Jive software as the base platform for customized collaboration products. The first product to use this platform as its base is Teamspaces, sponsored by the CCS team, for use in a Courseware context. IPS will use this project as a launchpad to understand the Clearspace application not just for this particular implementation, but for use in future products as part of the MAP set of application-platform components.
The IPS mission on the Teamspaces project is to take the baseline Clearspace product and determine that it integrates into the MIT environment with an acceptable level of simplicity. I needs to run in hosting environments that MIT provides to departments, it needs to integrate with user and group data, and work with all our existing authorization and authentication mechanisms. It must be an application that IPS has the skills to assist other developers in implementing.
Backlog
- 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.
- Include external users
- include external users in group, get attributes (from CAMS?)
- 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.