Federated Identity Management for HEP David Kelsey HEPi

Federated Identity Management for HEP David Kelsey HEPi. X, Ann Arbor MI 30 Oct 2013

Overview • What is federated Id. M? • A review of some Id. M topics – Since April 2012 HEPi. X (Prague) • • FIM 4 R, REFEDs and VAMP meetings WLCG activities Levels of Assurance - IGTF IOTA Next steps 30 Oct 13 HEPi. X Id. M, Kelsey 2

Id. P Many different permutations depending on the technology 30 Oct 13 SP User HEPi. X Id. M, Kelsey Id. P: Identity Provider SP: Service Provider 3

Id. P Then add a community operated attribute authority (for Auth. Z), e. g. VOMS 30 Oct 13 SP User HEPi. X Id. M, Kelsey AA 4

Talk at CHEP 2013 • “Horizon 2020: an EU perspective on data and computing infrastructures for research” – Plenary talk by Dr. Kostas GLINOS (European Commission) • He suggested they are working towards a vision of an integrated e-Infrastructure with all researchers accessing via a federated digital identifier 30 Oct 13 HEPi. X Id. M, Kelsey 5

Helsinki (CSC) Id. M meetings • 30 Sep 13 – VAMP (VO Architecture and Middleware Planning) – http: //www. terena. org/activities/vamp/ws 2/ • 1 -2 Oct 13 – Joint FIM 4 R & REFEDs – https: //refeds. org/meetings/oct 13/index. htm l 30 Oct 13 HEPi. X Id. M, Kelsey 6

Introduction – FIM 4 R • Federated Identity Management for Research Collaborations • An activity (EIROforum) that started 2 years ago in Europe – To explore and document a joint vision and our common requirements for FIM – And describe issues that make progress difficult • Includes: Climate Science, Earth Sciences, ESA, High Energy Physics, Social Sciences & Humanities, Life Sciences, Neutron & Photon Facilities, We. NMR – And open to any others who wish to join 19 Jun 13 FIM 4 R, Kelsey 7

Workshops and Paper • 6 workshops to date – link to Mar 2013 agenda (and links therein) http: //indico. psi. ch/conference. Display. py? conf. Id=2230 • April 2012: We prepared a paper that documents use cases, common requirements, a common vision and recommendations • Paper: CERN-OPEN-2012 -006: https: //cdsweb. cern. ch/record/1442597 19 Jun 13 FIM 4 R, Kelsey 8

Common vision statement A common policy and trust framework for Identity Management based on existing structures and federations either presently in use by or available to the communities. This framework must provide researchers with unique electronic identities authenticated in multiple administrative domains and across national boundaries that can be used together with community defined attributes to authorize access to digital resources 19 Jun 13 FIM 4 R, Kelsey 9

Pilot Projects 19 Jun 13 FIM 4 R, Kelsey 10

Roadmap for collaboration ² REFEDS/edu. GAIN produced a document to address FIM 4 R issues: Ø Provides an initial list of prioritised requirements (thanks also to Bob Jones & co. ) Ø Addresses some perceived issues Ø Presents proposals to solve some of the challenges https: //refeds. terena. org/images/3/3 e/Analysis. FIMDocumentv 0. 7. pdf

Identity Management for Research Collaborations: from Pilots to Production Bob Jones IT dept CERN

CERN ILL E. XFEL EFDA EMBL EIROforum ESRF ESA ESO Bob Jones (CERN) – October 2013 CERN EFDA EMBL ESA ESO ESRF European XFEL ILL

A Vision for a European e‐Infrastructure for the 21 st Century Sustainable - RIs currently in construction (FAIR, XFEL, ELIXIR, EPOS, ESS, SKA, ITER and upgrades to ILL and ESRF etc. ), need to be convinced that e-Infrastructure will exist and continue to evolve throughout their construction and operation phases if they are to take the risk and invest in its creation & exploitation Inclusive - Need an e-Infrastructure that supports the needs of the whole European research community, including the “long tail of science”, and interoperate with other regions Flexible - Cannot be a one-size-fits-all solution Integrated - Coherent set of services and tools must be available to met the specific needs of each community Innovative - Essential that European industry engage with the scientific community in building and providing such services User driven - The user community should have a strong voice in the governance of the e. Infrastructure See https: //cds. cern. ch/record/1550136/files/CERN-OPEN-2013 -018. pdf CERN EFDA EMBL ESA ESO ESRF European XFEL ILL

Prototype Centres of Excellence – Example from CERN • This Centre of Excellence will focus on data-centric services representing a platform on which more sophisticated services can be developed • Use the resources installed by CERN at the Wigner Research Centre for Physics in Budapest, Hungary • Services will be accessible via single sign-on through a fed id. mgmt system – Multi-tenant compute environment to provision/manage networks of VMs ondemand – ‘dropbox’ style service for secure file sharing over the internet – Point-to-point reliable, automated file transfer service for bulk data transfers – Open access repository for publications and supporting data allowing users to create and control their own digital libraries (see www. zenodo. org) – Long-term archiving service – Integrated Digital Conferencing tools allowing users to manage their conferences, workshops and meetings – Online training material for the services CERN EFDA EMBL ESA ESO ESRF European XFEL ILL

Sustainability of CERN’s Centre of Excellence - role of partners • Partners will – curate their data-sets – connect their identity federations – deploy their community specific services & portals – manage the interaction with their registered users and associated support activities • Beyond this first year, partners engage to fund the cost of the services their users consume according to a pay-per-usage model (to be jointly-developed with CERN during the first year) CERN EFDA EMBL ESA ESO ESRF European XFEL ILL

How can we create e-infrastructures that overcome fragmentation? • Fragmentation of users (big science vs. long tail) • Fragmentation of infrastructure (not integrated services) • Common platform (e-infrastructure commons) with 3 integrated areas – International network, authorization & authentication, persistent digital identifiers – small number of facilities to provide cloud and data services of general and widespread usage – Software services and tools to provide value-added abilities to the research communities, in a managed repository • Need a data continuum - linking the different stages of the data lifecycle, from raw data to publication, and compute services to process this data CERN EFDA EMBL ESA ESO ESRF European XFEL ILL

WLCG Group Identity Federation - HEP/WLCG FIM 4 R Meeting, Helsinki, Finland, 2 -3 October 2013, D. Kelsey, R. Wartel 18

Use cases • Use cases in WLCG are: – Web-based (grid portals used for job submission, wikis, etc. ) – CLI-based (job submission, admin tasks) • Use cases foreseen by the experiments for federated identities – Alice: Interested - but would rather the work to focus in priority on the Web use case – Atlas: Interested in both CLI and Web use case – CMS: No immediate adoption foreseen, but supportive of both CLI + Web use cases – LHCb: Interested - in particular in a CLI 19

Technical work • Conduct no further work on an ECP-based CLI pilot for now – Pilot works, but ECP will not be available for some time, making deployment difficult – Investigate alternative solutions for a CLI (supported by CILogon) • Focus on the Web use case – Understand what WLCG users (LHC experiments) need exactly – Determine how the pilot should interface with existing services • Very little progress since the last meeting – Support can be provided by the WLCG working group – But experiments will have to do the integration work – Not perceived as an important priority in the short term 20

Operational considerations • Identity federation brings more than implementation issues – Affects security incident handling and security operations • In the current model – Service providers implement user banning & conduct forensics – Id. Ps (e. g. certificate authority) perform (almost) no operational role • In a federated realm – Id. Ps implement emergency suspension and also collect essential traceability information – Id. Ps will therefore have to provide operational capabilities and actively participate in incident response • Providing operational capability is a significant change – Requires careful planning to ensure sufficient logging, expertise, communication channels, etc. are in place 21

Attributes • HEP/WLCG has used user attributes for many years: – Full name + email address • Base attributes verified with high Lo. A (passport verification) • Additional attributes are aggregated later – VO membership and role • In the future, the same attributes will likely be used – Lo. A may (have to) vary however – These issues are actively discussed within the IGTF (http: //www. igtf. net/) • HEP/WLCG needs few and simple attributes – But they need to be fully harmonised across administrative domains 22

IOTA Authentication Profile Towards Differentiated Identity Assurance David Groep, Nikhef supported by the Netherlands e-Infrastructure and SURFsara

Identifier-only Trust Assurance profile · Cater for those use cases where · the RPs (VOs) already collect identity data · this RP (VO) data is authoritative and provides traceability · the ‘identity’ component of the credential is not used · through an AP where the authority provides only · · persistent, non-reused identifiers traceability only at time of issuance naming be real or pseudonymous (discussion on going!) good security for issuance processes and systems · and where the RP will have to take care of · subscribers changing name often (in case traceability at issuing authority is lost) · all ‘named’ identity vetting, naming and contact details David Groep – davidg@eugridpma. org EUGrid. PMA Kyiv 2013 meeting – 24

IOTA Questions for RPs Sept 9, 2013 Bucharest, Romania David Groep & David Kelsey

Basic Premises · Subject names must be globally unique · Subject names must be persistent (for the life time of the authority) · It’s about people and robots · Naming of IOTA subjects must be different from other profiles David Groep – davidg@eugridpma. org 28 th EUGrid. PMA Kyiv – May 2013 - 26

IOTA Questions for Relying Parties (RP) Do the RPs need the ‘real name’ of the person the certificate subject? · Is it enough to be able to ask another entity to give you the name (e. g. the VO, community, other site or central LDAP)? What assurance level do you expect from this 3 rd party? · Do you need this information up-front (before or at use time)? · Do you need this information at end (e. g. for accounting)? · or It is sufficient to be able to ask an entity to contact the user on your behalf (like a privacy service)? · Should pseudonyms be clearly identifiable (e. g. if they look like a name they should be the real name)? · The email use case will not work: since email. Address must be embedded in the SAN, but the mail will be pseudonymous as well David Groep – davidg@eugridpma. org 28 th EUGrid. PMA Kyiv – May 2013 - 27

IOTA Authentication Profile · Vetting assurance level and responsibility · Given that the name may be a pseudonym and is weakly verified, do you (RP, community) have the mechanisms in place to strongly identify the real user? · Should we enforce obfuscated naming for all subjects? · How will you (RP, VO) deal with ‘identity spoofing’? · How do you currently enrol users in the community? Do you use or rely on the common. Name of the subject for adding people to your databases (or get a ‘warm fuzzy’ feeling in association with e. g. unsigned email)? · Tracability by the VO · Are you set up to provide traceability for your users? · Do you have means and procedures for incident response and mitigation? David Groep – davidg@eugridpma. org 28 th EUGrid. PMA Kyiv – May 2013 - 28

Auditability, traceability · Access to the user information by RPs Do you insist that the collection of this data is verifiable? Should the chain of processes be documented? Should the chain of processes be audited periodically (expensive!)? Should the chain be auditable? Or contract/sanction-based? A user may and will have many credentials and changing names: does this pose issues? · Do you expect e. g. the community to provide a real name up-front with every access request (e. g. in a VOMS generic attribute)? · · · Do the RPs need to be able to independently trace the user without involving the user community? · Can a registration mechanism, retrievable or callable by the RP, satisfy this requirement (e. g. like the EGEE CIC portal having an ability to send email to the owner of a DN) · Do the RPs need to be able to trace without involving the CA? · Which are the ‘emergency cases’ where they expect CA involvement in tracing or contacting subscribers? David Groep – davidg@eugridpma. org 28 th EUGrid. PMA Kyiv – May 2013 - 29

Incident response · Do RPs expect the CA to be involved in incident response? What is an incident where you expect CA involvement? What is the level of involvement? Do you see a classification of incidents? If there are up-stream Id. Ps, are you ‘happy’ with just the CA response even if upstream does not participate? · Do you expect more than pure credential revocation in case of demonstrable credential compromise? · Do you see the CA more than a fall back to point to in case LEA comes after you? · Do you expect/prefer suspension possibilities? Do you have this capability at the RP level (through authorization)? · · · Can you get by with just your own response capability? David Groep – davidg@eugridpma. org 28 th EUGrid. PMA Kyiv – May 2013 - 30

Next steps • IGTF discussions (next week) – What is their role in relation to FIM 4 R/REFEDS? • Defining best practice for Attribute Authorities, Id. Ps? • Can IGTF members provide Id. P services for Research • Discussions with others re Horizon 2020 – EGI, TERENA, REFEDs, … – Should we create a Federation of Research Communities? • To join edu. GAIN as a single federation • FIM 4 R likely to propose an Interest Group to RDA – Next meeting of FIM 4 R in April 2014 • How should HEP, CERN, WLCG, … “federate”? 30 Oct 13 HEPi. X Id. M, Kelsey 31

Questions? 30 Oct 13 HEPi. X Id. M, Kelsey 32