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

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

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

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

5
Heterogeneous Technologies

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

6
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

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)

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

9
Web front-ends

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

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

11
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

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

13
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

14
Authorization

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

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

16
QA
17
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?