sml -- I reformatted Catherine's notes into concrete requirements and tasks for the team. Some of these will copy to the Product backlog or into specific Sprint documentation.
Important Dates
June 15: Clearspace environment setup, tentative experiments connecting to an existing LDAP directory operated by NIST, determination of "least amount of work" path, recommendations
Clearspace to QA: July 15
Clearspace production date: August 1.
Questions to Answer for ISDA Lead Architects
- Do all or some of our target products insist on using LDAP for authentication if they are configured to use LDAP for access control?
- The MIT Way is that we cannot use LDAP for authentication.
- If we can decouple access control from authentication, is that really less work than customizing the product to work with our ID web services?
- Since we have to customize to integrate with Touchstone, are we really saving any work?
New Requirements
- Target products cannot use LDAP for authentication and they must use Touchstone.
- The LDAP connector cannot front for another authentication mechanism, it cannot receive passwords from an end user.
- ISDA Mgmt makes the assumption that we should use ldap.mit.edu
- We must test using ldap.mit.edu or the Active Directory LDAP before we attempt to use the penrose facade.
- We likely will not be allowed to use any new ldap service/protocol, even if it is a facade or abstacted interface like penrose
- The two key requirements to which this project must play are:
- real time updates of users and ACL
- Incorporation of external users (touchstone)
Impediments: Product Owner Tasks (Steve Landry and Possibly Derek Jaeger)
- Delta the LDAP requirements for Clearspace, Confluence, AlFresco, and Stellar
- Hand these off to Michael Gettes and Paul Hill to negotiate with NIST
- issue: products that use LDAP for groups also expect to use it for authentication.
- De-coupling would require customization.
- Would this be less customization than would otherwise be needed to hook to Moira directly?
- to do: Enumerate requirements of 3rd party apps to use LDAP w/o modification.
- Specifics: how does the app bind? how does it handle groups? (nested, static, dynamic, etc), etc.
- key requirements: 1.) real-time updates, 2.) incorporate external users
- Assumption should be that we use an OIS LDAP
OIS has 4 LDAP servers used for different purposes (one to support Techtime, ldap.mit.edu as an address book for email (used by Touchstone, no non-MIT users), Active Directory for Win domain, Exchange)
OIS plans to update ldap.mit.edu, looking for guidance from ISDA. Issues include no server data.
...
Can we specify the app requirements for NIST without doing any empirical research?
Research should be limited to trying to hook app up to an existing ldap (pbh suggests Active Directory, which is more realtime than ldap.mit.edu)
Unless you try it you cannot know if it will work for sure.
...
Action item: gettes to approach Confluence (no hard deadline)
Schedule points:June 15: Clearspace environment setup, tentative experiments connecting to an existing LDAP directory operated by NIST, determination of "least amount of work" path, recommendations
Clearspace to QA: July 15
Clearspace production date: August 1.
Action item: LDAP discussion to continue -- pbh to schedule further meetings of involved parties.