whose bits are they, anyway? access controlled applications built around afs

2004-03-24 SLAC AFS Best Practices - djbyrne 1

Whose Bits Are They, Anyway?

Access Controlled Applications Built Around AFSDJ Byrne

[email protected] Propulsion Laboratory

Information Services - File/Web Service Engineer

http://fil.jpl.nasa.gov/

2004-03-24 SLAC AFS Best Practices - djbyrne 22004-03-24 SLAC AFS Best Practices - djbyrne 2

JPL Main Campus, Pasadena, CA


AFS and WEB StatisticsAFS Users 3000

AFS Groups 400

Volumes 5500 RW3800 RO

Space Used 1.5 TB

BreakDelayedCallbacksEvents today

262 Messages over 14 users(5 potentially critical)

Websites in docroot 1000

Website throughput ~20 GB/day. More when landing on Mars :-)


AFS and WEB statistics

AFS Users 3000 AFS Groups 400 Volumes 5500 RW 3800 RO Space Used1.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 :-)


We’ve Got AFS; What Next?

People share data through more interfaces than the OS filesystem.


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.


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


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


Mix-n-Match Technology Layers

Repositories Client Access Interfaces Web front-ends Users (Authentication) Group Management Authorization


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


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]


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]


Web front-ends

iPlanet Apache WebSecure plugin - makes web server

respect AFS ACLs; keeps a token cache DocuShare TeamCenter


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 (?)


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


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


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


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


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.


Q&A


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?

whose bits are they, anyway? access controlled applications built around afs

Documents