whose bits are they anyway
play

Whose Bits Are They, Anyway? Access Controlled Applications Built - PowerPoint PPT Presentation

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/ 2004-03-24 SLAC AFS Best


  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/ 2004-03-24 SLAC AFS Best Practices - djbyrne 1

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

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

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

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

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

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

  8. Examples: web servers n HTML file created by vi/emacs served via httpd w Who can see it? w 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). n Web browser access to document repository using kerberos principals in LDAP groups to control access to files on NAS indexed in Oracle database. w I am not making this up. w Access decisions spread among components w Places trust in admins of several organizations 2004-03-24 2004-03-24 SLAC AFS Best Practices - djbyrne SLAC AFS Best Practices - djbyrne 8 8

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

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

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

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

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

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

  15. Group Management: PTS [P] n System:anyuser is Just Plain Evil, except for public outreach material [E] n 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 w JPL employee w US person w Someone we could contact if we need to n jpl.networks for IP-based authentication [E] n Actively managed by attentive humans [BP] n Automatically generated from some out-of-band data source, like “everyone in section 366” [BP] n Insufficient meta-data for administrative details w We rely heavily on naming conventions instead 2004-03-24 2004-03-24 SLAC AFS Best Practices - djbyrne SLAC AFS Best Practices - djbyrne 15 15

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

  17. Group Management: PTS/LDAP Synchronization [BP] n PTS groups sync from LDAP w Vice-versa is possible, but what would be the point? w 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. w System:{anyuser, authuser,administrator} clearly only mean the AFS system w Naming conventions very important • Use of colons • At JPL, *.admin owns and can administer the base group w PTS contexts already overloaded • At JPL, *.admin pays for the group space, plus any websites 2004-03-24 2004-03-24 SLAC AFS Best Practices - djbyrne SLAC AFS Best Practices - djbyrne 17 17

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

  19. Conclusions n Break the problem into small, well-defined technology pieces with clean interfaces w Use glue code to translate contexts w Only two things really need to be centralized: • Authentication • Group Management n 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. 2004-03-24 2004-03-24 SLAC AFS Best Practices - djbyrne SLAC AFS Best Practices - djbyrne 19 19

  20. Q&A 2004-03-24 2004-03-24 SLAC AFS Best Practices - djbyrne SLAC AFS Best Practices - djbyrne 20 20

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

Recommend


More recommend