Sharing Data and Protecting Data Adam Carter with contribu2ons from Jens Jensen and Peter Gietz Sharing versus Protecting • Security can help you to share – with those you would like to share with – knowing that others cannot see your data • Allow different people to do different things: – read / modify – all data / selected parts of data • Visibility of data should possibly vary over time: – At first, only you get to see/use it – Then, your collaborators get to see/use it – Then, the world gets to see/use it AAI • An AAI (such as that which EUDAT plans to provide) can help with sharing and protecting – We aim to do provide a distributed AAI – We aim to make use of existing infrastructures to make things easier for end users • AAI = Authentication and Authorisation Infrastructure Who Am I? What am I allowed to do? This Talk • Ways of doing distributed AAI • What you will see as a user of such an infrastructure • Some terminology • A little bit about what EUDAT is doing in this area, and the approaches it will adopt The Players in the game • Institutions – Research institutes, higher education, etc. – “Home organisations” that know the user and often create a user account for email and more (they are the Identity Provider) – Not everyone has an institution • Service Providers – Could be the above mentioned institutions – Can be computing centers or data centres – Can be content provider (Publishing companies) – Or any other company providing services to researchers (software licenses, etc.) The Players in the game • External Identity Providers, e.g., – National Research & Education Network (NREN) as Public Key Infrastructure provider – Commercial Certification Authorities – OpenID, Google, Yahoo, Microsoft, Facebook, ... – The government issuing ID cards with online auth – Different Levels of Assurance – Persistence of ID • allows moving institute • reputations can be built over the long term The Players in the game • Federation Managers – NRENs that have contracts with: • Identity Providers who say “our data are correct and current” • Service Providers who say: “we will do no evil with the personal data provided” The Players in the game You First, there was the Grid… • Grid computing has coined the term Virtual Organization – Foster, et al.: The Anatomy of the Grid - Enabling Scalable Virtual Organizations, 2001 The sharing that we are concerned with is not primarily file exchange but rather direct access to computers, so9ware, data, and other resources, as is required by a range of collabora<ve problem-‐solving and resourcebrokering strategies emerging in industry, science, and engineering. This sharing is, necessarily, highly controlled, with resource providers and consumers defining clearly and carefully just what is shared, who is allowed to share, and the condi<ons under which sharing occurs. A set of individuals and/or ins<tu<ons defined by such sharing rules form what we call a virtual organiza<on (VO) The trouble with the Grid… • …was that it was too hard to use. CERTIFICATES! • Having said that, it did a lot of things right • We should learn the lessons of Grid AAI and make use of that which is useful • Users can use certificates with the right tools – EUDAT will probably not require that you use certificates • Certificates can be (and are very likely to be) used behind the scenes… Virtual Organisations • VOs are – Research communities that want to collaborate – dynamic, members change even more often than in real organisations – multiorganisational, researchers from different organisations work together – multinational, these organisations are spread all over the world • Challenges: – Organisational issues, membership control – Different legal situations (privacy, copyright, etc.) • Some communities are already managing identities • Roles and rights rest with the community I don’t want to know about the AAI! Just let me share my data! Just keep my data secure! How might you interact with an AAI? • Registering • Logging In • Assigning access rights to data • Requesting rights to access data Registering • What if you didn’t have to? • You have already registered with your own institution • You may still need to register this with EUDAT but this would be lightweight because you already have an identifier • You might need to register with a service provider to gain authorisation but authentication would probably be done in the usual way Logging In = Authenticating • …or almost the usual way – You will use similar techniques, but use a single identity • Web Applications / Portals – Single Sign On: (Home) Username and Password – (Certificate) • Command Line – Username and Password • Client Applications – Uses web-based authentication behind the scenes, or – Certificate Ways of doing distributed AAI • Centralised (i.e. not really distributed at all…) – Simplest to implement from a technical point of view, but never going to happen! • A national supercomputing service, say, is very unlikely to give up control of its AA to a third party • Trust Hierarchy • Trust Federations Trust Hierarchy • • Certification Authorities (CA) prove and certify identity, signing such assertions with digital signature There are hierarchies of such CAs, which trust eachother because they follow policies – • • • • CAs are audited So, if you trust the top (policy) CA, you trust the hierarchy and you can trust every certificate The user owns and has to care about the security of the certificate The resource provider evaluates and trusts the certificate This is a Public Key Infrastructure (PKI), because of the asymmertic encryption technology for digital signatures (X.509, which is e.g. used in HTTPS) Trust Federations • Identity Provider (IdP) proves and certifies identity, signing such assertions with digital signature – • • • • • same PKI mechanism as hierarchy The Service Provider evaluates and trusts the assertions There is a Federation of IdPs and SPs which trust eachother, because they have signed contracts confirming policies So if you are a member of the federation you trust every assertion made within the federation The IdP owns (and has to care about the security of) the assertion This is called Federated Identity Management (FIM) Work is underway... • EUDAT doesn’t have all the answers to this yet, but work is already underway – A prototype is running at FZJ • Integration workshop in November – Plan to integrate the prototype with (existing) community portals • Working with CLARIN and ENES initially – They use two different techs: • Shibboleth and OpenID Source: Johannes Reetz Some AAI tools & technologies considered by EUDAT Kerberos 5 simpleSAMLphp OpenID Shibboleth Federated Authentication Active Directory eduGAIN IdP AtP v VOMS LDAP Ongoing work • • • • EUDAT Investigating re-using a federation framework developed by Contrail project Pilot service running at FZJ, will be used for community portal integration in Nov Contrail framework uses OpenID+Shibboleth login, internally uses X.509+SAML+OAuth2 CLARIN also have experience with OAuth2 Distributed AAI is challenging, but we’re working on it, and it should allow you to do more with your data. Our aim is to make it straightforward for the end-user You should be thinking about who you want to see and work with your data, and who you want to be able to use and share services your community provides You should be able to use the same identity for different EUDAT services and your own community services Final Thoughts • • Users should possibly concentrate on thinking about the who question (rather than the where) It's about more than identifying yourself – • It's also about linking up permissions so that the infrastructure can work on your behalf EUDAT's goal is to work with (and possibly extend) what you are used to, rather than replace it Ques2ons for Jens • Any idea whether EUDAT will go down PKI or FIM path, or both? • Any idea which technologies have been considered / proposed / adopted for AAI?
© Copyright 2024