EGEE is a project funded by the European Union under contract IST R-GMA Security Stephen Hicks UK Cluster Security Middleware Security Group Meeting, 06/05/04

Middleware Security Group Meeting, 06/05/ Contents Overview Authorization rules Security in the API Implementation issues External dependencies

Middleware Security Group Meeting, 06/05/ Overview Interactions involving  Users  R-GMA components Consumers Producers Registry Schema High level security  Is this service legitimate?  Can this user access this service?  Can service X access service Y? Application level  Is this user allowed to read data from this table?  Is this user allowed to write to this table? Consumer Service Producer Service Registry Service User Schema Service

Middleware Security Group Meeting, 06/05/ Authorization rules GACL: probably inappropriate for R-GMA  Can't define authorization on an item  Need parameterization: security details are part of the application data Not simply: persons X, Y and Z can access table T But: persons X, Y and Z can access data in table T where the GROUP column matches their group Fine-grained authorization based on a view of the database One rule contains  SQL SELECT statement  User credentials Both can contain parameters

Middleware Security Group Meeting, 06/05/ Authorization rules: examples Example table: Job  Columns: JobID, State, Owner, OwnersGroup SELECT * FROM Job : VO=‘ourVO’  A user (via a consumer) can access all data in table Job if it is a member of VO ourVO. SELECT * FROM Job WHERE Owner=[DN] : DN=[DN]  A user can access all rows of data in Job where he/she is the owner. SELECT JobID, State, Owner FROM Job WHERE OwnersGroup=’ABModel’ : GROUP=’ABModel’ OR GROUP=‘Xdata’  A user can access columns JobID, State and Owner of all rows in Job where the owner’s group for the row is ABModel and the user is in group ABModel or Xdata.

Middleware Security Group Meeting, 06/05/ Authorization rules Defined when a table is created Authorization defined by:  User via API  Preloading into schema for statically defined tables Details stored in Schema:  Table description (CREATE TABLE …)  Authorization rules One Schema per VO

Middleware Security Group Meeting, 06/05/ Security in the API Each Producer/Consumer created with a list of VOs  ProducerFactory.createPrimaryProducer(…, voNames)  ConsumerFactory.createConsumer(…, voNames) createTable(CreateTableStatement, TableAuthorization)

Middleware Security Group Meeting, 06/05/ Implementation issues Where is authorization decision made?  Producer Could be achieved by passing credentials between trusted services But ultimately requires delegation  Consumer Unnecessary passing of information, but no delegation needed Registry & Schema  Mutual trust between services or delegation? Secondary producers High level security handled by:  Web Service protocols  Transport protocols

Middleware Security Group Meeting, 06/05/ External dependencies R-GMA authorization depends on VOMS (or similar) VOMS needs to issue credentials both to users and R-GMA hosts. Eventually VOMS should be able to sign a specification of  which hosts they trust to carry out R-GMA roles  access control rules for that VO. R-GMA depends on Edg-Java-Security or its successor for  Authentication using the trust manager  Checking VOMS credentials  Extracting credentials within R-GMA