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

Compare with Current View Page History

« Previous Version 2 Next »

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.

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.
  • 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.

We need to come up w/ISDA requirements and then negotiate w/NIST. Then we determine our next steps -- either realign our schedule or do our own thing after consultations w/OIS. We could create a new service and then hand it over to NIST.

We could have this discussion w/NIST by having a working prototype. We would like some hands-on info from actual experience and experimentation, no problem w/informing NIST of this. We are generally getting into the business of doing R&D and then rolling out to NIST in other areas (Touchstone, VMS, etc).

Key is to have the requirements. Determine they can do it, or what they have in dev can do it, and only after that figure out who will do it if they cannot.

Steve still wants hands-on experience about the LDAP "bridge", orthogonal to issue of who does what.

Why not engage w/NIST first?

Driven by Clearspace needs. Why not do Clearspace integration against ldap.mit.edu?

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.

Proposed process: Answer the questions first, then engage w/NIST, then try to set it up test integration, then discover the problems.

Is this path acceptable to CCS?

We need to identify a date at which we evaluate. Unclear if the organizational need to go thru OIS first is worth slipping the project to next year -- need a checkpoint date at which to determine that.

Need to get Clearspace requirements, Carter to set up meeting w/Mike, Paul, and Clearspace. Next week is not possible for arch's due to CSG.

Most apps don't really understand how they are using LDAP. Can we get a 2-3 customers using Clearspace in LDAP mode (preferably higher ed) to find out their experiences.

Action item: Carter to set up meeting w/Clearspace technical resource (developer) to discuss LDAP integration for Monday afternoon. Include archs, sml not available, mmoretti not available, invite dtanner

Action item: ask Qing to collect LDAP docs on Alfresco, schedule a call if necessary (Thalia needs resolution by Sept)

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.

  • No labels