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