Authentication and Authorisation for Research and Collaboration
Policy and Best Practices Harmonisation
An overview of the “NA3” activities
David Groep
Nikhef
AARC Kick-Off Meeting
June 2015
https://aarc-project.eu
Policy challenges
What does assurance mean? And to whom?
How much differentiation of LoA can people handle?
How can we address incidents that
propagate through the federated space?
Can we get policy coordination to scale?
What is the place of third-party
commercial and eGov providers?
How does that help guest identity?
What’s a sustainable distribution of
responsibilities amongst AAI participants?
https://aarc-project.eu
How can we share necessary accounting?
Objectives
Develop recommendations for best practice in the areas of identity and attribute assurance,
and identify the minimal set of policies and best practices that permits grouping of identity
and attribute providers.
Objectives
• provide a level of assurance (LoA) framework that meets the requirements of resource
providers and can at the same time be supported by institutions (identity providers);
• identify a distributed approach to handling security incidents in a federated environment;
• specify scalable policy negotiation mechanisms between identity providers, attribute
providers and service providers to facilitate resource providers;
• investigate terms of usage for delivering commercial services.
https://aarc-project.eu
3
Supporting and encouraging policy development
Structured to support, leverage, and enhance emerging and nascent activities
• Assurance level development: driven by infrastructure needs and application use cases
DPCoC adoption, eIDAS levels, NIST LoA revision process, IGTF LoA generalisation, VoT, …
• Incident response
support development and adoption of SirTFi, and OpSec trust frameworks
• Service operational models and sustainability (“who might operate which parts of the AAI?”)
leveraging DARIAH developments
• Scalable policy negotiation
SCI Security for Collaboration Infrastructures, REFEDS EntityCategory work
• Accounting and processing of data
developing R&E legal guidance (and comparing that to practices in e.g. STORK), existing
development of e-Infra policies on accounting [but this is a most challenging task]
https://aarc-project.eu
4
Best Practices for LoA
TNA3.1 – Mikael Linden (CSC)
• Gather needs from research infrastructures and communities
• Gather current LoA practice from R&E federations
• Initial milestone coming up to collect at least a minimal level to ’promote’ (M7)
• That level should be useful to relying parties
– but also feasible to provide by authentication and attribute sources!
https://aarc-project.eu
5
Assurance
Assurance:
Implementation
Assurance:
The profile
Communities
AARC
Assurance:
Assurance
The Players
Federations
(IdPs)
REFEDS
eduGAIN
Whole
ecosystem
https://aarc-project.eu
6
Assurance timeline
AARC May 15 – 17
GN4 15 – 17
• Collect Requirements
for assurance
• Define a way to
address assurance
that works for the
user-communities and
for the federations
• Define the service
model that would offer
this type of profile
https://aarc-project.eu
GN4 2016-2017
• Transition from pilot to
production
7
Internal LoA players, how to coordinate?
AARC SA1
Proof of concept
AARC JRA1
Architecture
AARC
NA3T1
Training
AARC NA2
?
GN4p1
SA5T1.4
https://aarc-project.eu
Deliverable DNA3.1 M23:
LoA recommendations
External LoA players, how to collaborate?
NIST 800-63
STORK
Kantara IAF
eIDAS LoA
InCommon
IAP
Low adoption
https://aarc-project.eu
Stable 6/2015,
published 9/2015
IGTF
R&E
R&E
federation
R&E
federation
practices
federation
practices
practices
Currently
fragmented
Incident Response in federated environments
TNA3.2 – Romain Wartel (CERN)
Goals
• Review existing practices
• Propose recommendations for incident response
• Generic security incident response procedure for federations
Input and expected collaboration
• Sirtfi, EGI CSIRT, NRENs, REFEDS, eduGAIN, FIM4R, RDA, etc.
Milestones and Deliverables
• DNA3.2: security incident response procedure for federations (M20)
Draft execution plan
• Identity key partners and contacts
• Gather requirements, operational security standards and practices
• Propose and discuss a practical and reasonably simple procedure
• ‘Consensus is more important than actual content’
https://aarc-project.eu
see e.g. https://wiki.refeds.org/display/GROUPS/SIRTFI
10
Recommendation for service operational models for enabling crossdomain sustainable services
TNA3.3 – Peter Gietz, Martin Haase (DAASI)
●
What Policies are used in today's R&E federations?
–
–
●
Legal aspects, e.g. privacy / personally identifiable information; levels
of assurance
Organizations matters, e.g. server security, currentness of account
data
What Best Practices are recommended in today's R&E
federations?
–
–
–
–
IdP / SP operations: SAML metadata management
Mapping of entity categories and their requirements/policies to
concrete operational processes
Promotion of federated access by campus users to services
What issues does interfederation pose over regular federation (i18n,
attribute release, ...)?
https://aarc-project.eu
Sustainability and Results
●
●
Sustainability
– Policies for homeless user accounts lifecycles
– Policies for translating social network identities into SAML federation
users
– Policies for attribute authorities / gathering user consent
– Operation model
Results
– recommendation for possible operating models for sustainable crossdomain collaboration
– input for the various proof-of-concept implementations in SA1
– Deliverable DNA3.3 - Recommendations for service operational
models for enabling cross-domain sustainable services, M21
https://aarc-project.eu
Development of scalable policy negotiation mechanisms
TNA3.4 – David Kelsey (RAL)
Develop scalable policy negotiation mechanisms between identity providers, attribute providers and service providers
• Note: bi-lateral negotiation between SPs and IDPs/AAs will not work!
Effort funded: 19 PM (CERN, FOM-NIKHEF, GRNET, LIBER, RENATER, STFC)
Input required
• MJRA1.4 – First version of blueprint architecture (M15) this is the one we expect, not the one in the DoW …
Milestones and Deliverables
• DNA3.4 - Recommendations on the grouping of entities and their deployment mechanisms in scalable policy
negotiation (M24)
Draft Execution Plan – for discussion
• The first work will be the identification of the entities that need to be classified and expressed, such as the specific
categorisation that may be needed for non-identity attribute providers and for credential translators (Propose M9)
• proceed to formulate recommendations on the grouping of entities and on the actual deployable mechanisms that
can be evaluated in the proof-of-concepts of SA1 (Propose M12)
• The final recommendations will then be provided to the operational infrastructures and federations. (DNA3.4) (M24)
https://aarc-project.eu
13
Accounting and the processing of data
TNA3.5 – Marcus Hardt (KIT)
• Rationale of the task
• Information from monitoring and accounting (m&a) is personal data
• For users it is not obvious if and under which circumstances his data are stored at a computer center and / or
leave the site and are stored / processed by third parties
• Goals of the task
•
•
•
•
Identify stakeholders (VOs, Sites, Funding Organisations, ...)
Identify acceptable policies for [storage & release & processing] of m&a data
Identify reasonable requirements for the above
Develop a workflow for acceptable (by legal and technical) requirements for processing of data
• Cheap and quick example:
• 1: Aggregate on a VO-level prior to publishing,
• 2: Publish only to parties with reasonable and verified requests
• 3: Maximum storage periods (e.g. right to be forgotten)
• Define scheme to inform users about who will be given which data on which granularity
https://aarc-project.eu
Effort and partners available in NA3
Partners
• CERN, CSC, DAASI, GRNET, KIT, LIBER, Nikhef, RAL, RENATER, SURFsara
• 66 PM available
• with slight emphasis (>10PM) on incident response (“SirTFi”), scalable policies, and LoA
But the only way to validate the proposed best practices (and make them useful) is
• Incorporation in pilots of SA1
• Adoption by REFEDS and operational work in GEANT and at the NREN level
• And: we desparately need the IdPs, SPs, e-Infra’s and communities involved
We can probably reach the federation folk, the e-Infras like EGI and PRACE, and
ESFRI-sized communities – but we rely on training and dissemination to reach the others!
https://aarc-project.eu
15
Time line, pre-set mile stones, and deliverables
Tod
ay
3rd
Quarter
4th
Quarter
M7
1st
Quarter
2nd
Quarter
3rd
Quarter
M18
4th
Quarter
M20
1st M21 M232ndM24
Quarter
Quarter
Start
Finish
01/05/2
015
30/04/
2017
Recommendation on
relevant assurance levels
30/11/2015
Requirements of
data to protect
30/11/2015
Recommend.
processing of
personal data
31/10/2016
Best practices
collective SIR
31/12/2016
Recommend.
Recommend.
LoA
service
recommen on grouping
operational
of entities
dations
models
30/04/2017
31/03/2017
31/01/2017
Two early milestones
• On a relevant minimum assurance level to promote – in particular for use in any SA1 pilots
• Collection of the types of data (attributes, accounting records, log data, over-the-wire
monitoring, &c) and the participants (AAI IdPs, individual SPs, e-Infrastructures,
communities, other roles) that need to be addressed by the recommendations
We expect a more continuous stream of actual output: both recommendations and actual use
but will rely on both the SA1 pilots and ‘external’ entities (REFEDS, e-Infrastructures, GEANT4)
to work with the NA3 policy recommendations and best practices!
https://aarc-project.eu
16
Thank you
Any Questions?
davidg@nikhef.nl
https://aarc-project.eu
© GÉANT on behalf of the AARC project.
The work leading to these results has received funding from the European Union’s Horizon 2020 research and innovation programme under Grant Agreement No. 653965 (AARC).
https://aarc-project.eu