(Re)using existing AAI experiences and future --- AAI Soapbox --- Jens Jensen, STFC-RAL Terena VAMP,...

(Re)using existing AAIexperiences and future

--- AAI Soapbox ---

Jens Jensen, STFC-RALTerena 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

Community

Two 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