UK e-Infrastructure Security and Access Management Working Group
Date: Friday 1st May 2015
Venue: Brettenham House, 5 Lancaster Place, London, WC2E 7EN
Present:
Stephen Booth (EPCC), Andrew Cormack (Jisc (Chair)), John Chapman (Jisc), Paul Kennedy
(University of Nottingham), David Salmon (Jisc), David Kelsey (STFC), Jens Jensen (STFC),
Darren Hankinson (University of Manchester), Dave Britton (Glasgow), Alan Real (Leeds), Josh
Howlett (Jisc), Steven Newhouse (EBI).
Apologies:
Andy Richards (Oxford e-Research Centre)
1. Actions from previous meeting
1.1. AC to draft e-infrastructure security and access management for non-specialists
document. – Agenda item 6
1.2. AC to draft Policy document - Agenda item 3
1.3. JC to poll for date of next meeting – looking for May 2015 unless it can be scheduled
before the next RCUK meeting – Done
1.4. Find out what overlap there is with H2020 AARC and our work – Agenda item 4
2. Policy white paper review and discussion Authentication
2.1. There are 4 types of stakeholders: those who own the data; those who own the
hardware; those who bring the users; those running the VO.
2.2. Common policy structure means data owners can trust that a user (through their home
organisation/IdP) has agreed to their policies and thus meets their standards
2.3. We want to encourage organisations to cluster around existing groups of policies rather
than reinvent their own.
2.4. EBI has an existing stack of policies that infrastructure providers have to meet - Janet
AUP, Personnel policy, terms of use. It’s not a single document that has to be
implemented - there are a whole stack that users are exposed to. All the policies in all
the stacks must be non-contradictory.
2.5. Making common policies is a good aim, but all have to fit in to existing structures and
policy stacks.
2.6. This paper is a message to data owners to not invent their own, but where possible to
try and reuse existing policies.
2.7. The international grid world applies a user agreement when signing up to a VO: “If you
are a member of my community then you are bound to my rules”. Some may have
expectations rather than clear policies e.g. life sciences communities are less mature in
this area than physics communities – it is s a new thing for them to work across different
infrastructures rather than having bilateral agreements. Need common security policies lacking the concept of a VO to bring this all together.
2.8. The paper is starting from point that a PI was granted permissions from the
einfrastructure and the PI passes these on to users - flow of responsibility. But a VO may
have multiple PIs.
2.9. How do you manage change? If a VO connects to a new source then users of the VO
have already signed policies, but won’t necessarily have signed up to a new policy - need
to add an attribute for those that have signed the new one. EBI's policy says they have
the right to change the policy as things change.
2.10.Policing policies: The usual approach is to ban the user if they do something wrong. If
VO doesn't respond then they will ban the VO. Service is blocking the account for the
user.
2.11.EBI gets users to sign policies every year to reinforce they are there. Could flag up a
warning if they are downloading a data set with different conditions. Great for web
interaction but not for SSH.
2.12.Very common to request access to a data set (or for it to be created). The latter is the
Safe Share model which is a one off, the previous could last for a year or more.
2.13.Paper needs a section on what VOs do. And to say that this merging of policies may take
a while.
2.14.When a PI asks an einfrastructure provider for access to resources there needs to be
guidance on what policies are required e.g. a user policy, terms and conditions, terms for
using the Janet network etc. This paper could define all the possible interactions
2.15.The Grid world naively assumed there could be a global common policy. This failed as
too many managements involved and so politically it didn't work, Now it defines policy
best practice saying you must have a policy that covers certain areas - specify what
should be done, not how it should be done.
2.16.What does the einfrastructure have to have in terms of policies to allow them to trust
each other (at the level of incident data - looking at logs etc.)
2.17.Who is responsible? PI? Are we talking trust or liability? Data controller is responsible
for a data breach. Also need to be aware of the court of public opinion.
2.18.Policies are one control to mitigate risk. Also have to set expectations of those using it.
3. Analysis of H2020 AARC document to identify overlap with our work areas.
3.1. AARC might be the source to achieve some of the recommendations from this group.
This group could feed into AARC and vice versa.
3.2. AARC isn't a development project - one aim is to help document what is there and
point groups at it. - some prototype stuff may be available more timely but unlikely to
see anything operational until the end.
3.3. Slight complication is that there are two streams one funded by GÉANT and one from
AARC - message is to get involved now!
3.4. One of the outputs is case studies describing the combination of tools that you can put
together leading to providers being able to make more effective use of federated
identities. Will also look at expanding to new communities and addressing gaps.
3.5. Levels of assurance and social identities both being looked at. Social identities of interest
for the long tail - unfederated commercial researchers and citizen scientists.
3.6. Of interest as the Home org is a good place to get authN and enforcement. In the future
social identities plus 2 Factor AuthN.
3.7. AARC has a large budget for training - including for open workshops aimed at training
how to set up an SP for federated access.
3.8. The group agreed there is a low risk of duplication between AARC and this group.
4. Discussion on draft recommended activities from the group
4.1. Plan is to discuss here, fill in the gaps then take to PDG for more gap filling, then refine
and take to RCUK for approval.
4.2. Document needs “How soon needed" to be added to each section.
4.3. SAFE software sustainability – meeting arranged to look at requirements (15th May):
what is the need, what is the route to fulfil the needs - are they common needs? If not
then SAFE isn't appropriate. Interested in defining interfaces not software. Is there a
need for different infrastructure to talk to each other?
4.4. People have seen National eInfrastructures using SAFE and quoted it as the answer. But
what is the question you are trying to answer?
4.5. There is a value in coordination tools and automating service requests, but every time
Stephen has worked with different groups the requirements have diverged as they want
things to work slightly differently.
4.6. Question: would a single managed instance of the software run centrally be of any value?
This is what happens for DiRAC, but it won't scale infinitely - works for one group
based in 7 different places. Mandating everyone should use SAFE won't work. Group
management would work if there are interfaces. A centrally hosted service would help
with sustainability. Are differences major or just local preferences? Depends. Mainly on
policies and existing work flow.
4.7. Group management systems and services - We federated identity but not group
information. The Grid world uses x509 attributes. Could just need an opaque blob
containing name of member and name of group. Is a SAML attribute model sufficient?
4.8. There's no obvious beneficiary if everyone is happy working in siloes. - a VO manager
can replicate things manually it just takes time. An advantage would be to have one
interface to let them interact with multiple infrastructures - getting rid of cut and paste.
4.9. Binding across protocols??
4.10.Data sets - want to set access control lists so access to a service is a simple rule to say
give group X access. However, membership of that group is more dynamic. A Protocol
needs to be such that you can query the org that has most up to date list of users.
4.11.Some DiRAC workflows could be used on distributed resources - would be an
interesting project to look at. The Atlas experiment has changed how they do jobs by
scheduling individual events so there may be small CPUs that are free that can be
backfilled with small HPC jobs - has been done in the States.
4.12.If we have a standard structure for policies should there be a centrally hosted repository
for this? Registering terms of use and asserting what it does or doesn't do in a matrix
might be useful. - Look at when Policy doc is complete.
4.13.Recommended we leave list as is until after SAFE meeting and circulate another version.
4.14.GridPP/DiRAC will need a little bit of effort on each side - 0.5fte each. 2 year project?
5. Update on E-infrastructure security and access management for non-specialists paper
5.1. This was envisaged as an overview paper. The National eInfrastructure survey has
mention of 4 papers, one of which sounds similar to this paper so AC will liaise with
Matthew Dovey.
6. Future plans for Working Group
6.1. The term for this group was for 2 years ending this Autumn. There is interest in
continuing.
6.2. Absent any other ideas for more papers what can we do at other meetings? Guest
speakers? Different themes? Compare use cases?
6.3. We should identify a set of pilot projects that we can get recommend to RCUK to fund
and then have meetings based on these projects. Look at the landscape and how to
make use of a national einfrastructure.
6.4. Outcome of the 15th May meeting will also impact this group.
6.5. Can update this group on the safe share project progress.
6.6. Papers from this group should be presented at the next PDG and RCUK meetings.
7. Review and agreement on actions
7.1. Action: Papers should be presented at PDG and RCUK meetings – Jisc
7.2. Action: SB to present back on 15th May meeting
7.3. Action: AC to work on Policy document and coordinate with MD on overview doc.
8. AoB
8.1. Josh has been bouncing idea of concept of small conference/workshop bringing together
practitioners in this area to exchange ideas and presentation. Practical hands-on - how
people are doing group management, for example. Possibly tutorials. STFC has offered
to host at RAL. Focused on research usage of trust infrastructures.
9. Date of Next Meeting: end September. JC to circulate dates on Doodle.