Download Attribute Aggregation in Federated Identity

Attribute Aggregation in Federated
Attribute Identity
Aggregation in
Federated Identity
Nate Klingenstein
[email protected]
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 Organization
Owner 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 identity
Has 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?
[email protected]