Riccardo Gargana, INFN Roma Tre - PowerPoint PPT Presentation

About This Presentation
Title:

Riccardo Gargana, INFN Roma Tre

Description:

Roma, EUMEDGRID Tutorial, 11-13.09.2006. Riccardo Gargana, INFN Roma Tre. Authentication and Authorization in gLite. 2. FP62004 ... ciao. 3$r. ciao. 3$r ... – PowerPoint PPT presentation

Number of Views:161
Avg rating:3.0/5.0
Slides: 33
Provided by: riccardo7
Category:
Tags: infn | ciao | gargana | riccardo | roma | tre

less

Transcript and Presenter's Notes

Title: Riccardo Gargana, INFN Roma Tre


1
Authentication and Authorization in gLite
  • Riccardo Gargana, INFN Roma Tre

2
Grid security and trust
  • Providers of resources (computers, databases,..)
    need risks to be controlled they are asked to
    trust users they do not know
  • They trust a VO
  • The VO trusts its members
  • User needs
  • single sign-on to be able to logon to a machine
    that can pass the users identity to other
    resources
  • To trust owners of the resources they are using
  • Build middleware on layer providing
  • Authentication know who wants to use resource
  • Authorization know what the user is allowed to
    do
  • Security reduce vulnerability, e.g. from outside
    the firewall
  • Non-repudiation knowing who did what
  • The Grid Security Infrastructure middleware is
    the basis of (most) production grids

3
The Problems
  • How does a user securely access the Resource
    without having an account on the machines in
    between or even on the Resource?
  • How does the Resource know who a user is?
  • Which resource can you access, and what are you
    allowed to do?
  • Authentication how is identity of user/site
    communicated?
  • Authorisation what can a user do?

4
RISK vulnerability
  • Launch attacks to other sites
  • Large distributed farms of machines, perfect for
    launching a Distributed Denial of Service attack.
  • Illegal or inappropriate data distribution and
    access sensitive information
  • Massive distributed storage capacity ideal for
    example, for exchange movies.
  • Growing number of users have data that must be
    private biomedical imaging for example
  • Damage caused by viruses, worms etc.
  • Highly connected infrastructure means worms could
    spread faster than on the internet in general.

5
Basis of security (Public Key Algorithms)
  • Every user has two keys one private and one
    public
  • it is very difficult to derive the private key
    from the public one
  • a message encrypted by one key can be decrypted
    only by the other one.
  • Public keys are exchanged
  • The sender cyphers using the public key of the
    receiver
  • The receiver decrypts using his private key
  • The number of keys is O(n)

The Public key Algorithms assure that only the
receiver can be able to understand the messages
and allows to create a secure channel between the
user.
6
Basis of security (Digital Signature)
  • Paul calculates the hash of the message
  • Paul encrypts the hash using his private key the
    encrypted hash is the digital signature.
  • Paul sends the signed message to John.
  • John calculates the hash of the message
  • Decrypts signature, to get A, using Pauls
    public key.
  • If hashes equal 1. message wasnt
  • modified 2. hash A is from
    Pauls private key

Paul
message
Hash A
Digital Signature
Digital Signature allows to check the integrity
of the messages and the correspondence beetwen
the public key and the private key.
John
Pauls keys
Hash B
Hash A
public
private
7
Basis of security (Certification Authority)
  • How can John be sure that Pauls public key is
    really Pauls public key and not someone elses?
  • A third party certifies correspondence between
    the public key and Pauls identity.
  • Both John and Paul trust this third party
  • The third party is called a Certification
    Authority (CA).

Finally, the CA assure the correspondence
between the digital certificate and the
physical identity.
8
X.509 Certificates
  • An X.509 Certificate contains
  • owners public key
  • identity of the owner
  • info on the CA
  • time of validity
  • Serial number
  • Optional extensions
  • digital signature of the CA

9
The Grid Security Infrastructure (GSI)
  • every Grid transaction is mutually authenticated
  • Paul sends his certificate
  • John verifies signature in Pauls certificate
    using CA public certificate
  • John sends to Paul a challenge string
  • Paul encrypts the challenge string with his
    private key
  • Paul sends encrypted challenge to John
  • John uses Pauls public key to decrypt the
    challenge.
  • John compares the decrypted string with the
    original challenge
  • If they match, John verified Pauls identity and
    Paul can not repudiate it.
  • Repeat for Paul to verify Johns identity

JOHN
PAUL
Based on X.509 PKI
10
The Grid Security Infrastructure (GSI) - continued
Paul
After Paul and John uthenticated each other, for
Paul to send a message to John
John
  • Default message integrity checking
  • Not private a test for tampering
  • For private communication
  • Encrypt all the message (not just hash) - Slower

Message Encrypted hash
11
Certification Authorities
  • Users identity has to be certified by one of the
    national Certification Authorities (CAs)
  • Resources are also certified by CAs
  • CAs are mutually recognized http//www.gridpma.org
    /
  • Each CAs establish a number of people as
    registration authorities (RAs)
  • The RA is a link in the chain of trust RA check
    the identity of the users on CA behalf

12
Certificate Request
User generatespublic/privatekey pair in browser.
After RA blessing, CA signature links identity
and public key in certificate. CA informs user.
CertRequest Public Key
User sends public key to CA and shows RA proof of
identity.
Certification Authority
Private Key encrypted on local disk
13
Your personal certificate
  • Finally, everybody can have got a personal
    certificate signed by a CA. That certificate have
    one year of validity and identified yourself in
    to the grid and also in many different service
    provider on WWW. It s same to your passport,
    your ID card or your credit card in real life.
  • Where do you put your personal certificate and
    your private key?

14
User Responsibilities
  • Keep your private key secure on USB drive only
  • Do not loan your certificate to anyone.
  • Report to your local/regional contact if your
    certificate has been compromised.
  • Do not launch a delegation service for longer
    than your current task needs.

If your certificate or delegated service is used
by someone other than you, it cannot be proven
that it was not you.
15
Proxy Certificate
To authenticate himself the user does not use its
own long living certificate ? Security problems
may arise.
GSI extension to X.509 Identity Certificates
X.509 Proxy Certificate
16
X.509 Proxy Certificate
  • Proxy GSI extension to X.509 Identity
    Certificates
  • signed by the normal end entity cert (or by
    another proxy).
  • It enables single sign-on.
  • It supports some important features
  • Delegation
  • Mutual authentication
  • It has a limited lifetime (minimized risk of
    compromised credentials)
  • It is created by the grid-proxy-init command
  • grid-proxy-init
  • Enter PEM pass phrase
  • Options for grid-proxy-init
  • -hours ltlifetime of credentialgt
  • -bits ltlength of keygt
  • -help

17
grid-proxy-init
  • User enters pass phrase, which is used to decrypt
    private key.
  • Private key is used to sign a proxy certificate
    with its own, new public/private key pair.
  • Users private key not exposed after proxy has
    been signed
  • Proxy placed in /tmp
  • the private key of the Proxy is not encrypted
  • stored in local file must be readable only by
    the owner
  • proxy lifetime is short (typically 12 h) to
    minimize security risks.
  • NOTE No network traffic!

18
Proxy again
  • grid-proxy-init login to the Grid
  • To logout you have to destroy your proxy
  • grid-proxy-destroy
  • This does NOT destroy any proxies that were
    delegated from this proxy.
  • You cannot revoke a remote proxy
  • To gather information about your proxy
  • grid-proxy-info
  • Options for grid-proxy-info-subject -issuer-t
    ype -timeleft-strength -help

19
Delegation
  • Delegation remote creation of a (second level)
    proxy credential
  • New key pair generated remotely on server
  • Client signs proxy cert and returns it
  • Allows remote process to authenticate on behalf
    of the user
  • Remote process impersonates the user

20
  • Proxy has limited lifetime (default is 12 h)
  • Bad idea to have longer proxy
  • However, a grid task might need to use a proxy
    for much longer time
  • Grid jobs in HEP on LCG last up to 2 days
  • myproxy server
  • Allows to create and store a long term proxy
    certificate
  • myproxy-init -s lthost_namegt
  • -s lthost_namegt specifies the hostname of the
    myproxy server
  • myproxy-info
  • Get information about stored long living proxy
  • myproxy-get-delegation
  • Get a new proxy from the MyProxy server
  • myproxy-destroy
  • Check out the myproxy-xxx --help option for more
    information
  • A dedicated service on the RB can renew
    automatically the proxy
  • File transfer services in gLite validates user
    request and eventually renew proxies
  • contacting myproxy server

Long term proxy --gt Myproxy
21
Grid authentication with MyProxy
WS
UI PnP
I
n
s
t
a
l
l
Job Run
Job Done
22
Coffee break
23
VOs and authorization
  • Grid users MUST belong to virtual organizations
  • It was called groups previously.
  • It defines sets of users belonging to a
    collaboration
  • User must sign the usage guidelines for the VO
  • You will be registered in the VO-LDAP server
    (wait for notification)
  • List of supported VOs
  • https//lcg-registrar.cern.ch/virtual_organization
    .html
  • VOs maintain a list of their members on a LDAP
    Server
  • The list is downloaded by grid machines to map
    user certificate subjects to local pool
    accounts
  • Sites decide which VOs to support
  • /etc/grid-security/grid-mapfile

Absolete
"/CCH/OCERN/OUGRID/CNSimone Campana 7461"
.dteam "/CCH/OCERN/OUGRID/CNAndrea Sciaba
8968" .cms "/CCH/OCERN/OUGRID/CNPatricia
Mendez Lorenzo-ALICE" .alice
24
VOMS concepts
  • Virtual Organization Membership Service (VOMS) is
    a service that keeps track of the members of a VO
    and grants them a set of attributes, that get
    included in the users proxy certificate at proxy
    creation time.

25
VOMS concepts-2
  • Virtual Organization Membership Service
  • Extends the proxy with info on VO membership,
    group, roles
  • Fully compatible with the software of
    authetication (Globus Toolkit)
  • Each VO has a database containing group
    membership, roles and capabilities information
    for each user
  • User contacts voms server requesting his
    authorization info
  • Server sends authorization info to the client,
    which includes them in a proxy certificate

glite-tutor /home/garganagt voms-proxy-init
--voms gilda Cannot find file or dir
/home/gargana/.glite/vomses Your identity
/CIT/OGILDA/OUPersonal Certificate/LINFN-ROMA3
/CNRiccardo Gargana/Emailgargana_at_roma3.infn.it E
nter GRID pass phrase Your proxy is valid until
Mon Jan 30 233551 2006 Creating temporary
proxy.................................Done Contact
ing voms.ct.infn.it15001 /CIT/OGILDA/OUHost/
LINFN Catania/CNvoms.ct.infn.it/Emailemidio.gio
rgio_at_ct.infn.it "gilda" Creating proxy
...................................... Done Your
proxy is valid until Mon Jan 30 233551 2006
26
FQAN and AC
  • FQAN short for Fully Qualified Attribute Name, is
    what VOMS uses to express membership and other
    authorization info
  • Groups membership, roles and capabilities may be
    expressed in a format that bounds them
    togetherltgroupgt/Roleltrolegt/Capabilityltcapabi
    litygt
  • FQAN are included in an Attribute Certificate
  • Attribute Certificates are used to bind a set of
    attributes (like membership, roles, authorization
    info etc) with an identity
  • ACs are digitally signed
  • VOMS uses AC to include the attributes of a user
    in a proxy certificate
  • glite-tutor /home/gargana gt voms-proxy-info
    -fqan
  • /gilda/RoleNULL/CapabilityNULL
  • /gilda/tutors/RoleNULL/CapabilityNULL

27
VOMS and AC
  • Server creates and signs an AC containing the
    FQAN requested by the user, if applicable
  • AC is included by the client in a well-defined,
    non critical, extension assuring compatibility
    with GT-based mechanism

/home/gargana gt voms-proxy-info -all subject
/CIT/OGILDA/OUPersonal Certificate/LINFN-ROMA3
/CNRiccardo Gargana/Emailriccardo.gargana_at_roma3.
infn.it/CNproxy issuer /CIT/OGILDA/OUPers
onal Certificate/LINFN-ROMA3/CNRiccardo
Gargana/Emailgargana_at_roma3.infn.it identity
/CIT/OGILDA/OUPersonal Certificate/LINFN-ROMA3
/CNRiccardo Gargana/Emailgargana_at_roma3.infn.it t
ype proxy strength 512 bits path
/tmp/x509up_u513 timeleft 115952 VO
gilda extension information VO
gilda subject /CIT/OGILDA/OUPersonal
Certificate/LINFN-ROMA3/CNRiccardo
Gargana/Emailgargana_at_roma3.infn.it issuer
/CIT/OGILDA/OUHost/LINFN Catania/CNvoms.ct.in
fn.it/Emailemidio.giorgio_at_ct.infn.it attribute
/gilda/tutors/RoleNULL/CapabilityNULL attribute
/gilda/RoleNULL/CapabilityNULL timeleft
115945
Standard globus attributes
Voms extensions
28
Evolution of VO management
  • Before VOMS
  • User is authorised as a member of a single VO
  • All VO members have same rights
  • Gridmapfiles are updated by VO management
    software map the users DN to a local account
  • grid-proxy-init
  • VOMS
  • User can be in multiple VOs
  • Aggregate rights
  • VO can have groups
  • Different rights for each
  • Different groups of experimentalists
  • Nested groups
  • VO has roles
  • Assigned to specific purposes
  • E,g. system admin
  • When assume this role
  • Proxy certificate carries the additional
    attributes
  • voms-proxy-init

VOMS now in use on EGEE grid
29
Summary of AA - 1
  • Authentication based on X.509 PKI infrastructure
  • Trust between Certificate Authorities (CA) and
    sites, CAs and users is established (offline)
  • CAs issue (long lived) certificates identifying
    sites and individuals (much like a passport)
  • Commonly used in web browsers to authenticate to
    sites
  • In order to reduce vulnerability, on the Grid
    user identification is done by using (short
    lived) proxies of their certificates
  • Proxies can
  • Be delegated to a service such that it can act on
    the users behalf
  • Include additional attributes (like VO
    information via the VO Membership Service VOMS)
  • Be stored in an external proxy store (MyProxy)
  • Be renewed (in case they are about to expire)

30
  • User certificate files
  • Certificate X509_USER_CERT
  • (default HOME/.globus/usercert.pem)
  • Private key X509_USER_KEY
  • (default HOME/.globus/userkey.pem)
  • Proxy X509_USER_PROXY
  • (default /tmp/x509up_ultidgt)
  • Host certificate files
  • Certificate X509_HOST_CERT
  • (default /etc/grid-security/hostcert.pem)
  • Private key X509_HOST_KEY
  • (default /etc/grid-security/hostkey.pem)

GSI environment variables
31
GSI environment variables
  • Trusted certification authority certificates
  • X509_CERT_DIR
  • (default /etc/grid-security/certificates)
  • Voms server public keys
  • X509_VOMS_DIR
  • (default /etc/grid-security/vomsdir)

32
References
  • Grid
  • LCG Security http//proj-lcg-security.web.cern.ch
    /proj-lcg-security/
  • LCG Registration http//lcg-registrar.cern.ch/
  • Globus Security http//www.globus.org/security/
  • VOMS http//infnforge.cnaf.infn.it/projects/voms
  • IGTF for trusted CAs http//www.gridpma.org/
  • Background
  • GGF Security http//www.gridforum.org/security/
  • IETF PKIX charter http//www.ietf.org/html.charte
    rs/pkix-charter.html
  • PKCS http//www.rsasecurity.com/rsalabs/pkcs/inde
    x.html

33
Questions
?
Write a Comment
User Comments (0)
About PowerShow.com