Per  NDS-1005 - Getting issue details... STATUS


NCSA LDAP

The following diagram is from a discussion with Nathan Tolbert (ITS) about integrating with NCSA LDAP system. This is driven by the usual TERRA-REF use case: we want users of the TERRA-REF system (Workbench, Clowder, ROGER, Globus) to have a single identity with shared UID/GID for filesystem access across all three systems.  ROGER currently uses NCSA LDAP for authentication and authorization (via groups)

wb-ldap

Notes from discussion:

  • NCSA identity allows anyone to sign-up, access to resources is controlled through internal tools (e.g., Savannah). 
    • Because of this, authentication is not sufficient for authorization (same as any Oauth provider)
    • There is a group called all_disabled_users that contains users that should not have access to anything for one reason or another
  • Kerberos supports authentication only
  • LDAP implements two standard models: inetOrgPerson and groupOfUniqueNames
  • LDAP delegates authentication to Kerberos and provides Linux UIDs and GIDs, but cannot provide detailed ACLs
  • There are many many users, so filters/paging are essential when querying
  • Many systems tie directly to LDAP, e.g., Atlassian suite.  These use LDAP for users and groups that can be mapped to application-specific ACLs
  • For TERRA-REF case, LDAP integration would be sufficient (no need for OIDC/SSO as long as all services use LDAP

CILogon/CoManage

Notes from ad-hoc meeting with Jim Basney on 9/29

  • There is no standard to support group membership via Oauth/OIDC.  Scopes are available but inconsistent
  • CILogon can provide isMemberOf scopes from LDAP providers, if available on a per-client basis
  • Globus Auth has better documentation about use of scopes and groups


  • No labels