Whose Bits Are They, Anyway? Access Controlled Applications Built - - PowerPoint PPT Presentation

▶
whose bits are they anyway
SMART_READER_LITE
LIVE PREVIEW

Whose Bits Are They, Anyway? Access Controlled Applications Built - - PowerPoint PPT Presentation

Oct 07, 2022 290 likes •510 views

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/ 2004-03-24 SLAC AFS Best

slide-1
SLIDE 1

2004-03-24 SLAC AFS Best Practices - djbyrne 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/

slide-2
SLIDE 2

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

JPL Main Campus, Pasadena, CA

slide-3
SLIDE 3

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

AFS and WEB Statistics

5500 RW 3800 RO Volumes

262 Messages over 14 users (5 potentially critical)

BreakDelayedCallbacks Events today ~20 GB/day. More when landing on Mars :-) Website throughput 1000 Websites in docroot 1.5 TB Space Used 400 AFS Groups 3000 AFS Users

slide-4
SLIDE 4

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

AFS and WEB statistics

n AFS Users 3000 n AFS Groups 400 n Volumes 5500 RW n 3800 RO n Space Used 1.5 TB n BreakDelayedCallbacks n Events today

262 Messages over 14 users n (5 potentially critical)

n Websites in docroot 1000 n Website throughput ~20 GB/day. More when landing on Mars :-)

slide-5
SLIDE 5

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

We’ve Got AFS; What Next?

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

slide-6
SLIDE 6

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

The Enchilada in a Nut Shell

n Economy of scale: keep your bits in a nice big central repository. n Shoot yourself in the foot: require users to change their tools to match your repository. n Productivity: share bits with application adapted to its context. The more interfaces available, the more leveraging of centralization. n Calm down, it’s only ones and zeros.

slide-7
SLIDE 7

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

JPLIS File Service

n AFS n FTP access to AFS n SMB access to AFS n SSH access to AFS client (login.jpl.nasa.gov) n AppleTalk access recently shut down n Whatever those Windows-95/98 protocol translator things were, recently shut down n HTTP and HTTPS access to AFS recently spun off

slide-8
SLIDE 8

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

Examples: web servers

n HTML file created by vi/emacs served via httpd

w Who can see it? w 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).

n Web browser access to document repository using kerberos principals in LDAP groups to control access to files on NAS indexed in Oracle database.

w I am not making this up. w Access decisions spread among components w Places trust in admins of several organizations

slide-9
SLIDE 9

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

Mix-n-Match Technology Layers

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

slide-10
SLIDE 10

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

DJ’s Report Card Notation

n [BP] = Best Practice

w Can be more than one “Best” depending on context

n [CP] = Common Practice

w Convenient, or legacy, or just what we thought of first

n [P] = uh, Practice

w Or, “needs more practice”

n [E] = Evil

w Well, OK, I suppose every layer helps… w Confuses, delays, or prevents The Right Thing

slide-11
SLIDE 11

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

Repositories

n AFS [BP]

w Global namespace w Kerberized w Client caching

n NFS (e.g., NAS filer) [CP] n Oracle databases [CP] n Local disk (boooring. Ignored for this talk) n POP/IMAP server [P]

slide-12
SLIDE 12

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

Client Access Interfaces

n AFS native (cleartext) [CP] n AFS native (-crypt) [BP] n HTTP [CP] (but not for authenticated access) n HTTPS [BP] n WebDAV n Anonymous FTP [BP]

w Clients easy to come by, users already comfortable

n Authenticated FTP [E]

w Cleartext, PW in clear

n Scp [BP] n SMB (cleartext?) [CP]

slide-13
SLIDE 13

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

Web front-ends

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

slide-14
SLIDE 14

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

Users (Authentication)

n kerberos principals [BP]

w srvtab/keytab

n PTS entries matching some of the principals [BP] n LDAP objects [CP]

w “password” attribute w Vendor availability. Simple, lightweight w Cleartext binds on port 389 [E], SSL on 636

n IP address as authentication [E] n Policies like expirations and strength have to be agreed on, and therefore published n So how does a user get told their password expires tomorrow? And which interface do they use to reset the password?

w No hooks in kerberos servers (?)

slide-15
SLIDE 15

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

Group Management: PTS [P]

n System:anyuser is Just Plain Evil, except for public outreach material [E] n 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 w JPL employee w US person w Someone we could contact if we need to

n jpl.networks for IP-based authentication [E] n Actively managed by attentive humans [BP] n Automatically generated from some out-of-band data source, like “everyone in section 366” [BP] n Insufficient meta-data for administrative details

w We rely heavily on naming conventions instead

slide-16
SLIDE 16

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

Group Management: LDAP [BP]

n Lightweight Directory Access Protocol

w X500 without the cumbersome stuff…

  • …like security

n “Meta-directory” collects and publishes from many “gold sources”

w Personnel w Projects w Individual

n Base group “jimo” n Ya can’t beat a general-purpose DB with extensible attributes.

w Description: Jupiter Icy Moons Orbiter w jplService: emaillist, afs_pts_group w Memberurl: LDAP filter expression to auto-generate group

n Auto-generated derivative groups

w jimo.us w jimo.jpl w jimo.usjpl

slide-17
SLIDE 17

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

Group Management: PTS/LDAP Synchronization [BP]

n PTS groups sync from LDAP

w Vice-versa is possible, but what would be the point? w 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. w System:{anyuser, authuser,administrator} clearly only mean the AFS system w Naming conventions very important

  • Use of colons
  • At JPL, *.admin owns and can administer the base group

w PTS contexts already overloaded

  • At JPL, *.admin pays for the group space, plus any websites
slide-18
SLIDE 18

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

Authorization

n ACLs

w Individuals [P] w Role-based groups [BP] w “IP ACLs” [CP][E] w srvtab/keytab [BP]

  • Mind your PAGs
  • Monitor for inadvertant tokens, e.g. user CGI programs. You know who to contact :-)

w token passing [BP?]

n nsconfig/htaccess [CP]

w By web client IP [CP][E]

  • nsconfig.jpl

w By username authentication [BP?]

n Application-specific [BP] n Mapping [E]

w E.g., database of “protected” URLs w Ignores power of indirection, which is the whole point of popular words like “distributed,” “web,” and “hyper.”

slide-19
SLIDE 19

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

Conclusions

n Break the problem into small, well-defined technology pieces with clean interfaces

w Use glue code to translate contexts w Only two things really need to be centralized:

  • Authentication
  • Group Management

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

slide-20
SLIDE 20

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

Q&A

slide-21
SLIDE 21

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

Backup slide: More on the Problem Space

n "The ITAR Problem"

w International Trade in Arms Regulation w Clearance and Document Review

n User training and expectations

w "public" means "public," not just my company! w “www” is not “Wcompany Wide Web” with a silent W w “Any” does not mean “some” in system:anyuser

n Tools, Templates, and Best Practices to make the Right Thing easier to do than the Wrong Thing

w Policies to tell the difference

n Audit functions? Who’s the policeman? On what authority?