1 / 26

(Re)using existing AAI experiences and future --- AAI Soapbox ---

(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

yitro
Download Presentation

(Re)using existing AAI experiences and future --- AAI Soapbox ---

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Background Question • ePTID

  3. 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)

  4. 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

  5. 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)

  6. 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…

  7. 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

  8. 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

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

  10. 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)

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

  12. Two Approaches Federations • Policy defined, processes • MinLoA • RPs and IdPs Reputations • More unilateral, doesn’t scale • More ad-hoc

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

  14. How to build a better user? • Combining known statements AA AA IdP IdP IdP IdP

  15. How to build a better user? • Combining known statements Federation Policies P2P trust AA AA IdP IdP IdP IdP

  16. 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

  17. 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

  18. 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

  19. 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

  20. 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)

  21. 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

  22. Compare Contrail use of OAuth • Delegate rights to obtain credential • With AuZattrs • Users access AS to check their delegations

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

  24. 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.

  25. 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

  26. 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

More Related