RSP Fedora training days January 2009 Richard Green

RSP Fedora Training Days January 2009  Fedora creates an admin user as part of the installation process  Further users can be dealt with through:  the Tomcat users file  linking to a local LDAP  etc  security systems can be ‘chained’  Users are usually assigned a ‘role’ which can be used to determine their general permissions

RSP Fedora Training Days January 2009  Authorisation in Fedora is managed by the SUN XACML engine  Security policies can be tied to users, roles, IP addresses; objects, datastreams, methods  Only administrators can use API-M  API-M can only be called from  Users in the role ‘student’ cannot have access to datastreams called “fullsizeImage”  etc 3

RSP Fedora Training Days January 2009  Fedora provides dozens of ‘hooks’ to which security can be attached:  subject (loginID)  actions (API-M, purgeObject, riFindObjects…)  resources (object:owner, datastream:id…)  environment (clientIpAddress, currentDate…)  Hugely flexible  but can get complicated when policies interact  XACML is not very nice to write 4

RSP Fedora Training Days January 2009  The overall intent of this policy is datastream hiding, meaning that raw datastreams must not be accessible to anyone except very privileged users, but service-mediated disseminations are accessible by a broader audience.  The key point is that students can access disseminations of the object, but not the raw datastreams. This is might typically be done in cases where lesser privileged users are given a derivation of the main datastream, or a lesser quality view, or a less complete view of the raw datastream content.  Given that an object is of a certain content model (in this case UVA_STD_IMAGE), this policy will DENY datastream access to users who do NOT have the ROLE of 'administrator' or 'professor.' It will also DENY dissemination access to to users who do NOT have the ROLE of 'student,' 'administrator,' or 'professor.' 5

RSP Fedora Training Days January

 Default set of policies available ‘out of the box’  Good set of example policies provided  heavily commented  to learn from  to adapt 7

RSP Fedora Training Days January 2009  Given that writing XACML is not for the faint- hearted, other approaches have been produced by Fedora developers to hide it from even admin users  For instance, Muradora (which uses not quite the native Fedora security system but the principle holds): 8

RSP Fedora Training Days January 2009  Each collection (or object) has a security icon (authorisation permitting) 9

RSP Fedora Training Days January 2009  Users and roles listed  Check box security  Permissions set here are inherited (or overriden) at lower levels 10

RSP Fedora Training Days January Thesis object showing security options against individual datastreams. Could allow thesis to anyone (inherited) but audio clips only to… (Copyright?)

RSP Fedora Training Days January 2009  ‘Advanced’ security allows admin to set repository-wide permissions 12

RSP Fedora Training Days January 2009  Deny datastreams of type ‘audio/mpeg’ to students 13

RSP Fedora Training Days January 2009  Fedora has very flexible access controls  Authorisation based around XACML 14