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

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. 2004-03-25 2004-03-25 SLAC AFS Best Practices - djbyrne SLAC AFS Best Practices - djbyrne 2 2

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 2004-03-25 2004-03-25 SLAC AFS Best Practices - djbyrne SLAC AFS Best Practices - djbyrne 3 3

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 2004-03-25 2004-03-25 SLAC AFS Best Practices - djbyrne SLAC AFS Best Practices - djbyrne 4 4

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

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 2004-03-25 2004-03-25 SLAC AFS Best Practices - djbyrne SLAC AFS Best Practices - djbyrne 6 6

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

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] 2004-03-25 2004-03-25 SLAC AFS Best Practices - djbyrne SLAC AFS Best Practices - djbyrne 8 8

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

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 (?) 2004-03-25 2004-03-25 SLAC AFS Best Practices - djbyrne SLAC AFS Best Practices - djbyrne 10 10

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 2004-03-25 2004-03-25 SLAC AFS Best Practices - djbyrne SLAC AFS Best Practices - djbyrne 11 11

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 2004-03-25 2004-03-25 SLAC AFS Best Practices - djbyrne SLAC AFS Best Practices - djbyrne 12 12

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 2004-03-25 2004-03-25 SLAC AFS Best Practices - djbyrne SLAC AFS Best Practices - djbyrne 13 13

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.” 2004-03-25 2004-03-25 SLAC AFS Best Practices - djbyrne SLAC AFS Best Practices - djbyrne 14 14

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. 2004-03-25 2004-03-25 SLAC AFS Best Practices - djbyrne SLAC AFS Best Practices - djbyrne 15 15

Q&A 2004-03-25 2004-03-25 SLAC AFS Best Practices - djbyrne SLAC AFS Best Practices - djbyrne 16 16

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? 2004-03-25 2004-03-25 SLAC AFS Best Practices - djbyrne SLAC AFS Best Practices - djbyrne 17 17