Attribute Aggregation in Federated Identity

1. Attribute Aggregation in Federated Identity Attribute Aggregation in Federated Identity Nate Klingenstein ndk@internet2.edu

2. ToC • The Problem • The Framework • The Solutions • The New Problems

3. The Problem (carmody@IEEE) A researcher would like to purchase a computer from an online store offering discounts to the educational sector using a federated bank account. The researcher must establish: Member of Educational Organization Owner of Bank Account 0142203

4. The Problem • The bank is authoritative for account 0142203 • The institution is authoritative for its membership • In standard federated identity, a researcher can only provide attributes from one identity, but this transaction requires attributes from two • Traditional reconciliation/merging can’t be performed

5. The Other Problem • An astronomer is a member of a professional society that spans many organizations. The society purchases telescope time and divides it amongst its members, but wants to rely on institutional identity management to avoid creating another account for users. To reserve telescope time, the astronomer must establish: Institutional identity Has remaining telescope time

6. The Other Problem • The institution authenticates the user and is authoritative for the main identity • The virtual organization (VO) is authoritative for telescope time, but can’t vouch for the user’s identity • How can these attributes be aggregated for an application?

7. Attribute Aggregation Attribute aggregation is the process of acquiring identity information from multiple authorities in a single session. • Get the bank account information from the bank; • Get the affiliation from the educational organization; • Supply them both to the service. • Get a new computer. What do the flows look like? Well, what do your policies look like?

8. General Flow Requirements • The identities containing attributes to be aggregated must have been associated in some manner; • The SP must have sufficient information to accept assertions and attributes expressed therein; • And the UA must establish a security context with the SP.

9. Identity Association • How are two identities determined to be possessed by the same principal? • Batch association? Why not use the user? • Identity Federation (not to be confused with Federated Identity, a.k.a. account linking) • Create uni- or bi-directional links between identities using Liberty ID-WSF • Identifier Sharing • Re-use an identifier issued by one provider at another provider • Contextual Association • If a client shows up with two bearer credentials issued by different providers…

10. Conservation of Information • Federated identity transactions don’t preserve all information • Simplicity • Privacy • How much does a provider need to know? • Origins of attribute information? • The quality with which other providers have authenticated the user-agent? • Proof of another provider’s intent? • Et cetera… • Flows should accommodate policy needs

11. Security Context Establishment • The user-agent needs a security context with the SP to allow the SP to associate assertions with it • Think SHIRE • Most frequently performed by consumption of an authentication statement • May be achieved through authentication of client by SP

12. SP Database • Maintain attributes at the SP that are inappropriate for the IdP to store • Preferences • Bookmarks • Other local application data • Gateway to legacy/non-SAML systems • Generally requires that the SP cache some information from the IdP • Identifier sharing • … which could just be a persistent identifier

13. SP Database

14. Identity Proxying • Extends an identity maintained in another domain with additional attributes from another identity • Think VO • myVocs • I AM Suite • Attribute caching and reassertion troublesome • Identifier sharing • Better version with more security & privacy feasible but much harder to implement

15. Identity Proxying

16. SP-Mediated Attribute Aggregation • The SP maintains a persistent session with a user through two separate federated identity exchanges, collecting attributes • If everyone else has a lizard brain, do it yourself • Not really “SSO” or a great user experience • IdP’s need no trust relationship with each other • Contextual association

17. SP-Mediated Attribute Aggregation

18. Client-Mediated Attribute Aggregation • If an intelligent client exists, it can gather everything before ever accessing the SP • SAML ECP • Liberty ID-WSF LUAD • Cardspace(formerly known as Infocard) • Two separate transactions and logins, but mostly transparent to the user • If not SP-first, how do the IdP’s know which SP to issue the assertion to?

19. Client-Mediated Attribute Aggregation

20. IdP-Mediated Attribute Aggregation • Based on identity federation • First, ask the user to establish a link between the two identities • Log in at one, request link, log in at other • May be unidirectional or bidirectional • But what is the link? • Assertions can encode lots of information but would be complex; using hashes could remove IdP statefulness • persistentId’s are simple and the issuing IdP retains control over reuse, expiration, etc. • Do attributes get linked too?

21. IdP-Mediated Attribute Aggregation • Then express the link to an SP, allowing the SP to retrieve additional attributes from the second identity • Is this expression an assertion, or a string? • What constraints need to be supported? • Proof of intent? • Expiration? • Authentication quality? • Secret message from one IdP to the other?

22. IdP-Mediated Attribute Aggregation: Link Establishment

23. IdP-Mediated Attribute Aggregation

24. The New Problems • User interface • Where are you from? Where else are you from? Where are you primarily from? • Many hops, multiple authentications • Involuntary aggregation • Once two identities have been associated, the SP and potentially one or more IdP’s could collude to assemble all known information • Profiles • How much policy do they support? How many are there?

25. I’ve asked enough questions of you What are your questions for me? ndk@internet2.edu