Implementing Community Security Policies for Trustworthy e/cyberinfrastructure Jens Jensen, STFC (UK) Paolo Mori, CNR (IT) Stephan Kindermann, DKRZ (DE) Mark van de Sanden, SurfSARA (NL) International Symposium on Grids and Clouds (ISGC) 2014, Academia Sinica, Taipei, March 2014

Contents Background – the problem, the projects What are policies? AAI deployment Requirements Implementation

BACKGROUND The problem, the projects

Background – The Problem e/cyber infrastructures are providing services Mostly federation rules are quite simple –D Kelsey et al – WLCG federation rules –WLCG has a simple VO structure (see later) However, user communities will diversify –And complexificate –And future developments may also have an effect

Background – The Relevance e-/cyber-infrastructures support diverse communities Scale – more users, more data, complexity Make use of standards – tools, implementations, protocols Stds 1+1i Users

Background – the Projects Federated access to clouds: ConSec: framework for AAI Data e-Infrastructure

7 Data StagingSafe ReplicationSimple Store AAIMetadata Catalogue Dynamic replication to HPC workspace for processing Data curation and access optimization Various flavors Researcher data store (simple upload, share and access) Aggregated EUDAT metadata domain. Data inventory Network of trust among authentication and authorization actors PID Identity Integrity Authenticity Locations EUDAT Box dropbox -like service easy sharing local synching Semantic Anno checking & referencing services to come Dynamic Data immediate handling Workflow Engine executing WFs EUDAT Services

Simple but works – WLCG WLCGVOSiteSecurity

WLCG WLCG is (kind of) a federation of T0, T1, T2, T3 –1 T0, ~11 T1, ~100 T2s, Four original WLCG VOs (ATLAS, CMS, LHCb, ALICE) Additional VOs: global, international, national, site VOs provide scalability: –Accepting WLCG AUP –Defining scope of VO’s work –Managing membership and user authorisation –Authorisation is pretty coarse grained: user, production –Using VOMS (RFC3281 AC)

More complex: Dramatis Personae FederationCommunity Sub- community MemberSiteSite adminSite opsec“Fed stuff”

Next steps in federated authorisation? How can we express policy in practice, and which policy requirements can we identify – and satisfy with the technology available to us today? Case studies: ENES (climate), CLARIN (linguistics) in EUDAT

POLICIES

Policies (in general) –Identity attributes –Authorisation attributes doing to –identifier, class-of-object in –Time, location, status

We divide policies into two main classes: * Authorisations: express the actions that a subject is allowed to perform on an object within an environment. * Prohibitions: express actions that a subject is not allowed to perform on an object within an environment. (use with caution...)

Usage Control Normal access control: “pre” (before action) Ongoing control: “on” (after successful initial decision)

DEPLOYMENT

Technology Review Protocols and Standards X.509 – federation-internal credentials (SSL/TLS) XACML SAML OAuth (RFC6749) – delegation of credentials

From xacml-3.0-core-spec-os-en: Copyright © OASIS Open All Rights Reserved. The XACML model

Important: separation of duties in ConSec

REQUIREMENTS Community policies

ENES Data centres: local data ingest Actions: –Access, Ingest, Publish, Modification/Version User and API access (OGC WPS?)

CLARIN – The Language Archive (TLA) Trusted repository Users can upload and share language data NREN (Shib) feds for identity and attributes Authorisation is local (currently.htaccess), generally individually {user}x{file}  {true, false} Virtualises the logical name space and physical name, identifies objects via Persistent Identifiers

EUDAT itself Different authentication methods (e.g. OpenID, OAuth, X.509, Shib, …) Support fine grained access control – VO and Role approach does not (always) work A minimum set of semantically standardised attributes for user identification and access control (future: CoC) Communities retain control on authorisation decisions Attributes provided by IdP, ConSec, or (todo) AtP Support different Access Methods (e.g. HTTP, GridFTP, Web Portals, Workflows) Bridge to other infrastructures – PRACE, EGI, …

EUDAT itself Authorisation policies Language sufficiently expressive Tools to make it possible to express Sufficient performance in evaluations Resilience possible (against SPoF, attacks) Need much of XACML3.0 supported Also certain optional, er, options (note also support for UCON as extension)

IMPLEMENTATION Community policies

Very simple policies …? (Communities) Objects = Files (or datasets) Subjects = User (DN/principal) –With X.509. Possibly delegated (w. OAuth) Actions = read (mostly) Environment = (don’t care) …

Very simple policies? (Sites’ view) Site policies: –Define communities to support –Define min-req-LoA, policy-attrs., AUP accepted –Traceable identities –Agents are user-delegated (OAuth)

Very simple policies? (Fed’n view) Which LoAs are supported –Policy for assignment of LoAs to IdPs –Cross federation AUPs accepted Supporting volatile attributes? Community data must go only to community-supporting sites

Combining Algorithms Select on membership: –User is member of –PolicySet Kind of like boolean (except 3-state) (or (and (member-x) (cond-x)) (and (member-y) (cond-y))) Membership can be multi-valued (future?)

Combining Algorithms PolicySet: Policies from Com., Site, Fed’n Failsafe: deny overrides Consider ordering: in general, Com. is more specific (do last) Check communities orthogonal: (NotApplicable) if processed

Matching Community Resources (fed policy) Resource publishes (bag of) community Use of AttributeSelector

E.g. AUP and IdP-LoA Fed: IdP is covered by suitable policy –Or, user has accepted additional AUP Comm.: Must have Comm.-AUP Site: must have Comm. member and AUP

Problems – Translations Translating existing ACLs into the fed. infra “New” names: users, files –must be mapped, consistent, persistent –Particularly ePTID where no algo exists (use ?) How to address files –Replicas, PID, –Protect every replica; single ACL Datasets (PID/handle), granularity

Problems – more names urn names of attributes (AttributeDesignator) Harmonised credentials made it possible (problem is pushed to multi server and/or fed’n db) Consistency across PEPs - context

Access Control Decisions (community integration) Callout to existing PDP (e.g. REMS) –REMS: {user} x {file}  {true, false} Run a new REMS instance with e-I names Translate to fed-provided policy (language) –Maintain consistency With XACML it’d be Policy (with first-applicable ) … where Target matches file “name”, subject “name”, and action (Access)

CONCLUSION

What we can do XACML (prototype!) Data ACL (read only) Data ACL (read only) Fed level PAP

Future work PEP integration with EUDAT services Understanding of the naming problems Support more actions Link to external AA/AtP (eg VOMS) Community PAPs More testing…!

Conclusions Basics (like read-only) common to communities –Somewhat coarse grained, except objects –Expressing ~90% is relatively easy, translations harder –Still a bit experimental – getting a feel for what’s feasible –Semi-hand-knitted – works, but no direct community PAP Yes, probably XACML is overkill atm –But it makes sense to use standards –Maintain extensibility for future Move to federated authorisation not trivial –Mostly the (re)naming problems –Still need to integrate non-IdP AtP (AA) Federation must provide (consistent) authorisation –Enforced at lowest level (storage) – ConSec provides portal and API

Thanks… S Memon, FZJ (DE) I Matteucci, A Yautsiukhin, M Petrocchi, L Krautsevich, A Lazouski, CNR (IT) W Elbers, MPI (NL)

EXTRA SLIDES

POLICIES

Contradictions * Contradictory policies allow and deny the same action by the same subject on the same object within the same environment * Alice can write clinical data during office hours * Alice cannot write clinical data during office hours

Exceptions * Exceptions: different effects on the same action, and one policy is a subset of the other one. * Subjects with role General Practitioner can print documents of category medical of their patients * Subjects with ID dr12345 cannot print the document with ID xyz * dr12345 has role General Practitioner * xyz is a medical document

Correlations * Correlations: different effects and the attributes set of a policy intersects the attributes set of the other * Subjects with role Administrative Personnel can print administrative documents * Subjects with role Administrative Personnel cannot print administrative documents until 31/12/2020

Analytic Hierarchy Process 1)you have a goal in mind 2)you have different alternatives to reach the goal 3) AHP helps you in choose the most relevant alternative based on a set of criteria.

Sub-criteria Each criterion can be refined by considering sub-criteria

AHP for policy conflict resolution The goal is ranking two conflicting policies and prioritize the application of the winning policy The alternatives are the two conflicting policies The criteria are –Specificity of the subject –Specificity of the object –Specificity of the environment –The subcriteria for each criterion are for subject: ID, role, and organization for object: ID, category, and issuer for environment: status, time, and location

DEPLOYMENT

Fed stuff? Governance –Rules of membership –Policies Operations –Adding/removing sites, communities, –Security incidents (coordinate response) –Dealing with (high level) policy violations Legal –Data protection –Compliance with national legislation

Federated Id Resource PEP PDP DB Policies PAP PIP Subscr. OK X reject + suspend Federation core =attributes (SAML) Authorisation and Access Control