1 / 17

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

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/ SLAC AFS Best Practices Workshop March 25, 2004. The Enchilada in a Nut Shell.

markku
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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/ SLAC AFS Best Practices Workshop March 25, 2004

  2. 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

  3. 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

  4. 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

  5. Heterogeneous Technologies • Repositories • Client Access Interfaces • Web front-ends • Users (Authentication) • Group management • Authorization SLAC AFS Best Practices - djbyrne

  6. 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

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

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

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

  10. 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

  11. 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

  12. 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

  13. 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

  14. Authorization • ACLs • Individuals [P] • Role-based groups [BP] • “IP ACLs” [CP][E] • srvtab/keytab [BP] • 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

  15. 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

  16. Q&A SLAC AFS Best Practices - djbyrne

  17. 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

More Related