1 / 22

DyVOSE Project: Experiences in Applying Advanced Authorisation Infrastructures

DyVOSE Project: Experiences in Applying Advanced Authorisation Infrastructures. John Watt ( j.watt@nesc.gla.ac.uk ) Richard Sinnott ( r.sinnott@nesc.gla.ac.uk ) University of Glasgow, Scotland, UK. Dynamic Virtual Organisations in e-Science Education.

holmes-vang
Download Presentation

DyVOSE Project: Experiences in Applying Advanced Authorisation Infrastructures

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. DyVOSE Project: Experiences in Applying Advanced Authorisation Infrastructures John Watt ( j.watt@nesc.gla.ac.uk ) Richard Sinnott ( r.sinnott@nesc.gla.ac.uk ) University of Glasgow, Scotland, UK

  2. Dynamic Virtual Organisations in e-Science Education http://www.nesc.ac.uk/hub/projects/dyvose “Investigating the establishment of scalable Virtual Organisations in an e-Science education domain.” 2 year JISC-funded project (May ’04 – July ’06) In partnership with University of Kent (and EDINA)

  3. Project Goals (Glasgow) • Creation of a permanent Grid Computing Module (GC5) as an option within the Advanced MSc. postgraduate course in Glasgow’s Computing Science department • Provide a lasting lab infrastructure to support practical Grid Computing lab sessions • Investigate technologies that enable Grid Services to be protected with advanced authorisation infrastructures which the students can deploy as part of an assignment

  4. Course Details • Single term course of 20 lectures and 10 tutorials (Jan-Mar) • 1st year (’04-’05) – 19 students • 2nd year (’05-’06) – 16 students • Three short essay/programming assessments • Final Exam in June (answer 3 questions of 5) • Month-long Programming Assignment • This assignment forms the core of the DyVOSE authorisation investigations

  5. Assignment • In both years the assignment took the following form: • Students are split into two teams • Write a Grid Service (and a client) in GT3.3 to perform some task • Write a scheduler that will split a large job into many sub-jobs and submit to the local Condor pool • Protect the Grid Service so that some functions are only available to students who are in the same team • For both years, students used PERMIS to protect their Grid Services…

  6. Assignment • Year 1 • Investigate STATIC privilege management • Roles are issued by a local Source of Authority (SoA) stored in a local LDAP for access to a local service only • Year 2 • Investigate DYNAMIC privilege management • Roles are issued by a local SoA stored in a local LDAP for accessing local AND REMOTE services • But roles required for access to the REMOTE service are not recognised within the local infrastructure • REMOTE SoA DELEGATES the right to assign these REMOTE roles to the LOCAL SoA (they form a VO!) • Will prove that this can be done SECURELY and EASILY (from a user perspective) with PERMIS…

  7. Generic Java API for Role Based Access Control (RBAC) • Provides method-level protection to applications and Web Services • Protects Grid Services through GGF-standardised SAML Authz API • Roles are issue in the form of X509 Attribute Certificates (ACs) http://sec.cs.kent.ac.uk/permis http://www.permis.org

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

  9. PERMIS with GGF Authz API • PERMIS deployed in Grid Service container • WSDD file contains policy location, LDAP server details and trust info • GSI provides user DN, PERMIS retrieves ACs

  10. PERMIS Components • XML Policy • Roles • and heirarchy • Targets • Actions • SOAs • DN Scope • Attribute Storelist • LDAPs • Policy Editor tool • syntax checks

  11. PERMIS Components • Privilege Allocator or Attribute Certificate Manager (ACM) • Creates and signs X509 Attribute Certificates (ACs) and loads into LDAP • ACs contain digitally signed attributes (roles) • PERMIS API verifies PKI chain of trust (if more than unity length) on invocation • Fully supports a static PMI • One SoA, home roles only…

  12. Year 1 Assignment • “Write a Grid service (and client) to parse the Complete Works of Shakespeare and offer a “Search” service to everyone, but a “Sort” service only to members of the same team. Split the job into sub-jobs and submit to the Condor pool.” • Support (as Sys Admins) • Create PKI (CA) and p12 certificates for Globus • Write a local XML policy to enforce the rules • Create LDAP entries and use the ACM to issue ACs to the students which contain their role • Students were given LDAP and PKI info to amend their PERMIS service • A tough assignment for four weeks. We got 2 completions and about 5 or 6 who were about 90% there. • We have since Shibboleth-enabled this service, check URL at end…

  13. Year 2 Assignment • “Write a Grid Service and client which runs BLAST on a set of data extracted from a remote database and schedule into sub-jobs for submission to the Condor pool” • Student experience much the same as before implementation-wise (deploy PERMIS in container – point to our PMI details) • But the Support part requires a more sophisticated AC allocator application to handle external as well as local roles (among other properties) • Enter the Delegation Issuing Service (DIS)… • (and a slightly modified PERMIS too)

  14. Delegation Issuing Service • No user key pair required to issue ACs • ‘dis’ user signs all ACs on behalf of the delegator • If a rogue employee is kicked out, any certificates they issued to trustworthy employees are still valid • Not the case with AC chains • DIS checks the local policy before signing • Only policy-valid ACs can ever be issued • With previous PERMIS tools it is possible to issue ANY AC with ANY role • Deployed as a web service utilising SOAP • Can be used anywhere by valid users

  15. Delegation Issuing Service • Extensions to the PERMIS API allow for • Cross-certification • Allow ACs signed by a remote CA to be recognised • Currently done through an SoA policy extension • Role-mapping • Recognise the meaning of an external role • Currently done by equating the names of the roles in the local policies • Future tools will do this equality on the fly without having to alter local core policy • The above implement the necessary features to allow Glasgow to issue Edinburgh roles within their PMI and in accordance with both sites policies

  16. DIS Implementation • Web Service • AXIS, Apache, Tomcat • Not too tricky • An afternoon • Docs fine for this part • Underlying PKI • OpenSSL • Quite complex • Had to be quite careful with compatibility of VO PKIs • Have written extension to manual detailing the steps required in full

  17. Dynamic PMI Use Case • Student Assignment • Student were split into two teams • They were issued with Attribute Certificates which assigned them with one of two roles (GlaTeamN and GlaTeamP) • Students implemented a BLAST Grid Service which queried an external database (hosted in Edinburgh) for gene data • Database was PERMIS protected so only members of the correct team got the right data (based on EdTeam roles) • Students PERMIS protected their service so only members of their own team could invoke the service

  18. Dynamic PMI Use Case PERMIS Policy Details • BLAST DATA Service (Edinburgh) • Send Nucleotide Data if User presents PERMIS Role “EdTeamN” • Send Protein Data if User presents PERMIS Role “EdTeamP” • BLAST Service (Glasgow) • Invoke BLASTN service if User presents PERMIS Role “GlaTeamN” • Invoke BLASTP service if User presents PERMIS Role “GlaTeamP”

  19. Dynamic PMI Use Case • Dynamic Delegation • Edinburgh issues a Delegation Statement to the Glasgow SoA that allows them to assign the EDINBURGH PERMIS role ‘EdTeamN/P’ • Done through Glasgow policy extension (RoleMapping) • Glasgow SoA delegates the responsibility to issue this role to user ‘ext’ • Issues ‘ext’ an Attribute Certificate containing the Edinburgh roles with the delegation flag set • User ‘ext’ assigns the Edinburgh roles to Glasgow students • By issuing the Glasgow students Attribute Certificates • This user can be in the Glasgow infrastructure or can be the Edinburgh SoA (by logging into the Glasgow DIS) – both models can be supported (the former being the more direct) • Edinburgh Data Service searches both LDAP directories • Service finds User entries in Glasgow LDAP that contain the correct Edinburgh role – ACCESS GRANTED

  20. Dynamic PMI Use Case Edinburgh “You may assign Edinburgh Roles” Glasgow CONDOR LDAP LDAP P P Student PERMIS Service BLAST Client BLAST DATA BLAST SERVICE PERMIS Service GT3.3 Container GT3.3 Container

  21. In Practise

  22. Summary • PERMIS simple to deploy for users • For sys admins, deployment is tricky, but use is easy • Dynamic Delegation of Authority can be secure and workable • Future tools (next year?) will optimise this process • User need not know of certificates! • Happier users • DyVOSE legacy • Third year of Grid module starting in Jan ’07 • Permanent Grid Computing Laboratory in NeSC Glasgow • A set of tools which we are able to apply to many of our security projects now and in the future • Fancy doing the course next year? • http://www.dcs.gla.ac.uk/courses/MSc_ACS/

More Related