Page History

...

Authentication/authorization component

The wbauth component handles the nginx auth_request and simply returns 2xx, 401 or 403. It can set and check for the presence of a cookie (e.g., wb_auth) and delegate to another configured authentication module.

• wb_auth cookie
  • Same as JWT
  • Encodes user 
• Checks for the presence of wb_auth cookie (e.g., token)
  • If cookie present
    • Confirms that token is valid
    • Confirms that user has access to requested resource
      • e..g, sxxx-studio – must lookup stack ID and confirm user has access to namespace
    • If valid
      • returns 200 (updating token)
    • If not valid
      • Returns 403
  • If cookie not present
    • Delegates (proxies) request to supported auth methods

LDAP provider

The LDAP provider would support authentication using an existing LDAP server, such as NCSA LDAP. 

• wbauth is configured to use LDAP provider
  
  • server: ldap.ncsa.illinois.edu
  • port: 636
  • use SSL
  • user base dn: ou=People,dc=ncsa,dc=illinois,dc=edu
  • search filter : (&(objectClass=inetorgperson)   (|(memberOf=cn=prj_isda,ou=groups,dc=ncsa,dc=illinois,dc=edu)(memberOf=cn=isda_external,ou=groups,dc=ncsa,dc=illinois,dc=edu)))
• Need to define what it means to sign-up for workbench or if this is basically the oauth scenario (i.e., anyone who logs in is signed-up, pending approval).  Options include:
  • LDAP configured with allowable groups only, members of the group are allowed in.
    • Configurable sign-in URL (https://identity.ncsa.illinois.edu)
  • We could have a sign-in page to push the user through the usual approval process. This would overcome the "opensource" problem where you can sign-up for an opensource account but need to know to ask to be added to JIRA, HipChat, etc.  In this case, the user still signs in with their NCSA identity, but it pushed through an approval process. 
• Instead of storing the password in etcd, we would delegate authentication to LDAP. This would allow us to synchronize information (e.g., groups) at each login
• Could also follow the pattern of automatically sync'ing LDAP accounts (ala Atlassian or OMD)
• Using the posixAccount object, we can optionally get UID/GID information and use this to run containers.  The runAsUser feature appears to work without question. However, groups are a different problem.  The fsGroup feature appears to be limited to certain storage options (e.g., not hostPath), so would force us to move to another storage model (which we want, anyway).