1. User VOMS Java C CA 2. certificate dn, ca, key 1. request 3. certificate 4. VOMS cred: VO, groups, roles, capabilities Authentication Certificate Authorities (CA) Working Group –16 national certification authorities + CrossGrid CAs –policies & procedures  mutual trust –users identified by certificates signed by their national Certificate Authority CA’s CERN CESNET CNRS (3) GermanGrid Grid-Ireland INFN NIKHEF NorduGrid LIP Russian DataGrid DATAGRID-ES GridPP US–DOE Root CA US-DOE Sub CA CrossGrid (*) Fine-grained e.g. RepMeC WP2/WP3 authentication authorization pre-process (service specific) valid certificate + valid VOMS cred. reqested operation, object id./ACL TrustManager Web Services Authorization Framework Coarse-grained e.g. Spitfire WP2 authentication authorization mapping valid certificate + valid VOMS cred. dn, attributes (local) id 5.a proxy certificate 5.b proxy certificate once a year once a day Fine-grained e.g. SE, /grid WP5 authentication authorization pre-process (service specific) valid certificate + valid VOMS cred. reqested operation, object id./ACL Globus Security Infrastructure LCAS GACL Coarse-grained e.g. CE, Gatekeeper WP4 authentication authorization mapping valid certificate + valid VOMS cred. dn, attributes local user 5.c proxy certificate 5.d proxy certificate Virtual Organization Membership Service Provides information on the user’s relationship with her Virtual Organization: her groups, roles and capabilities. single login using voms-proxy-init only at the beginning of the session (was grid-proxy-init) expiration time: the authorization information is only valid for a limited period of time as the proxy certificate itself backward compatibility: the extra VO related information is in the user’s proxy certificate, which can be still used with non VOMS-aware services multiple VOs: the user may „log-in” into multiple VOs and create an aggregate proxy certificate, which enables her to access resources in any of them The service is basically a simple account database, which serves the information in a special format (VOMS credential). The VO manager can administrate it remotely using command line tools or a web interface. ALICE ATLAS CMS LHCb Earth Observation Biomedical Testbed Tutorial VOs TrustManager: certificate validator for Java services TrustManager is a pure Java based solution for GSI style X509 certificate path checking with Certificate Revocation Lists. Using standard CA certificates, certificate revocation lists (CRLs) and server credentials (certificates) authenticates the server to the user and the user to the server. This can be used for example in Tomcat to secure any web service without changes in the code. Changes to X509 certificate path checking The way the Globus proxy certificate is implemented (non CA certificates are signing sub-certificates) can pose a security risk in certain situations. As the restriction to a simple „CN=proxy” prefix to the DN would be too strict for the future, an automatic naming constraint is enforced. The algorithm is the following: 1.If the CA certificate is X509 v1 cert, then the second one is considered to be the user certificate. 2.Otherwise the first certificate that does not have CA flag is considered to be the user certificate. 3.The user certificate can be used to sign only sub-certificates that end with the DN of the user certificate. The sub-certificates can only sign sub-sub-certificates that end with the DN of the previous one (suffix namespace constraint). Example: [CN=John Doe, OU=Beauty Products, O=Acme] can be used to sign [CN=Work, CN=John Doe, OU=Beauty Products, O=Acme], but not [CN=John Walker, OU=Beauty Products, O=Acme]. Authorization Manager: enforcing policies in Java services The AuthorizationManager operates with one or several policies. Each policy has defined an AttributeRepository, which is used to deduce whether a subject can be associated with a given attribute ('role', if you so wish). The AuthorizationManager also has an optional translation phase: after deducing that a subject indeed is authorized (i.e., can be associated with the attribute in question), the attribute name can be translated into another name, understandable by the local application. Thus, one can give the AuthorizationManager the triplet (subject=John, attribute=DataGridMember, policy=localDbAccess) and get the answer "ReadAccessOnTableX" back, an answer that the local database application knows how to handle. Flow example An application needs to know whether a client is authorized to perform a certain action (or set of actions). It sends the information triplet (subject, attributes, policy) to the AuthorizationManager. 1.The AuthorizationManager decides which of the preconfigured polices to use. 2.The AttributeRepository associated with the policy is used to find out if there in an association between subject and attribute (or attributes). 3.The AttributeRepository may be a AttributeMapRepository, in which case the AttributeMap in question is used to perform a lookup on subject 4.The attribute map performs the lookup. In this case, it is a map that operates against a database. 5.A list of attributes associated with subject is returned. The AttributeRepository masks the attributes against that list. 6.The result is returned up to the policy level. 7.(Optional). The approved attribute(s) may be translated into something the application understands (mapping global policy attributes to locally defined attributes). 8.The (translated) authorized attribute(s) is returned to the application. LCAS: enforcing local policies at every site To ensure the autonomy of the resources that compose the DataGrid, each site can use a authorization hook to ensure local policies. LCAS, which stands for Local Centre Authorization System, is a site-local service to ensure that local policies are respected. The first version of LCAS, deployed on the current test bed, implements only three basic policies: allow a set of users, ban specific users, and put time restrictions on Grid job submission. The authorization can also depend on what job the user is requesting to run. In the future, this system will evolve into a centre Application Service Module (ASM) as part of global policy decision making. LCMAPS: integrating Grid users in an existing infrastructure Operating systems todate have no specific knowledge of "Grid Users". Therefore it is needed to translate the idea of a grid user into that of a local user. And since there are many different implementations of local users, even within the same site, a flexible credential "mappining service" is needed: LCMAPS, or the Local Credential MAPping Service. The LCMAPS service will create and assign local credentials based not only on user identity, but also on Virtual Organisation (VO) affiliation, and site-local policy. Credentials supported are: - UNIX user and group ID's - Pool Accounts from the Gridmapdir system - individual accounts - AFS and Kerberos Slashgrid: a framework for Grid-aware filesystems. DataGrid TestBed 1 used a patched version of Globus gatekeeper and the grid ftp-server to associate random Unix userids for authenticated and authorized grid users from a pre-allocated pool of userids. This dynamic account scheme is a reasonable solution for carrying out processing when there is no need to store data after the processing is complete, but any files created by the pool userid will need to be cleaned up before the account can be re-allocated no good for long term storage, as there is no guarantee that the userid- Grid DN (distinguished name) association will be kept in the long term. The obvious solution is to have a filesystem where file ownership depends on Grid DNs not temporary userids. The problem was solved by putting a file-system into the kernel and letting the kernel enforce access control restrictions. This construction is potentially as fast as the normal disk access. This special file-system uses a user space daemon for complex operations, such as parsing the proxies and doing remote IO. kernel a real (ext2) disk open() read() stat() SlashGrid read() write() open() stat() /dev/cfs0/var/spool/slashgrid/fcache ordinary directory /grid/... User process GACL: a Grid Acccess Control List library Commonly used compromise between granularity and simplicity is the per- directory ACL (cf AFS) Slashgrid uses the same format as the GridSite website management system: –admin: can modify ACL –write: can write/create files –list: can get a directory listing –read: can read a named file –ACL consists of lines: Currently only implement but in future will add VO groups, VOMS or CAS authorization symbols etc. European DataGrid Security Interworking & Collaboration We need to inter-work with many other Grid projects including: CrossGrid, DataTAG, LCG, PPDG, GriPhyN, iVDGL, and GridStart. We achieve this via direct collaboration and active participation in many GGF Security groups: GridCP, CA Operations, Authorization frameworks and mechanisms, SiteAA requirements. GGF defines standards and best practices. Authorization From the authorization point of view, a grid is established by enforcing agreements between Resource Providers (RP) and Virtual Organizations (VO). In general, resource access is controlled by both parties with different roles, and indeed the main difficulty is to clearly separate the two roles. To solve this apparent dualism, we can classify the authorization information into two categories:  general information regarding the relationship of the user with his VO: groups he belongs to, roles he is allowed to cover and capabilities he should present to RP's for special processing needs;  information regarding what the user is allowed to do at a RP, owing to his membership of a particular VO. The first kind of information should be managed by the VO itself and it is provided for the users upon request (at starting their session) from the Virtual Organization Membership Service (VOMS). The second kind is best kept at the local sites, near the resources involved in some kind of (extended) Access Control Lists or local policy settings. In the authorization process at a RP the VO specific and local information is evaluated and a decision is made if the user is permitted to access a resource. This decision making process and the enforcement of the decision is specific to the protected service. DataGrid services are using three fundamental solutions: Trust/Authorization Manager for Java, LCAS/LCMAPS and SlashGrid. LCMAPS