(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) AuZ

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

IdP IdP IdP IdPAA AA

How to build a better user?

• Combining known statements

IdP IdP IdP IdPAA AA

Federation Policies P2P trust

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

EUDAT

CommunityTwo portals, one presented inside the otherSingle login actually works! Demonstratedwith CLARIN

IdPBridg

e

Google

Yahoo

Umbrella

WAYF

IdP

Auz Svr

DB

Account creationLoA setAttribute update (eg email)

Single SP for all IdPsUniform identity presentedto the fed core (OAuth AS)

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

• 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, GermanyAleš Černivec, XLAB, SloveniaWillem Elbers, MPI, Netherlands