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_at_jpl.nasa.gov
• Jet Propulsion Laboratory
• Information Services -
• File/Web Service Engineer
• http//fil.jpl.nasa.gov/

2
JPL Main Campus, Pasadena, CA
3
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 -)
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 -)

5
Weve Got AFS What Next?

• People share data through more interfaces than
  the OS filesystem.

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, its only ones and zeros.

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

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

9
Mix-n-Match Technology Layers

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

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

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

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

13
Web front-ends

• iPlanet
• Apache
• WebSecure plugin - makes web server respect AFS
  ACLs keeps a token cache
• DocuShare
• TeamCenter

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

15
Group Management PTS P

• Systemanyuser is Just Plain Evil, except for
  public outreach material E
• Systemauthuser is only A Slightly Lesser Evil at
  JPL, because it doesnt 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

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 cant 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

17
Group ManagementPTS/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! Doesnt make sense for it to hold
  LDAP groups are intended to be generic but PTS
  carries context.
• Systemanyuser, 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

18
Authorization

• ACLs
• Individuals P
• Role-based groups BP
• IP ACLs CPE
• 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 CPE
• 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.

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. Its tempting to build mapping
  applications to cross contexts. This invariably
  leads to a data sync problem.

20
QA
21
Backup slideMore 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 systemanyuser
• Tools, Templates, and Best Practices to make the
  Right Thing easier to do than the Wrong Thing
• Policies to tell the difference
• Audit functions? Whos the policeman? On what
  authority?