Opened 8 years ago

Last modified 5 years ago

#322 new enhancement

Unauthenticated list membership API

Reported by: adehnert Owned by:
Priority: normal Milestone:
Component: misc Keywords:

Description (last modified by adehnert)

Many of our users would like to synchronize authz in their application with authz managed through moira lists. (Indeed, we'd probably like to do that with Trac --- We also have a FAQ entry about doing this with Mediawiki --- At the moment, I believe that requires either making your list an NFS group to use LDAP (which people dislike, given the group quota), using pts mem -noauth (which is vulnerable to a MITM), or juggling tickets and tokens to use pts mem with authentication.

If such a service already exists (a stable-ish looking LDAP server supporting SSL, for example), awesome. We should document it, and make sure our FAQ entries use that, not pts mem -noauth.

If not, we should write some service that uses an integrity-protected channel to get moira list membership and returned it to users. (One option would be a setuid program that basically just aklog'd with some principal it had access to and ran pts mem. Another would be a web service (possibly firewalled to localhost or accessible over unix socket) that did the same. Conceivably, this could use blanche, LDAP, or some other web service instead.)

Change History (7)

comment:1 Changed 8 years ago by adehnert

  • Description modified (diff)

comment:2 Changed 8 years ago by adehnert

I would like to propose "unauthenticated webapp that serves up (authenticated) group membership (generally over HTTPS)". I have validated that, with no tokens at all, I can use pts mem (and pts exa) against a Athena-cell group with flags "S-M--". I believe that this means we do not have privacy concerns about such a webapp. If people do have privacy concerns, please say so.

Also, if people consider using AFS (pts mem or Python libraries, probably) to get group membership to be unacceptable, please say so. This is my preferred approach, because it's more robust than Moira, doesn't not require the group be an NFS group (unlike, I believe, LDAP), and is more known to me than any other solution.

I'm anticipating getting and using daemon.scripts-membership or some such for this.

I will endeavor to actually implement this soonish, but want to make sure my thing won't be DOA because of privacy concerns or something.

comment:3 Changed 8 years ago by jdreed

I believe that this means we do not have privacy concerns about such a webapp.

Provided such a thing is subject to the access restrictions described in the initial description (e.g. loopback connections only, or IP-acl'd to the Scripts servers, or whatever), it's probably fine, but I'm not an authoritative source on that. Privacy concerns aside, using AFS to do an end-run around LDAP feels hackish (in particular, the "group quota" -- assuming you mean the Hesiod GRPLIST limit -- isn't going to be around forever) I think there's actually more stuff in LDAP than we think there is, and in an Athena context, Garry and Mark have been open to requests to add things to LDAP or change Schema, etc.

My two cents is that it's worth having a conversation with Ops about the Right(tm) way to do this.

comment:4 Changed 8 years ago by adehnert

Hmm. It occurs to me that there are three(?) ways to do this:

  • Totally unauthenticated --- plus: easy to use; minus: reveals semi-private(?) data
  • IP authenticated (net-18? localhost-only?) --- pluses: easy to use; minus: development sites can't work (possible solutions: also supply an server stub that uses "pts mem -noauth" or something for use on dev servers; or say that people should be using this only in syncing cron jobs or something, and they should develop those only on scripts)
  • Authenticated with an API key --- pluses: works from dev servers; minus: requires them using a key and us tracking keys (and probably having a webform to give them out)

I'd be basically happy implementing any of these. Thoughts on which is best?

comment:5 Changed 8 years ago by adehnert

  • Description modified (diff)

comment:6 Changed 8 years ago by adehnert

Mechanisms for getting this data:

  • Webmoira: curl'ing 302's
  • LDAP: has AFS groups; membership is available if you authenticate
  • Moira: has everything, but is not high-availability, among other issues
  • AFS: has AFS groups; integrity protection is available if you have tokens
  • MOIRAWS: has everything; Ops likes to give access only to a specific prefix, and it requires talking to them (in a less-smooth/no-questions-asked process than getting a keytab, I think)

I think I prefer AFS (it's pretty easy), though LDAP would also be fine. MOIRAWS seems maybe a little silly, Webmoira seems clearly wrong, and Moira itself seems dubious for various reasons.

Last edited 5 years ago by adehnert (previous) (diff)

comment:7 Changed 8 years ago by adehnert

Kerberized LDAP:

import ldap
import ldap.filter
import ldap.sasl
import sys

conn = ldap.initialize('ldap://')
conn.sasl_interactive_bind_s("", ldap.sasl.gssapi())
dn = "ou=lists,ou=moira,dc=mit,dc=edu"
groupfilter = ldap.filter.filter_format('cn=%s', [sys.argv[1]])
fields = ['dn', 'cn', 'description', 'member', 'owner', 'gidNumber', ]
result = conn.search_s(dn, ldap.SCOPE_SUBTREE, groupfilter, fields)
print result
print result[0][1]['member']
Note: See TracTickets for help on using tickets.