Whose Bits Are They, Anyway? Access Controlled Applications Built Around AFS

1. Whose Bits Are They, Anyway?Access Controlled Applications Built Around AFS DJ Byrne djbyrne@jpl.nasa.gov Jet Propulsion Laboratory Information Services - File/Web Service Engineer http://fil.jpl.nasa.gov/

2. JPL Main Campus, Pasadena, CA SLAC AFS Best Practices - djbyrne

3. AFS and WEB Statistics SLAC AFS Best Practices - djbyrne

4. AFS and WEB statistics • AFS Users 3000 • AFS Groups 400 • Volumes 5500 RW • 3800 RO • Space Used 1.5 TB • BreakDelayedCallbacks • Events today 262 Messages over 14 users • (5 potentially critical) • Websites in docroot 1000 • Website throughput ~20 GB/day. More when landing on Mars :-) SLAC AFS Best Practices - djbyrne

5. We’ve Got AFS; What Next? • People share data through more interfaces than the OS filesystem. SLAC AFS Best Practices - djbyrne

6. The Enchilada in a Nut Shell • Economy of scale: keep your bits in a nice big central repository. • Shoot yourself in the foot: require users to change their tools to match your repository. • Productivity: share bits with application adapted to its context. The more interfaces available, the more leveraging of centralization. • Calm down, it’s only ones and zeros. SLAC AFS Best Practices - djbyrne

7. JPLIS File Service • AFS • FTP access to AFS • SMB access to AFS • SSH access to AFS client (login.jpl.nasa.gov) • AppleTalk access recently shut down • Whatever those Windows-95/98 protocol translator things were, recently shut down • HTTP and HTTPS access to AFS recently spun off SLAC AFS Best Practices - djbyrne

8. Examples: web servers • HTML file created by vi/emacs served via httpd • Who can see it? • The web server has to get the bits, identify the user, and make a second authorization decision (fileserver made the first decision to give ‘em to the web server). • Web browser access to document repository using kerberos principals in LDAP groups to control access to files on NAS indexed in Oracle database. • I am not making this up. • Access decisions spread among components • Places trust in admins of several organizations SLAC AFS Best Practices - djbyrne

9. Mix-n-Match Technology Layers • Repositories • Client Access Interfaces • Web front-ends • Users (Authentication) • Group Management • Authorization SLAC AFS Best Practices - djbyrne

10. DJ’s Report Card Notation • [BP] = Best Practice • Can be more than one “Best” depending on context • [CP] = Common Practice • Convenient, or legacy, or just what we thought of first • [P] = uh, Practice • Or, “needs more practice” • [E] = Evil • Well, OK, I suppose every layer helps… • Confuses, delays, or prevents The Right Thing SLAC AFS Best Practices - djbyrne

11. Repositories • AFS [BP] • Global namespace • Kerberized • Client caching • NFS (e.g., NAS filer) [CP] • Oracle databases [CP] • Local disk (boooring. Ignored for this talk) • POP/IMAP server [P] SLAC AFS Best Practices - djbyrne

12. Client Access Interfaces • AFS native (cleartext) [CP] • AFS native (-crypt) [BP] • HTTP [CP] (but not for authenticated access) • HTTPS [BP] • WebDAV • Anonymous FTP [BP] • Clients easy to come by, users already comfortable • Authenticated FTP [E] • Cleartext, PW in clear • Scp [BP] • SMB (cleartext?) [CP] SLAC AFS Best Practices - djbyrne

13. Web front-ends • iPlanet • Apache • WebSecure plugin - makes web server respect AFS ACLs; keeps a token cache • DocuShare • TeamCenter SLAC AFS Best Practices - djbyrne

14. Users (Authentication) • kerberos principals [BP] • srvtab/keytab • PTS entries matching some of the principals [BP] • LDAP objects [CP] • “password” attribute • Vendor availability. Simple, lightweight • Cleartext binds on port 389 [E], SSL on 636 • IP address as authentication [E] • Policies like expirations and strength have to be agreed on, and therefore published • So how does a user get told their password expires tomorrow? And which interface do they use to reset the password? • No hooks in kerberos servers (?) SLAC AFS Best Practices - djbyrne

15. Group Management: PTS [P] • System:anyuser is Just Plain Evil, except for public outreach material [E] • System:authuser is only A Slightly Lesser Evil at JPL, because it doesn’t actually say anything about the principal. [E] Dangerous common mis-conceptions include • JPL employee • US person • Someone we could contact if we need to • jpl.networks for IP-based authentication [E] • Actively managed by attentive humans [BP] • Automatically generated from some out-of-band data source, like “everyone in section 366” [BP] • Insufficient meta-data for administrative details • We rely heavily on naming conventions instead SLAC AFS Best Practices - djbyrne

16. Group Management: LDAP [BP] • Lightweight Directory Access Protocol • X500 without the cumbersome stuff… • …like security • “Meta-directory” collects and publishes from many “gold sources” • Personnel • Projects • Individual • Base group “jimo” • Ya can’t beat a general-purpose DB with extensible attributes. • Description: Jupiter Icy Moons Orbiter • jplService: emaillist, afs_pts_group • Memberurl: LDAP filter expression to auto-generate group • Auto-generated derivative groups • jimo.us • jimo.jpl • jimo.usjpl SLAC AFS Best Practices - djbyrne

17. Group Management:PTS/LDAP Synchronization [BP] • PTS groups sync from LDAP • Vice-versa is possible, but what would be the point? • Watch the “One to one and Onto” mapping assumption! Doesn’t make sense for it to hold; LDAP groups are intended to be generic but PTS carries context. • System:{anyuser, authuser,administrator} clearly only mean the AFS system • Naming conventions very important • Use of colons • At JPL, *.admin owns and can administer the base group • PTS contexts already overloaded • At JPL, *.admin pays for the group space, plus any websites SLAC AFS Best Practices - djbyrne

18. Authorization • ACLs • Individuals [P] • Role-based groups [BP] • “IP ACLs” [CP][E] • srvtab/keytab [BP] • Mind your PAGs • Monitor for inadvertant tokens, e.g. user CGI programs. You know who to contact :-) • token passing [BP?] • nsconfig/htaccess [CP] • By web client IP [CP][E] • nsconfig.jpl • By username authentication [BP?] • Application-specific [BP] • Mapping [E] • E.g., database of “protected” URLs • Ignores power of indirection, which is the whole point of popular words like “distributed,” “web,” and “hyper.” SLAC AFS Best Practices - djbyrne

19. Conclusions • Break the problem into small, well-defined technology pieces with clean interfaces • Use glue code to translate contexts • Only two things really need to be centralized: • Authentication • Group Management • Push Authorization as close to the bits as possible. It’s tempting to build “mapping” applications to cross contexts. This invariably leads to a data sync problem. SLAC AFS Best Practices - djbyrne

20. Q&A SLAC AFS Best Practices - djbyrne

21. Backup slide:More on the Problem Space • "The ITAR Problem" • International Trade in Arms Regulation • Clearance and Document Review • User training and expectations • "public" means "public," not just my company! • “www” is not “Wcompany Wide Web” with a silent W • “Any” does not mean “some” in system:anyuser • Tools, Templates, and Best Practices to make the Right Thing easier to do than the Wrong Thing • Policies to tell the difference • Audit functions? Who’s the policeman? On what authority? SLAC AFS Best Practices - djbyrne