1. Usable Security for Science Challenges and Next Steps Jens Jensen Science and Technology Facilities Council Trust and Security 2 nd Workshop Oxford 8-9 May 2008

2. This Talk… Is about security – practical security Mainly from the service provider’s view Broader view rather than narrow tech Mostly about AAA in line with workshop’s theme Tried to be provocative now and then

3. Large scale science facilities with users across the world All Images © STFC

4. all areas of science Biology and medicine Space Earth Materials Physics Arts and humanities Environment and energy … Technology Chemistry

5. Why Security? Protect our infrastructure (and users’ data)‏ Enforce allocations Accounting for resource use Track resource misuse Peering – across UK, Europe, World

6. Practical Aspects Most technology is experimental Standard Java Library Implementation C/C++ Library Implementation … third implementation

7. Practical Aspects A spec alone is useless...(without implementations)‏ Java (alone) is useless C can be linked into everything (almost)‏ –Perl, python, … Need >2 independent implementations –Interoperating !! Usable licence

8. Practical Aspects Standards are very important Sometimes there are too many

9. Practical Aspects like traffic (sort of)‏ Technology, Grids, it’s experimental Never ever just trust the standard

10. What we have for AuC Site security – physical (people, doors, access cards, keys)‏ Site computing – Active Directory e-Science CA (IGTF/X.509)‏ Shibboleth Credential conversion (later in talk)‏

11. Whose Developer Service provider Sysadmin Supporter Accounting Facility provider User office Granting body PI End user

12. Dimensions Time (user’s)‏ Time (ours)‏ Space (geo)‏ Financial/resources Ease of use Assurance Trust End to end (user to system)‏

13. Interest in proposal Registration Authorisation Users’ timeline Science! Termination (or not?)‏ Weak AUC Stronger AUC STATE of AUC?

14. Organisation Timeline Preserving data, curation Technology migration Lower costs…

15. User OfficesHR Integrated Account Management STAFF VISITOR AGENCY STAFF External Diamond? Other STFC sites PPARC/CCLRC xyz12345@fed.cclrc.ac.uk joe.user@stfc.ac.uk

16. Usability for users Should be like a duck Who moves across the pond Paddling of feet unseen

17. Usability for service provider Let the good guys in Keep the bad guys out Minimal support requirements

18. How we achieve (some of) it Credential Conversion Scientist wishes to do work Logs in Uses resource

19. Account mgmt and AuZ Site single sign on databases (connected)‏ fedId, DN, resource username Granting access to resources (AuZ)‏ Single account management –Also holds customers – e.g. beamline scientists Adding more resources

20. Example Resource SCARF cluster External users use certificates All staff have a default SSO account –Temporary limited recyclable accounts Staff can apply for permanent acct License management for all users –Commercial libraries

21. MyProxy for CC http://grid.ncsa.uiuc.edu/myproxy/ Grids (NGS, gLite/GridPP, SRB)‏ Kerberos or Active Directory Users do not see the certificate – it's all managed behind the scenes (duck paddling)‏

22. Applications integrated security We adapt science applications to use the Grid End to end Interfaces to security infrastructure Often security is added only as necessary? –Imposed by Grid infrastructure

23. Shib for CC PasswordShibboleth Resource access

24. NGS Deploy production services for Grids SARoNGS – Jan 07 – Jan 08 for NGS –Integrate ShibGrid and SHEBANGS –Shibboleth access with VO attrs from VOMS

25. NGS e-Science CA: accepted internationally High assurance level Works because everybody in the world is on the same level Robots for automated services (or portals)‏ Not necessarily needed for normal users?

26. Why does it work? Interoperable Standards based Tested!

27. Er, what was the question again? How important is usability for my users? Very More for some than for others –Health workers seem to have particular difficulties –Physicists are more hardy folk

28. …Usability? Security… …a necessary evil?

29. Experiences Usable security …satisfying user and site requirements… …makes happy(er) and productive users

30. …And the second question? Usability and interoperability? Interoperability improves reusability Reusable means more versatile Improves usability

31. …And the final question? What we learn from other communities? Pick usable components for reuse Build on experiences Deploy services for other communities –Try to adapt what they already have

32. Don’t reinvent the But did they want this? or this?

33. Final words (promise)‏ Aim to meet user and site requirements Build on stuff that works (or build stuff that works…)‏ Users don’t always know what they want Don’t forget, it’s an experimental science – across all dimensions