1. (Re)using existing AAI experiences 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 1 st 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) AuZ attrs/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 IdP AA

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

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 EUDAT Community Two portals, one presented inside the other Single login actually works! Demonstrated with CLARIN

19. IdP Bridg e Google Yahoo Umbrella WAYF IdP Auz Svr DB Account creation LoA set Attribute update (eg email) Single SP for all IdPs Uniform identity presented to the fed core (OAuth AS)

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 AuZ attrs 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