TWiki> DICE Web>AFSWebServerIssues (revision 1)EditAttach
Planning Questions

What do we want from a secure web server?

We need to be aware of the distinction and any discrepancies between general web-browsing access and filesystem access. What, if anything, do we want to change or fix?

We can use generic "apache" ID access to serve public files, and user-specific access for restricted files, where:

  • public access is via AFS apache ID (as currently for system:groupwebserver, which contains afsweb.hostname IDs)
  • restricted access via minimal AFS user ID (assume this ID when public access is not sufficient - and this may need to be triggered by URL, as access requirements may vary).

create/configure new server (real or VM?)

  • physically separate AFS server, firewall protected? (This might prevent unwarranted physical and administrative access to the server, but would not have a significant impact on the AFS structure.)

install/configure apache

  • do we require user-run scripts?
  • we could disable arbitrary user-run scripts (a script should not be able to subvert any explicit restrictions by abusing the AFS apache ID privileges, scripts should run as user).

identify disk storage space/location

  • how much would we need and where would it be?

define our volume naming scheme

(one volume per user, on demand)

Volume allocation would be per user, and on-demand (rather than automatically by default), administered by appropriate capability.

AFS web space could be provided as a separate volume, web.NAME for example, either mounted or linked as the old public_html used to be, or accessible via a separate path such as /afs/ or somesuch (to avoid conflict with home directory access constraints imposed or required by the user).

Providing web data storage on separate AFS volumes has the advantage of:

  • fine grain access control,
  • fine grain quota control,
  • the ability to access the data files from outwith the University
  • the ability to remove volumes as part of the account lifecycle mechanism

consider the apache start mechanism (keeping it authenticated)

...using k5start

  • intra-PAG
  • extra-PAG (if the web server is started by hand, the web server will lose its credentials)

This approach allows one AFS id for the entire website, but no finer granularity.

decide on the apache file-access mechanism

(so that web-server can access requested files on behalf of users)

Any server that needs authenticated access to AFS will need its own service principal

All requests could use same ID (but any compromise would affect all users), OR requests could use a unique user/web ID.

Access permissions would need to be isolated so that there's no general access to, for example, cgi scripts - a user's CGI shouldn't (because it might need to run as apache) be able to access or affect anything that the user can't. This will probably mean separate/additional AFS user identities.

...the upshot of which strongly supports the use of mod_waklog in conjunction with CoSign. We can use a single ID be specifying a WaklogDefaultPrincipal to give us public access, or per-user CoSign authentication for finer control.

<Location /webstuff>
  CosignProtected      On
  AuthType       Cosign
  Require       valid-user

  CosignGetKerberosTickets    On
  CosignKerberosSetupGss       On
  WaklogUseUserTokens        On
With respect to URL-triggered credential change referred to above, different credentials might be used for different locations via the WaklogLocationPrincipal directive.

Apache needs to be able to authenticate against our KDC, and to obtain AFS tokens for the principal it's authenticated as. The AFS ACLs need to be configured accordingly to provide access to the required files.

Each machine which requires web access to AFS space should have an AFS/web service principal mapping to a corresponding AFS id.

-- RogerBurroughes - 06 May 2014

Edit | Attach | Print version | History: r4 < r3 < r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r1 - 06 May 2014 - 12:24:48 - RogerBurroughes
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback
This Wiki uses Cookies