Reusing existing AAI experiences and future AAI Soapbox

(Re)using existing AAI experiences and future --- AAI Soapbox --Jensen, STFC-RAL Terena VAMP, 0 -1 Oct 2013

Background Question • e. PTID

Why – Basic Advantages • Meet needs of existing user communities • Avoiding managing ids and pwds • Build on existing work, e/cyber-infra • Users get single login (sort of)

st 1 Security as a class WP in projects • Prev: Build first, secure later – afterthought – Still often is… • AAI designed in from the start – – But that requires a usable AAI ready to integrate Supported in useful languages (or SOA) Still hard problems to solve Inconsistent between

Single Sign-On • Single “account” • Single password with x-ple resources • Single login (subject to timeout) – Typ. , 1 hr for Shib – Expiry of TGT for K 5 – Expiry of GSI proxy (typ. 12 hrs)

Single Sign-On • Pros: – Improves the user experience – Reduces the password sharing – Single point to re(set) password – Password can be validated • Cons: – – Phishing problem Serious if cred stolen Needs X-site trust Lo. A not always well defined – The attribute problem…

The attribute problem(s) • Attributes not always suitable for service • Id. P rarely knows Au. Z attributes • Consistency of naming values (schemata) • Users have no control – Cf. mobile phone apps

The “Account” • Holds user identity – Identity-related attributes (Au. C) • • Holds (sometimes) Au. Z attrs/request Accounting information, billing Linked to credential – proof of pos. Single identifier / single persistent identifier

Not just true for e-/cyber-I • Checking into a hotel – Payment (pre or post) – Customer leaves without… • Paying • Their jewellery – Process – detailed, brokered

Aye, there’s the rub • Is the user authorised to access the service? – Has the user paid/can we make the user pay? (“payment” doesn’t have to be money) • Can we trace the user if something goes wrong (or very wrong)

The Rub • How much information do we (RPs) need about the user? • How do we ensure it is timely and accurate?

Two Approaches Federations • Policy defined, processes • Min. Lo. A • RPs and Id. Ps Reputations • More unilateral, doesn’t scale • More ad-hoc

How to build a better user? • Someone better says something nice – VO, or other trusted – Peers: social • Reputation • Policies accepted • Higher Lo. A

How to build a better user? • Combining known statements Id. P AA AA Id. P

How to build a better user? • Combining known statements Federation Policies Id. P AA AA P 2 P trust Id. P

Why build a better user? • “Cloudier” – Less work needed before accessing privileged resource – (Train and grant) vs (grant and enforce) • Enable multi-Lo. A access to resources

Policies need more work • Users accept RP AUP… how much is that worth? • Fed policies: home org says user accepts – Still the education issue • Combining policies: site, federation, VO

Actual Project Experiences • Yes, e. PTID is a pain in the bum – But it’s what it is for a reason – Workaround requires tighter integration Community EUDAT Two portals, one presented inside the other Single login actually works! Demonstrated with CLARIN

Google Single SP for all Id. Ps Uniform identity presented to the fed core (OAuth AS) Yahoo Auz Svr Id. P Bridge Umbrella Account creation Lo. A set Attribute update (eg email) WAYF DB Id. P

Recommendations • Give users more control over attrs • Introduce multi-Lo. A • Like data protecion – RPs need adequate (just-about-good-enough Lo. A) and relevant data • Publish data requirements (eg SLAs) – Negotiate (cf WS-Agreement. Negotiation)

User Control of Personal Attrs • Which ones are released from the Id. P • How they are being used (and where) • Data protection guarantees – Not just promises • How they are used once released • Withdraw the rights-of-use • Note the when-is-consent-not-consent from data protection directive

Compare Contrail use of OAuth • Delegate rights to obtain credential – With Au. Z attrs • Users access AS to check their delegations

Dramatis Personae • NRENs, GEANT, edu. Gain – infrastructure, superfederating, policy • e/cyber Projects – build • User projects (ESFRI et al) – policy, integration

Technology View • Shibboleth – Designed to err on the side of caution – Lacks flexibility in practical deployments • Moonshot – Superfederation – Carrying attrs from Id. P (org), or from AA designated by Id. P org.

Conclusion • Users are not authoritative for their attrs – Except for self assertions (cardspace, non-org email) • Users should be able to release and control – Many users, of course, “just want it to work” • Multi-fed policies, multi-Lo. A – Combine in sensible ways: fed, community, site, user • Need for AAAaa. S (Piyush Harsh) • Need Community effort

Acks This work partially funded by the Contrail and EUDAT FP 7 projects Special thanks to: Shiraz Memon, FZJ, Germany Aleš Černivec, XLAB, Slovenia Willem Elbers, MPI, Netherlands