1 / 59

Security 2: Advanced Concepts

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. Overview. Authorisation (11.00-11.30) What Can I Do?? Too many models… Access Control Lists/Role Based Access Control

petra
Download Presentation

Security 2: Advanced Concepts

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

  3. Importance of Security • What happens when your system is not secure • Large communities will not engage • medical community, industry, financial community … • Legal and ethical issues possible to be violated with all sorts of consequences • e.g. data protection act violations and fines incurred • Expensive (impossible?) to repeat some experiments • Huge machines running large simulations for several years • Trust is easily lost and hard to re-establish • Grid resources are a dream for hackers • 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, …

  4. The Challenge of Grid Security • Grid predicts scenarios that stretch inter-organisational security • Imagine two distributed virtual organisations agreeing to share resources, e.g. compute/data resources to accomplish some task with sharing done across internet • 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? • …

  5. The Challenge of Grid Security • Grids allow (or should allow!) dynamic establishment of virtual organisations (VOs) • These can be arbitrarily complex • 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 • Avoid all application areas re-inventing their own (incompatible/inoperable) solutions

  6. What we need is… • Technologies for establishment of arbitrary VOs • need rules/contracts (policies) • 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 • 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 • 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!!!

  7. Authorisation

  8. 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 • And often many AuthZ techs

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

  10. 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 and works well for mini-grids • The generic AuthZ for GSI (Grid Security Infrastructure) is an ACL • Will show you one in the next section • But remember they have defined the GGF API to use with ANY AuthZ • But.. • What if access to a resource is needed for a different purpose by the same person? • Multiple entries or multiple lists? • What if we want HUNDREDS of users? • BUSY, BUSY sys admins!!

  11. 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? • Doctor, Nurse, Student, Lecturer, Director, CEO, SysAdmin, PhD • People come and go but job descriptions generally are static • Any exceptions should be easy to manage • Can you see where this may be going..?

  12. 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 • Different levels of AuthZ may be enforced. • Role hierarchies may be supported • Access may be granted by Role only • If anonymous access is required • No policy changes required as users come and go • Happy sys admins! • Just grant them the necessary role when they join the VO and they will have access.. • So how do we grant roles to users?

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

  14. PKI and PMI • A PMI is to authorisation what a PKI is to authentication – hence similar concepts

  15. Generic Authorisation • A generic framework for authorisation is defined in X.812 ISO 10181-3 Acc. Ctrl. Framework

  16. Grid APIs for Generic Authorisation • SAML AuthZ specification provides generic PEP approach for Grid services • … or at least all GT3.3+ based services

  17. 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 • This will be specified when the application is deployed • In Grid Service Deployment descriptor • What should these policies look like?

  18. Access Control Policies • Basic idea is to define: • roles applicable to specific VO • 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 • { 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, …

  19. Tools of the Trade • CAS – Community Authorization Service • Resource providers specify a coarse-grained policy • They grant the privileges to the community • Fine grained policy decisions delegated to the community administrator served by CAS • 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. • If CAS decides they have sufficient privileges, they are sent a proxy certificate with an embedded policy allowing access to the resource

  20. Tools of the Trade • VOMS – Virtual Organization Membership Service • Part of European DataGrid project • Supplies a database for storing authorisation data for users (and manipulation tools) • Proxy credentials can be generated that contain VOMS AuthZ info as well as generic GSI info • Very flexible – • Grid apps can use credentials and ignore VOMS data. VOMS apps can use the AuthZ info. • Or both…

  21. PERMIS • Privilege and Role Management Infrastructure Standards Validation • A generic Java API for Authorization • 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 ----

  22. PERMIS Policy • Subject Policy • Specifies the domain (as an LDAP subtree) of users who may be granted roles within the PMI <SubjectPolicy> <SubjectDomainSpec ID=“MyCompany”> <Include LDAPDN=“o=My Organisation,C=GB”/> <Exclude LDAPDN=“ou=OtherCompany,o=MyOrganisation,C=GB”/> </SubjectDomainSpec> <SubjectDomainSpec ID=“everyoneElse”> <Include LDAPDN=“”/> </SubjectDomainSpec> </SubjectPolicy>

  23. 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 • Any trusted AC for this policy must have been signed by one of them <SOAPolicy> <SOASpec ID=“MyCompanyAdmin” LDAPDN=“cn=Admin,o=MyOrganisation,C=GB”/> </SOAPolicy>

  24. 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. permisRole,Slave) <RoleHierarchyPolicy> <RoleSpec OID=“1.2.345.0.1.321432.1.1.14” Type=“permisRole”> <SupRole Value=“Boss”> <SubRole Value=“Slave”> </SupRole> <SupRole Value=“Slave”> </RoleSpec> </RoleHierarchyPolicy>

  25. 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) <RoleAssignmentPolicy> <RoleAssignment ID=“MyCompanyAdminAllocator”> <SubjectDomain ID=“MyCompany”/> <RoleList> <RoleType=“permisRole” Value=“Boss”/> <RoleType=“permisRole” Value=“Slave”/> </RoleList> <Delegate Depth=“0”/> <SOA ID=“MyCompanyAdmin”/> <Validity/> </RoleAssignment> </RoleAssignmentPolicy>

  26. PERMIS Policy • Repository Policy • Allows the PDP to search multiple LDAP directories • One of the policy statements that supports Dynamic Delegation (more later) <RepositoryPolicy> <LDAP=“ldap://ldap.server.ac.uk”/> <LDAP=“ldap://another.ldap.server.ac.uk”/> </RepositoryPolicy>

  27. PERMIS Policy • Target Policy • Specifies the target domains covered by this policy • Give the name of your Grid Service you want to protect here <TargetPolicy> <TargetDomainSpec ID=“MyCompanyGridService”> <Include URL=“http://localhost:8080/ogsa/services/GridServices/ core/first/MyCompanyGridService”/> </TargetDomainSpec> </TargetPolicy>

  28. PERMIS Policy • Action Policy • Defines the actions (operations on targets) supported by this policy • Lets say the MyCompany Grid Service operates the doors in the MyCompany building… • ‘Name’ is the specific command to perform the action <ActionPolicy> <Action Args=“MyCompanyGridService” Name=“lockMainDoor”/> <Action Args=“MyCompanyGridService” Name=“unlockMainDoor”/> <Action Args=“MyCompanyGridService” Name=“lockOfficeDoor”/> <Action Args=“MyCompanyGridService” Name=“unlockOfficeDoor”/> <Action Args=“MyCompanyGridService” Name=“getMainDoorStatus”/> <Action Args=“MyCompanyGridService” Name=“getOfficeDoorStatus”/> </ActionPolicy>

  29. 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) <TargetAccessPolicy> <TargetAccess ID=“public”> <RoleList/> <TargetList> <Target Actions=“getMainDoorStatus,getOfficeDoorStatus”> <TargetDomain ID=“MyCompanyGridService”/> </Target> </TargetList> </TargetAccess> <TargetAccess ID=“slaves”> <RoleList> <RoleType=“permisRole” Value=“slave”/> </RoleList> <TargetList> <Target Actions=“unlockOfficeDoor,lockOfficeDoor”> etc…

  30. PERMIS Policy Editor • PERMIS Policies created with PERMIS PolicyEditor (output is XML based policy – verified with DTD) • PERMIS Privilege Allocator (and Attribute Certificate Manager) then used to sign policies • Policies stored as attribute certificates in LDAP server

  31. Another Problem… • The Source of Authority signs ACs • He holds the SoA key pair • But he may want to delegate the ability to sign ACs to someone else • 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 • 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!!

  32. 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 SoA • The SoA delegates the ability to assign attributes to subordinate USERS by giving them ACs with a DELEGATION STATEMENT • SoA 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

  33. 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 • 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!)

  34. 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 • But we want to get away from that as the policy should be set in stone, VOs should connect not dictate policies • Role Mapping • The equating of roles at different institutions and any inheritance • Cross-Certification • The recognition of an external Source of Authority

  35. 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?”) ??? • Hopefully some of you may be asked to give the answer! • But the future is Privilege Management…

  36. Security in Practise

  37. Grid Security Infrastructure (GSI) • Standard mechanism for interfacing Grids • Supports X509 proxy certificates for Authentication (Last Lecture) • Created with the “grid-proxy-init” command • Proxy certificate stored in /tmp directory • Establishes connections between services by Mutual Authentication • 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

  38. Grid Security Infrastructure (GSI) • Uses an Access Control List called a grid-mapfile for Authorisation • But still can use GGF SAML Callout to other AuthZ functions • Stored in the /etc/grid-security/ directory “/C=UK/O=eScience/OU=Glasgow/L=Compserv/CN=steve kee” skee “/C=UK/O=eScience/OU=Edinburgh/L=NeSC/CN=stewart mills” smills “/C=UK/O=eScience/OU=Glasgow/L=Compserv/CN=iain mcbride” imcbride “/C=UK/O=eScience/OU=Aberdeen/L=GeSC/CN=nikki salter” nsalter “/C=UK/O=eScience/OU=Newcastle/L=NEReSC/CN=nicola wightman” nwightman “/C=UK/O=eScience/OU=London/L=LeSC/CN=scott mccaig” smccaig “/C=UK/O=eScience/OU=Glasgow/L=Compserv/CN=kev mcneil” kmcneil “/C=UK/O=eScience/OU=Glasgow/L=Compserv/CN=nik martin” nmartin “/C=UK/O=eScience/OU=Edinburgh/L=NeSC/CN=ann robertson” aroberts

  39. Federated Trust • Local authentication infrastructures are vital • e.g. Campus student directories • 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 • 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

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

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

  42. Identity Provider Service Provider Application Home Institution Federation Authz WAYF User Grid Portal

  43. Application Home Institution Federation Authz WAYF Point browser to portal User Grid Portal

  44. Identity Provider Service Provider Application Home Institution Federation Authz WAYF Shibboleth redirects user to W.A.Y.F service User Grid Portal

  45. Identity Provider Service Provider Application Home Institution Federation Authz User selects their home institution WAYF User Grid Portal

  46. Identity Provider Service Provider AUTHENTICATE LDAP Home confirms user ID in local LDAP and pushes attributes to the service provider Application Home Institution Federation Authz WAYF User Grid Portal

  47. Identity Provider Service Provider Application Home Institution Federation Authz WAYF Portal logs user in and presents attributes to authorisation function User Grid Portal

  48. Identity Provider Service Provider AUTHORISE Portal passes attributes to AuthZ function to make final access control decision Application Home Institution Federation Authz WAYF User Grid Portal

  49. The Overall Picture? • Shibboleth • Distributed Authentication Mechanism • PERMIS/DIS • Advanced Dynamic Authorisation Infrastructure • VOMS/MyProxy • Grid Credential Repositories • GSI • Globus Toolkit Security Infrastructure • + other projects (GridShib looking very good)

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

More Related