1 / 17

Scalla Authorization

Scalla Authorization. xrootd /cmsd Andrew Hanushevsky SLAC National Accelerator Laboratory CERN Seminar 10-November-08 http://xrootd.slac.stanford.edu. Outline. Server Architecture Where authorization fits in Authorization Challenges & Approach Built-In Plug-In Architecture

abel
Download Presentation

Scalla Authorization

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Scalla Authorization xrootd /cmsd Andrew Hanushevsky SLAC National Accelerator Laboratory CERN Seminar 10-November-08 http://xrootd.slac.stanford.edu

  2. Outline • Server Architecture • Where authorization fits in • Authorization Challenges & Approach • Built-In Plug-In Architecture • Entities, Objects, and Privileges • Positioning certificates • Conclusion 2: http://xrootd.slac.stanford.edu

  3. xrootd Server Architecture clustering heart application Protocol & Thread Manager xrd xrootd Protocol Layer xroot Authentication Filesystem Logical Layer cms ofs Authorization optional Filesystem Physical Layer oss (included in distribution) Filesystem Implementation _fs mss 3: http://xrootd.slac.stanford.edu

  4. Authenticated Identity XrdSecEntity.hh • char prot[8]; // Protocol used • char *name; // Entity's name • char *host; // Entity's host name • char *vorg; // Entity's virtual organization • char *role; // Entity's role • char *grps; // Entity’s groups • char *endorsements; // Protocol specific endorsements • char *tident; // Trace identifier (do not modify) • void *cert // Pointer to certificate (future) • int clen; // Length of certificate (future) Passed to file system layer to be used for authorization Used by default authorization plug-in 4: http://xrootd.slac.stanford.edu

  5. Authorization Interface class XrdAccAuthorize { public: virtual XrdAccPrivs Access(const XrdSecEntity *Entity, const char *path, const Access_Operation oper, XrdOucEnv *Env=0) = 0; virtual int Audit(const int accok, const XrdSecEntity *Entity, const char *path, const Access_Operation oper, XrdOucEnv *Env=0) = 0; virtual int Test(const XrdAccPrivs priv, const Access_Operation oper) = 0; }; 5: http://xrootd.slac.stanford.edu

  6. Authorization Challenge • Number of files • Billions and billions of files • Access control list model unmanageable • Too many files to protect • Don’t want to record allowed entities in many places • Capability model is manageable • Few users relative to number of files • Entities recorded only once • Each entity given access to arbitrary file space regions 6: http://xrootd.slac.stanford.edu

  7. Authorization Approach • Default authorization is built-in • Basic Windows XP-like access control • Works as a plug-in • ofs.authlib path [ parms ] • Over-rides built-in authorization • ofs.authorize • Required to turn on authorization 7: http://xrootd.slac.stanford.edu

  8. libXrdSec.so Security Shared Library Authorization Architecture lib????.so xrootd Authentication Authorization Shared Library Authorization XrdOfs Replaceable Database Interface database u abh rw /slac/files/usr/abh r /cern/files 8: http://xrootd.slac.stanford.edu

  9. Builtin Architecture Detail libXrdOfs.so client request ofs Client xrootd access() yes or no database Access Control Object lib????.so or builtin db Object u abh rw /slac/files/usr/abh r /cern/files Authorization Object Auditing Object 9: http://xrootd.slac.stanford.edu

  10. Builtin Authorization Model • Capability based model • Each entity has a list of capabilities • A capability is a path prefix-privilege pair • Any number of such pairs may be specified • More scalable when number of objects greatly exceeds number of entities • Can mimic an access control model Entities can be: Host Names NIS Netgroups Group Names User Names Capability List u abh rw /slac/files/usr/abh r /cern/files 10: http://xrootd.slac.stanford.edu

  11. Builtin Authorization Entities • idtypeid { pathprivs | tempid } [ • • • ] [ \ ] • g - Group name • Applied when user is a member of the group • h - Host name • Applied when request originates from this host • Always fully qualify the host name and specify in lower case • n - NIS netgroup name • Applied when the triplet (hostname, username, domainname) is a member of the specified netgroup • t - template name • Specification substituted in future authorization records for tempid • u - user’s name (can be DN) • Applied for specific user, as identified by authentication protocol 11: http://xrootd.slac.stanford.edu

  12. Special Entities • u = { pathprivs | tempid } [ • • • ] [ \ ] • User’s name replaces the first occurrence of @= in path • Allows specializing privileges by user’s name without listing all users • Only one such entry may exist • Example: • u = /usr/@=/files a • User abh has all privileges for /usr/abh/files • u * { pathprivs | tempid } [ • • • ] [ \ ] • The entry applies to all users regardless of the originating host • Essentially default privileges • Only one such entry may exist • Example • u * /files rws Fungible Default 12: http://xrootd.slac.stanford.edu

  13. Builtin Authorization Privileges • idtypeid { pathprivs | tempid } [ • • • ] [ \ ] • a - all privileges i - insert (create) l - lookup r - read • d - delete k - lock (unused)n - rename w - write • Positive and negative privileges allowed • Negative privileges always override positive privileges • Examples • u aaa /foo rw • User aaa has read/write privileges in /foo • u abh /foo a-n • User abh has all privileges except rename in /foo • u xyz /foo –wind • User xyz is denied write/insert/rename/delete privileges in /foo 13: http://xrootd.slac.stanford.edu

  14. Principal of Least Privilege • For the first applicable path, if any, in each of • Default entry • Fungible user entry • Specific user entry • Entry for originating host • All groups in which user is a member • All netgroups to which (hostname, username, domainname) applies • Logically add together positive privileges • pos_privs |= new_pos_privs • Logically add together negative privileges • neg_privs |= new_neg_privs • Final privileges are positive less negative privileges • final_privs = pos_privs & ~neg_privs 14: http://xrootd.slac.stanford.edu

  15. Entities and Certs • Some entities equivalent • User Name and DN • Host • Others are not clear • Group, Netgroup • Additions are needed • Vorg and Role (the definition?) • Endorsement handling is totally unclear • Future Project 15: http://xrootd.slac.stanford.edu

  16. Summary • xrootd security • Fully configurable, extendable, even replaceable • Standards-based authentication • GSI • Kerberos (version 4 or 5) • Host based • Password • Built-in Capability-based authorization • Extensive privilege support • Auditing • Good model for application level security 16: http://xrootd.slac.stanford.edu

  17. Acknowledgements • Software Contributors • CERN: Derek Feichtinger, Fabrizio Furano, Andreas Peters • Fermi: Tony Johnson (Java) • Root: Gerri Ganis, Bertrand Bellenot • SLAC: Jacek Becla, Tofigh Azemoon, Wilko Kroeger • Operational Collaborators • BNL, INFN, IN2P3 • Partial Funding • US Department of Energy • Contract DE-AC02-76SF00515 with Stanford University 17: http://xrootd.slac.stanford.edu

More Related