1. Update on EDG Security (VOMS)
European DataGrid Project
Security Coordination Group

2. 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)
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)
to the administrator: new request notification
to the requestor: address confirmation
to the requestor: request is accepted/denied

3. Multi-VO registrationCA
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

4. 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)

5. 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)

6. 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

7. 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

8. 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

9. 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

10. 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)