Securing OSU Web Services

1
SecuringOSU Web Services

• Scott Cantor
• cantor.2_at_osu.edu
• Office of Information Technology

2
Basic ConceptsAuthentication

• Identifying the user to an acceptable degree of
  certainty
• Should never be part of applications
• Technical options range from passwords to
  long-lived public key certificates
• Only source of enterprise authentication at OSU
  is Kerberos (ohio-state.edu)
• Faculty, staff, students, some affiliates

3
Basic ConceptsAuthorization

• Evaluating policy in order to decide whether an
  action on an object by an authenticated principal
  is permitted
• Often intertwined with applications
• Can be modularized in various ways, but
  organizations tend to be exception driven (for
  better or worse)
• No formal enterprise authorization at OSU

4
SupportedWeb Authentication Software

• OIT provides centralized authentication to
  Kerberos via the distauth system
• User authentication is via password over SSL to
  an OIT login server
• Target web servers run a plug-in that requests
  authentication by redirecting users for login and
  assigning a cookie which is validated by a secure
  process on the login server
• Cookies are associated with users attributes

5
distauthAdvantages

• Password traffic is confined to one host
• Single sign-on between servers is (optionally)
  automatic
• Applications can run w/o SSL (ideally not)
• Attributes pushed to applications
• Supported system on the critical path of key
  university services

6
distauthRequirements

• Windows NT/2000
• Solaris 2.6
• HP-UX 11
• other commercial UNIX
• IIS, Netscape/iPlanet, Apache 1.3.x
• http//usfs2.us.ohio-state.edu/security/dwas.html

7
UnsupportedWeb Authentication Software

• Developers who must use Linux or BSD for some
  reason can use Kerberos directly for
  authentication
• User authentication is via password over SSL to
  the target server
• basic-auth generally used, be very careful
  otherwise
• An unsupported Apache module (mod_auth_krb5) that
  offers caching and fail-over to local accounts is
  available

8
mod_auth_krb5Pluses and Minus

• More portable
• Co-exists with existing password-based
  authentication schemes
• Stringent server security requirements
• Single sign-on w/ basic-auth is impossible
• Limited non-trivial support
• Only a Kerberos principal name is immediately
  accessible to applications

9
FutureWeb Authentication Software

• Existing system relies on overkill DCE
  infrastructure, home grown, YASSOS
• Shibboleth, an Internet2 MACE project, is
  building an open source attribute exchange system
  for higher education based on SAML industry
  standard
• I co-wrote the architecture spec. and am
  implementing the components with developers at
  CMU and IBM

10
distauth v2 lt Shibboleth

• Designs are similar enough that Shibboleth has
  superceded distauth v2 (and we get it on I2s
  dime)
• Focuses on attribute exchange between
  institutions (so you can accept credentials
  issued by other universities), with an emphasis
  on user privacy
• Goal is a unified inter/intra-campus system by
  2003 (lots of time needed for migration)

11
Authorization and Attributes

• Focus is on attributes rather than authz.
• distauth (and Shibboleth) can aggregate and push
  data from multiple sources directly to
  applications
• Direct attribute sources include the OIT Data
  Warehouse, administrative databases, and
  eventually LDAP
• Requests for information always decided by data
  owners (HR, OES, etc.)

12
Interesting URLs

• distauthhttp//usfs2.us.ohio-state.edu/security/d
  was.html
• mod_auth_krb5http//usfs2.us.ohio-state.edu/webde
  v/WWW/mod_auth_krb5/
• Shibbolethhttp//middleware.internet2.edu/shibbol
  eth/
• SAMLhttp//www.oasis-open.org/committees/security
  /