Security 2 Advanced Concepts Dr John Watt Grid

Security 2: Advanced Concepts Dr John Watt Grid Security Engineer National e-Science Centre University of Glasgow j. watt@nesc. gla. ac. uk 12 th July 2006 ISSGC 06, Ischia July 2006

Overview Authorisation (11. 00 -11. 30) What Can I Do? ? Too many models… Access Control Lists/Role Based Access Control Privilege Management Infrastructures (PMIs) Tools of the Trade Security in Practise (11. 30 -12. 30) The Grid Security Infrastructure (GSI) Shibboleth and Federated Trust Current Activities and The Way Ahead… ISSGC 06, Ischia July 2006

Importance of Security What happens when your system is not secure Large communities will not engage u medical community, industry, financial community … Legal and ethical issues possible to be violated with all sorts of consequences u e. g. data protection act violations and fines incurred Expensive (impossible? ) to repeat some experiments u Huge machines running large simulations for several years Trust is easily lost and hard to re-establish Grid resources are a dream for hackers u u Huge file storage for keeping their “dodgy data” Perfect environment for launching attacks like distributed denial of service – Not just access to one machine » whole interconnected networks of ultra performant machines which can be used for cracking passwords, codes, launching distributed denial of service attacks, … ISSGC 06, Ischia July 2006

The Challenge of Grid Security Grid predicts scenarios that stretch interorganisational security Imagine two distributed virtual organisations agreeing to share resources, e. g. compute/data resources to accomplish some task with sharing done across internet u u u Could have policies that restrict access to and usage of resources based on pre-identified users, resources But what if new resources added, new users added, old users go, …? What if organisations decide to change policies governing access to and usage of resources? What if want to transfer large data sets between different organisations – how to ensure that data is not cached somewhere it might be compromised? … ISSGC 06, Ischia July 2006

The Challenge of Grid Security Grids allow (or should allow!) dynamic establishment of virtual organisations (VOs) These can be arbitrarily complex u u Grids (VOs) might include highly secure supercomputing facilities through to single user PCs/laptops Need security technologies that scales to meet wide variety of applications – from highly secure medical information data sets through to particle physics/public genome data sets – Using services for processing of patient data through to “needle in haystack” searching of physics experiments or protein sequence similarity of genomic data Should try to develop generic Grid security solutions u Avoid all application areas re-inventing their own (incompatible/inoperable) solutions ISSGC 06, Ischia July 2006

What we need is… Technologies for establishment of arbitrary VOs need rules/contracts (policies) u Who can do what, on what, in what context, … Policies can be direct assertions/obligations/prohibitions on specific resources/users Policies can be local to VO members/resources u e. g. user X from site A can have access to P% resource B on site C – (site C responsible for local policy – autonomy!!!) Policies can be on remote resources u users from site A can access / download data Y from site B provided they do not make it available outside of site A – …site B trusts site A to ensure this is the case » and possibly to ensure that the security is comparable with site B » … trust!!! ISSGC 06, Ischia July 2006

Authorisation ISSGC 06, Ischia July 2006

What Can I Do? Identity established through authentication No info on user permissions/rights/privilege A separate infrastructure is needed to manage user privilege This infrastructure should support the scenarios just described Authorisation is an ongoing research area with many solutions Most solutions involve integrating many separate technologies u And often many Auth. Z techs ISSGC 06, Ischia July 2006

So many models… Various technologies for authorization including PERMIS u Privil. Ege and Role Management Infrastructure Standards Validation – http: //www. permis. org VOMS u http: //hep-project-grid-scg. web. cern. ch/hep-project-grid-scg/voms. html Community Authorisation Service u http: //www. globus. org/security/CAS/ AKENTI u http: //www-itg. lbl. giv/security/akenti CARDEA u http: //www. nasa. gov/Research/Reports/Techreports/2003/nas-03 -020 abstract. html All of them predominantly work at the local policy level ISSGC 06, Ischia July 2006

Access Control Lists (ACLs) Lets start with the simplest scenario: Once a user has authenticated they are checked against a local list of users Simple to understand works well for mini-grids The generic Auth. Z for GSI (Grid Security Infrastructure) is an ACL u u Will show you one in the next section But remember they have defined the GGF API to use with ANY Auth. Z But. . What if access to a resource is needed for a different purpose by the same person? u Multiple entries or multiple lists? What if we want HUNDREDS of users? u BUSY, BUSY sys admins!! ISSGC 06, Ischia July 2006

A better way… Just a straight list of users is too difficult to maintain and is not flexible enough for Grids What defines a persons permissions on a resource usually? What kind of jobs do people have? u Doctor, Nurse, Student, Lecturer, Director, CEO, Sys. Admin, Ph. D People come and go but job descriptions generally are static u Any exceptions should be easy to manage Can you see where this may be going. . ? ISSGC 06, Ischia July 2006

Role Based Access Control Access to a resource should be granted according to a user’s ROLE within the VO Multiple Roles may be held by a user u u Different levels of Auth. Z may be enforced. Role hierarchies may be supported Access may be granted by Role only u If anonymous access is required No policy changes required as users come and go u Happy sys admins! Just grant them the necessary role when they join the VO and they will have access. . u So how do we grant roles to users? u ISSGC 06, Ischia July 2006

Privilege Management Infrastructures (PMIs) We can utilise the secure infrastructure provided by X. 509 certificates to assign roles to users We need an extension to the X. 509 specification to support PRIVILEGE ATTRIBUTES So as well as the normal info in their certificate, a user may be assigned one or more ATTRIBUTE CERTIFICATES which contain a signed assertion of their role within the VO Many similarities to PKIs… ISSGC 06, Ischia July 2006

PKI and PMI A PMI is to authorisation what a PKI is to authentication – hence similar concepts Concept PKI Entity PMI Entity Certificate Public Key Certificate (PKC) Attribute Certificate (AC) Certificate Issuer Certification Authority (CA) Attribute Authority (AA) Certificate User Subject Holder Certificate Binding Subject’s name to Public Key Holder’s Name to Privilege Attribute(s) Revocation Certificate Revocation List (CRL) Attribute Certificate Revocation List (ACRL) Root of trust Root Certification Authority or Trust Anchor Source of Authority (SOA) Subordinate authority Subordinate Certification Authority Attribute Authority (AA) ISSGC 06, Ischia July 2006

Generic Authorisation A generic framework for authorisation is defined in X. 812 ISO 10181 -3 Acc. Ctrl. Framework ISSGC 06, Ischia July 2006

Grid APIs for Generic Authorisation SAML Auth. Z specification provides generic PEP approach for Grid services … or at least all GT 3. 3+ based services ISSGC 06, Ischia July 2006

Grid API for Generic Authorisation This API allows a generic policy enforcement engine to be created One PEP and PDP may be deployed on your resource Each application may use a different policy (and attribute repository) as required u This will be specified when the application is deployed – In Grid Service Deployment descriptor What should these policies look like? ISSGC 06, Ischia July 2006

Access Control Policies Basic idea is to define: roles applicable to specific VO u roles often hierarchical – Role X ≥ Role Y ≥ Role Z – Manager can do everything (and more) than an employee can do who can do everything (and more) than a trainee can do actions allowed/not allowed for VO members resources comprising VO infrastructure (computers, data resources etc) A policy then consists of sets of these rules u u { Role x Action x Target } – Can user with VO role X invoke service Y on resource Z? Policy itself can be represented in many ways, – e. g. XML document, SAML, XACML, … ISSGC 06, Ischia July 2006

Tools of the Trade CAS – Community Authorization Service Resource providers specify a coarse-grained policy u They grant the privileges to the community Fine grained policy decisions delegated to the community administrator served by CAS u u Resource providers have established a trust relationship with this administrator The Administrator uses CAS to distribute privileges to the community User requests access to resource with their cert. u If CAS decides they have sufficient privileges, they are sent a proxy certificate with an embedded policy allowing access to the resource ISSGC 06, Ischia July 2006

Tools of the Trade VOMS – Virtual Organization Membership Service Part of European Data. Grid project Supplies a database for storing authorisation data for users (and manipulation tools) Proxy credentials can be generated that contain VOMS Auth. Z info as well as generic GSI info Very flexible – u u Grid apps can use credentials and ignore VOMS data. VOMS apps can use the Auth. Z info. Or both… ISSGC 06, Ischia July 2006

PERMIS Privilege and Role Management Infrastructure Standards Validation A generic Java API for Authorization u Can protect many applications Compliant with the GGF SAML API PERMIS grants access to resources based on presented Attribute Certificates which are checked against the local policy ---- ISSGC 06, Ischia July 2006

PERMIS Policy Subject Policy Specifies the domain (as an LDAP subtree) of users who may be granted roles within the PMI ISSGC 06, Ischia July 2006

PERMIS Policy Source Of Authority (SOA) policy Lists the LDAP DNs of SOAs which are trusted to issue roles to the subjects specified above First name listed is the LDAP DN of the policy creator (required), subsequent names are SOAs which are “cross-certified” by the policy creator This name(s) will become the root issuer name(s) in a signed Attribute Certificate u Any trusted AC for this policy must have been signed by one of them ISSGC 06, Ischia July 2006

PERMIS Policy Role Hierarchy Policy Defines the role hierarchies supported by this policy Specified as a “directed graph” of Superior-Subordinate attribute values Each role named using an attribute type, attribute value pair (e. g. permis. Role, Slave) ISSGC 06, Ischia July 2006

PERMIS Policy Role Assignment Policy Specifies which roles can be given to which subjects by which SOAs Supports delegation and time constraints (not used here) ISSGC 06, Ischia July 2006

PERMIS Policy Repository Policy Allows the PDP to search multiple LDAP directories One of the policy statements that supports Dynamic Delegation (more later) ISSGC 06, Ischia July 2006

PERMIS Policy Target Policy Specifies the target domains covered by this policy Give the name of your Grid Service you want to protect here ISSGC 06, Ischia July 2006

PERMIS Policy Action Policy Defines the actions (operations on targets) supported by this policy Lets say the My. Company Grid Service operates the doors in the My. Company building… ‘Name’ is the specific command to perform the action ISSGC 06, Ischia July 2006 Name=“lock. Main. Door”/> Name=“unlock. Main. Door”/> Name=“lock. Office. Door”/> Name=“unlock. Office. Door”/> Name=“get. Main. Door. Status”/>

PERMIS Policy Target Access Policy Specifies which roles are needed to access which targets for which actions (+ under what conditions) Operates a Deny All Unless Specifically Granted rule One must possess all roles within a target clause to gain access (may need multiple ACs to access) etc… ISSGC 06, Ischia July 2006

PERMIS Policy Editor PERMIS Policies created with PERMIS Policy. Editor (output is XML based policy – verified with DTD) PERMIS Privilege Allocator (and Attribute Certificate Manager) then used to sign policies u Policies stored as attribute certificates in LDAP server ISSGC 06, Ischia July 2006

Another Problem… The Source of Authority signs ACs He holds the So. A key pair But he may want to delegate the ability to sign ACs to someone else u u And they may wish to delegate the ability down again… Remember these are longer lasting certificates than proxies – And a CA doesn’t want you signing certs on their behalf!! Each of these people will require a key pair within the PMI to sign ACs u u Not such a big deal? ? What happens if one of the certificates in this chain needs to be revoked? – The chain above this certificate becomes invalid – When a service tries to use the certificate, the trust chain checker finds that one certificate in the chain can’t be verified – DENIED!! ISSGC 06, Ischia July 2006

Delegation Issuing Service DIS creates a special user (called DIS) who holds a key pair and will be responsible for signing all the ACs in the PMI Umm. . Aren’t we doing this already!? No, this DIS user can be accessed by anyone in the PMI who is authorised by the So. A u u u The So. A delegates the ability to assign attributes to subordinate USERS by giving them ACs with a DELEGATION STATEMENT – So. A gets this ability from the Delegation part of the Policy The USER logs into the DIS and assigns roles based on the abilities they have been delegated from their AC BUT when they sign the certificate, it is actually the DIS that signs it – This means that any certificates that get revoked will not affect any others ISSGC 06, Ischia July 2006

Delegation Issuing Service DIS is the newest tool in PERMIS Provides a revocation proof AC trust chain BUT ALSO… DIS issues ACs by consulting the Policy first for verification u This is different from the Attribute Certificate Manager tool which (provided you hold a valid key pair) allows you to issue ANY certificate you want (even roles that don’t exist!) ISSGC 06, Ischia July 2006

Delegation Issuing Service There are two more tools being developed by PERMIS which aim to provide a dynamic way to establish VOs Both may be implemented NOW through policy manipulation u But we want to get away from that as the policy should be set in stone, VOs should connect not dictate policies Role Mapping u The equating of roles at different institutions and any inheritance Cross-Certification u The recognition of an external Source of Authority ISSGC 06, Ischia July 2006

Authorisation in the Future PERMIS is providing a powerful set of tools to allow complex ACs to be created and verified with dynamic VO capabilities VOMS ACs are directly compatible with Globus Toolkit A powerful Grid Authorisation infrastructure will feature a composite of these functions Is this what we asked for in slide 6 (“What We Need Is? ”) ? ? ? u Hopefully some of you may be asked to give the answer! But the future is Privilege Management… ISSGC 06, Ischia July 2006

Security in Practise ISSGC 06, Ischia July 2006

Grid Security Infrastructure (GSI) Standard mechanism for interfacing Grids Supports X 509 proxy certificates for Authentication (Last Lecture) u u Created with the “grid-proxy-init” command Proxy certificate stored in /tmp directory Establishes connections between services by Mutual Authentication u u u Preliminary messages are exchanged and encrypted/decrypted Signatures and CAs are verified If this checks out then both parties know who they are talking to ISSGC 06, Ischia July 2006

Grid Security Infrastructure (GSI) Uses an Access Control List called a grid-mapfile for Authorisation u u But still can use GGF SAML Callout to other Auth. Z functions Stored in the /etc/grid-security/ directory “/C=UK/O=e. Science/OU=Glasgow/L=Compserv/CN=steve kee” skee “/C=UK/O=e. Science/OU=Edinburgh/L=Ne. SC/CN=stewart mills” smills “/C=UK/O=e. Science/OU=Glasgow/L=Compserv/CN=iain mcbride” imcbride “/C=UK/O=e. Science/OU=Aberdeen/L=Ge. SC/CN=nikki salter” nsalter “/C=UK/O=e. Science/OU=Newcastle/L=NERe. SC/CN=nicola wightman” nwightman “/C=UK/O=e. Science/OU=London/L=Le. SC/CN=scott mccaig” smccaig “/C=UK/O=e. Science/OU=Glasgow/L=Compserv/CN=kev mcneil” kmcneil “/C=UK/O=e. Science/OU=Glasgow/L=Compserv/CN=nik martin” nmartin “/C=UK/O=e. Science/OU=Edinburgh/L=Ne. SC/CN=ann robertson” aroberts ISSGC 06, Ischia July 2006

Federated Trust Local authentication infrastructures are vital e. g. Campus student directories u Support existing infrastructures (e. g. registration, human resources) – Will normally have enrolled IN PERSON at the institution » With standard identity (birth certificate, exam results) – Will be (reasonably) well known by local staff Also the Regional Operators for a CA u Required decentralisation of credential verification due to travel/time restrictions – National CA would be impossible without this Remote authentication information will always be out of date Don’t want to have to learn lots of usernames/passwords ISSGC 06, Ischia July 2006

Federated Trust The best entity to authenticate a person is their home institution/company Info will be up to date They will always know a person better than a remote site Remote site may not know if user is still valid or not Can we utilise a user’s home credentials to access remote resources? ISSGC 06, Ischia July 2006

Federated Authentication system using SAML for secure conversation Enables Single-Sign On to Web Pages and Portals Authentication is done by the user’s home institution Identity Provider (Origin) Authorisation (and access) is done by the resource Service Provider (Target) ISSGC 06, Ischia July 2006

Identity Provider Service Provider Application Home Institution Federation Authz WAYF User ISSGC 06, Ischia July 2006 Grid Portal

Application Home Institution Federation Authz WAYF Point browser to portal User ISSGC 06, Ischia July 2006 Grid Portal

Identity Provider Service Provider Application Home Institution Federation Authz WAYF User Shibboleth redirects user to W. A. Y. F service ISSGC 06, Ischia July 2006 Grid Portal

Identity Provider Service Provider Application Home Institution Federation Authz User selects their home institution WAYF User ISSGC 06, Ischia July 2006 Grid Portal

Identity Provider LDAP Service Provider AUTHENTICATE Home confirms user ID in local LDAP and pushes attributes to the service provider Application Home Institution Federation Authz WAYF User ISSGC 06, Ischia July 2006 Grid Portal

Identity Provider Service Provider Application Home Institution Federation Authz WAYF User Portal logs user in and presents attributes to authorisation function ISSGC 06, Ischia July 2006 Grid Portal

Identity Provider AUTHORISE Portal passes attributes to Auth. Z function to make final access control decision Service Provider Application Home Institution Federation Authz WAYF User ISSGC 06, Ischia July 2006 Grid Portal

The Overall Picture? Shibboleth Distributed Authentication Mechanism PERMIS/DIS Advanced Dynamic Authorisation Infrastructure VOMS/My. Proxy Grid Credential Repositories GSI Globus Toolkit Security Infrastructure + other projects (Grid. Shib looking very good) ISSGC 06, Ischia July 2006

Glasgow e-Science Hub Externally u Glasgow end of Ne. SC – Involved in UK wide activities » Involved in numerous life science/security related projects (more later) – Public visibility of Ne. SC » responsible for Ne. SC web site (www. nesc. ac. uk) Internally u u Focal point for e-Science research/activities at Glasgow Work closely with foundation departments » Department of Computing Science » Department of Physics & Astronomy u Also working with other groups including » » Bioinformatics Research Centre Biostatistics Electronics and Electrical Engineering Clinicians, Hospitals, across Scotland, … ISSGC 06, Ischia July 2006

Glasgow e-Science Infrastructure Consolidating resources Story started with building around Scot. Grid u Providing shared Grid resource for wide variety of scientists inside/outside Glasgow – HEP, CS, BRC, EEE, … » Target shares established » Non-contributing groups encouraged Scot. Grid [ Disk ~15 TB CPU ~ 330 1 GHz ] Over 2 million CPU hours completed (May 2005) Over 230, 000 jobs completed Includes time out for major rebuilds Typically running at ~90% usage ISSGC 06, Ischia July 2006

Overview of BRIDGES Biomedical Research Informatics Delivered by Grid Enabled Services (BRIDGES) Ne. SC (Edinburgh and Glasgow) and IBM Started October 2003 – Ended October 2005 Supporting project for CFG project Generating data on hypertension Rat, Mouse, Human genome databases Variety of tools used BLAST, BLAT, Gene Prediction, visualisation, … Variety of data sources and formats Microarray data, genome DBs, project partner research data, … Aim is integrated infrastructure supporting Data federation Security ISSGC 06, Ischia July 2006

BRIDGES Project VO Authorisation Information Integrator OGSA-DAI Magna Vista Service st bla Synteny Service + ISSGC 06, Ischia July 2006 + +

ISSGC 06, Ischia July 2006

VOTES Virtual Organisations for Trials and Epidemiological Studies 3 year MRC (£ 2. 8 M) funded project Plans to develop Grid infrastructure to address key components of clinical trial/observational study u u u Recruitment of potentially eligible participants Data collection during the study Study administration and coordination – Involves Glasgow, Oxford, Leicester, Nottingham, Manchester ISSGC 06, Ischia July 2006

Dy. VOSE Project Dynamic Virtual Organisations for e-Science Education (Dy. VOSE) project Two year project started 1 st May 2004 funded by JISC Exploring advanced authorisation infrastructures for security u … in Grid Computing Module as part of advanced MSc at Glasgow – Provide insight into rolling Grid out to the masses! ISSGC 06, Ischia July 2006

Dy. VOSE Phase 2/3 Glasgow Scot. Grid Edinburgh Condor pool Blue Dwarf Dynamically established VO resources/users Delegated VO policies Glasgow Education VO policies Shibboleth PERMIS based Authorisation checks/decisions ISSGC 06, Ischia July 2006 Edinburgh Education VO policies

Dy. VOSE Project ‘Shibbolized’ Grid Portal Search/sort text service Deployed in Grid. Sphere PERMIS protected for two separate teams u DIS Service used for ACs in Second Year Outstanding issues The ‘tier 2’ problem u How to bridge local credentials with global Grid ones… ISSGC 06, Ischia July 2006

Summary Authorisation has many solutions which may be complementary The future Grid will have to utilise Privilege Management if is to scale Push to make access to the Grid as easy as possible (use existing passwords/Shibboleth) ISSGC 06, Ischia July 2006