Sharing Data and Protecting Data

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?