Update on EDG Security (VOMS) European DataGrid Project Security Coordination Group http://cern.ch/hep-project-grid-scg

Registration CA user VO-VOMS user cert (long life) registration low frequency high frequency user user cert (long life) VO-VOMS registration web denied deny VO membership request (user) email address confirmation (user) create user requests a certificate (once in every two-three years) user sends the requests to the CA, which sends back the signed certificate conversion to browser digestable PKCS12 format registration in the EDG LDAP-VO (once for the lifetime of the VO – you may change the certificate keys!) generats a proxy certificate (24 hours lifetime) host/service requests a certificate host/service sends the requests to the CA, which sends back the signed certificate retrival of the trusted CA certificates and their CRLs (automatically updated every night/week) generating a gridmap file from the LDAP database for authorization and mapping (automatically updated every night/week) user contacts a service: they exchange their certificates to authenticate each other; the service bases its authorization decision on the gridmap file (... currently) Real life example: The traveller goes to the destination country and shows up his passport at the border. The officer checks its validity by comparing it to the example passport from the issuing country. He also looks at the list of revoked passports (coming from the originating country) and the visa, which allows the traveller to enter the country. The traveller may also ask the officer to identify itself, so the authentication is also symmetric in the real life. allow new confirmed accepted done (VO admin) email to the administrator: new request notification email to the requestor: email address confirmation email to the requestor: request is accepted/denied email

Multi-VO registration CA low frequency high frequency user user cert (long life) VO-VOMS registration VO administration operations create/delete (sub)group/role/capability add/remove member of g/r/c get/set ACLs for these operations VO registration tasks user requested administrative operation; e.g.: user registration = add member VO-VOMS VO-VOMS user requests a certificate (once in every two-three years) user sends the requests to the CA, which sends back the signed certificate conversion to browser digestable PKCS12 format registration in the EDG LDAP-VO (once for the lifetime of the VO – you may change the certificate keys!) generats a proxy certificate (24 hours lifetime) host/service requests a certificate host/service sends the requests to the CA, which sends back the signed certificate retrival of the trusted CA certificates and their CRLs (automatically updated every night/week) generating a gridmap file from the LDAP database for authorization and mapping (automatically updated every night/week) user contacts a service: they exchange their certificates to authenticate each other; the service bases its authorization decision on the gridmap file (... currently) Real life example: The traveller goes to the destination country and shows up his passport at the border. The officer checks its validity by comparing it to the example passport from the issuing country. He also looks at the list of revoked passports (coming from the originating country) and the visa, which allows the traveller to enter the country. The traveller may also ask the officer to identify itself, so the authentication is also symmetric in the real life. VO-VOMS

proxy cert (short life) authz cert (short life) “Login” CA low frequency high frequency user user cert (long life) VO-VOMS voms-proxy-init proxy cert (short life) user requests a certificate (once in every two-three years) user sends the requests to the CA, which sends back the signed certificate conversion to browser digestable PKCS12 format registration in the EDG LDAP-VO (once for the lifetime of the VO – you may change the certificate keys!) generats a proxy certificate (24 hours lifetime) host/service requests a certificate host/service sends the requests to the CA, which sends back the signed certificate retrival of the trusted CA certificates and their CRLs (automatically updated every night/week) generating a gridmap file from the LDAP database for authorization and mapping (automatically updated every night/week) user contacts a service: they exchange their certificates to authenticate each other; the service bases its authorization decision on the gridmap file (... currently) Real life example: The traveller goes to the destination country and shows up his passport at the border. The officer checks its validity by comparing it to the example passport from the issuing country. He also looks at the list of revoked passports (coming from the originating country) and the visa, which allows the traveller to enter the country. The traveller may also ask the officer to identify itself, so the authentication is also symmetric in the real life. edg-voms-proxy-init -voms iteam /tmp/x509_up<UID> (normal proxy location) backward compatible proxy format authz cert (short life)

proxy cert (short life) authz cert (short life) Multi-VO “Login” CA low frequency high frequency voms-proxy-init -voms iteam -voms wp6 single proxy certificate is generated each VO provides a separate VOMS credential first one is the default VO each VOMS credential contains multiple group/role entries first one is the default group user user cert (long life) VO-VOMS VO-VOMS voms-proxy-init VO-VOMS proxy cert (short life) user requests a certificate (once in every two-three years) user sends the requests to the CA, which sends back the signed certificate conversion to browser digestable PKCS12 format registration in the EDG LDAP-VO (once for the lifetime of the VO – you may change the certificate keys!) generats a proxy certificate (24 hours lifetime) host/service requests a certificate host/service sends the requests to the CA, which sends back the signed certificate retrival of the trusted CA certificates and their CRLs (automatically updated every night/week) generating a gridmap file from the LDAP database for authorization and mapping (automatically updated every night/week) user contacts a service: they exchange their certificates to authenticate each other; the service bases its authorization decision on the gridmap file (... currently) Real life example: The traveller goes to the destination country and shows up his passport at the border. The officer checks its validity by comparing it to the example passport from the issuing country. He also looks at the list of revoked passports (coming from the originating country) and the visa, which allows the traveller to enter the country. The traveller may also ask the officer to identify itself, so the authentication is also symmetric in the real life. VO-VOMS authz cert (short life)

Old-style Service CA service crl update mkgridmap GSI VO-VOMS VO-VOMS low frequency high frequency host cert (long life) service crl update VO-VOMS VO-VOMS Old-style services still use the gridmap-file for authorization gridftp EDG 1.4.x services EDG 2.x service in compatibility mode no advantage, but everything works as before... mkgridmap VO-VOMS user requests a certificate (once in every two-three years) user sends the requests to the CA, which sends back the signed certificate conversion to browser digestable PKCS12 format registration in the EDG LDAP-VO (once for the lifetime of the VO – you may change the certificate keys!) generats a proxy certificate (24 hours lifetime) host/service requests a certificate host/service sends the requests to the CA, which sends back the signed certificate retrival of the trusted CA certificates and their CRLs (automatically updated every night/week) generating a gridmap file from the LDAP database for authorization and mapping (automatically updated every night/week) user contacts a service: they exchange their certificates to authenticate each other; the service bases its authorization decision on the gridmap file (... currently) Real life example: The traveller goes to the destination country and shows up his passport at the border. The officer checks its validity by comparing it to the example passport from the issuing country. He also looks at the list of revoked passports (coming from the originating country) and the visa, which allows the traveller to enter the country. The traveller may also ask the officer to identify itself, so the authentication is also symmetric in the real life. gridmap-file VO-VOMS GSI

Replica Management RM user authentication & authorization info low frequency high frequency host cert information system RM user 1. VO affiliation user cert 2. service URI(s) for VOs in authz? proxy user requests a certificate (once in every two-three years) user sends the requests to the CA, which sends back the signed certificate conversion to browser digestable PKCS12 format registration in the EDG LDAP-VO (once for the lifetime of the VO – you may change the certificate keys!) generats a proxy certificate (24 hours lifetime) host/service requests a certificate host/service sends the requests to the CA, which sends back the signed certificate retrival of the trusted CA certificates and their CRLs (automatically updated every night/week) generating a gridmap file from the LDAP database for authorization and mapping (automatically updated every night/week) user contacts a service: they exchange their certificates to authenticate each other; the service bases its authorization decision on the gridmap file (... currently) Real life example: The traveller goes to the destination country and shows up his passport at the border. The officer checks its validity by comparing it to the example passport from the issuing country. He also looks at the list of revoked passports (coming from the originating country) and the visa, which allows the traveller to enter the country. The traveller may also ask the officer to identify itself, so the authentication is also symmetric in the real life. VO authz 3. calling the service (URI) edg-java- security authentication & authorization info

1. VO affiliation (AccessControlBase) Job Submission low frequency high frequency host cert information system CE user 1. VO affiliation (AccessControlBase) user cert 4. CEs for VOs in authz? WMS 3. job submission proxy user requests a certificate (once in every two-three years) user sends the requests to the CA, which sends back the signed certificate conversion to browser digestable PKCS12 format registration in the EDG LDAP-VO (once for the lifetime of the VO – you may change the certificate keys!) generats a proxy certificate (24 hours lifetime) host/service requests a certificate host/service sends the requests to the CA, which sends back the signed certificate retrival of the trusted CA certificates and their CRLs (automatically updated every night/week) generating a gridmap file from the LDAP database for authorization and mapping (automatically updated every night/week) user contacts a service: they exchange their certificates to authenticate each other; the service bases its authorization decision on the gridmap file (... currently) Real life example: The traveller goes to the destination country and shows up his passport at the border. The officer checks its validity by comparing it to the example passport from the issuing country. He also looks at the list of revoked passports (coming from the originating country) and the visa, which allows the traveller to enter the country. The traveller may also ask the officer to identify itself, so the authentication is also symmetric in the real life. VO authz MyProxy server 2. cert upload

authentication & authorization info Running a Job LCAS: authorization based on (multiple) VO/group/role attributes LCMAPS: mapping to user pool and to (multiple) groups default VO = default UNIX group other VO/group/role = other UNIX group(s) host cert MyProxy server CE cert (long term) voms-proxy-init WMS proxy user requests a certificate (once in every two-three years) user sends the requests to the CA, which sends back the signed certificate conversion to browser digestable PKCS12 format registration in the EDG LDAP-VO (once for the lifetime of the VO – you may change the certificate keys!) generats a proxy certificate (24 hours lifetime) host/service requests a certificate host/service sends the requests to the CA, which sends back the signed certificate retrival of the trusted CA certificates and their CRLs (automatically updated every night/week) generating a gridmap file from the LDAP database for authorization and mapping (automatically updated every night/week) user contacts a service: they exchange their certificates to authenticate each other; the service bases its authorization decision on the gridmap file (... currently) Real life example: The traveller goes to the destination country and shows up his passport at the border. The officer checks its validity by comparing it to the example passport from the issuing country. He also looks at the list of revoked passports (coming from the originating country) and the visa, which allows the traveller to enter the country. The traveller may also ask the officer to identify itself, so the authentication is also symmetric in the real life. VO 2. job start authz 1. cert download authentication & authorization info LCAS/ LCMAPS

VOMS FAQ No instant effect: the user has to “log-in”, using voms-proxy- init, to be notified of any VO change Delegation: a user cannot delegate her/his groups to someone else (unless s/he is a group-admin); no user groups Indirect effect on the policy: VOMS may name groups/roles in order to implement a policy, but it is up to the services to enforce it and up to the resource owner no to override it VOMS is not used to implement fine grained ACLs: it does not store file names or job ids (although it has its own ACLs for group/role administration)