Attribute Aggregation in Federated IdentityAttribute Aggregation in

Federated Identity

Nate Klingensteinndk@internet2.edu

ToC

• The Problem• The Framework• The Solutions• The New Problems

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 OrganizationOwner of Bank Account 0142203

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

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 identityHas remaining telescope time

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?

Attribute Aggregation

Attribute aggregation is the process of acquiring identity information from multiple authorities in a single session.

1. Get the bank account information from the bank;2. Get the affiliation from the educational

organization;3. Supply them both to the service.4. Get a new computer.

What do the flows look like?Well, what do your policies look like?

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.

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…

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

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

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

SP Database

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

Identity Proxying

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

SP-Mediated Attribute Aggregation

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?

Client-Mediated Attribute Aggregation

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?

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?

IdP-Mediated Attribute Aggregation: Link Establishment

IdP-Mediated Attribute Aggregation

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?

I’ve asked enough questions of you

What are your questions for me?

ndk@internet2.edu