260 likes | 359 Views
(Re)using existing AAI experiences and future --- AAI Soapbox ---. Jens Jensen, STFC-RAL Terena VAMP, 0-1 Oct 2013. Background Question. ePTID. Why – Basic Advantages. Meet needs of existing user communities Avoiding managing ids and pwds Build on existing work, e/cyber-infra
E N D
(Re)using existing AAIexperiences and future --- AAI Soapbox --- Jens Jensen, STFC-RAL Terena VAMP, 0-1 Oct 2013
Background Question • ePTID
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)
Security as a 1st 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., 1hr for Shib • Expiry of TGT for K5 • 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 • LoA not always well defined • The attribute problem…
The attribute problem(s) • Attributes not always suitable for service • IdP rarely knows AuZ attributes • Consistency of naming values (schemata) • Users have no control • Cf. mobile phone apps
The “Account” • Holds user identity • Identity-related attributes (AuC) • Holds (sometimes) AuZattrs/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 • MinLoA • RPs and IdPs 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 LoA
How to build a better user? • Combining known statements AA AA IdP IdP IdP IdP
How to build a better user? • Combining known statements Federation Policies P2P trust AA AA IdP IdP IdP IdP
Why build a better user? • “Cloudier” • Less work needed before accessing privileged resource • (Train and grant) vs (grant and enforce) • Enable multi-LoA 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, ePTID is a pain in the bum • But it’s what it is for a reason • Workaround requires tighter integration Community Two portals, one presented inside the other Single login actually works! Demonstrated with CLARIN EUDAT
Google Single SP for all IdPs Uniform identity presented to the fed core (OAuth AS) Yahoo AuzSvr IdP Bridge Umbrella Account creation LoA set Attribute update (eg email) WAYF DB IdP
Recommendations • Give users more control over attrs • Introduce multi-LoA • Like data protecion – RPs need adequate (just-about-good-enough LoA) and relevant data • Publish data requirements (eg SLAs) • Negotiate (cf WS-AgreementNegotiation)
User Control of Personal Attrs • Which ones are released from the IdP • 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 AuZattrs • Users access AS to check their delegations
Dramatis Personae • NRENs, GEANT, eduGain – 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 IdP (org), or from AA designated by IdP 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-LoA • Combine in sensible ways: fed, community, site, user • Need for AAAaaS (Piyush Harsh) • Need Community effort
Acks This work partially funded by the Contrail and EUDAT FP7 projects Special thanks to: Shiraz Memon, FZJ, Germany AlešČernivec, XLAB, Slovenia Willem Elbers, MPI, Netherlands