Overview of “Attribute Aggregation In Federated Identity Management”[1] Presented by Daniel Waymel November 2013 at UT Dallas

Background Foundation – Identity Providers (IdP) – Service Providers (SP) – Attributes Federated Identity Management – ABAC-Based – Unify IdPs In a Trust Relationship – Extends SSO – Enhanced User Convenience – Potentially Enhanced User Privacy Attribute Aggregation – Compilation of Attributes from Multiple IdPs – Greater Convenience Without Complete Loss of Privacy

Existing Solutions [1] SSO certificates : ex. X.509 Liberty Alliance – Background sharing between IdPs using randomized aliases – Note: User affiliations are known to IdPs – potential privacy leak Partnerships – IdP-Mediated Attribute Aggregation – User-Initiated linking of accounts across IdPs via shared secret – Unified alias can subsequently be passed to SPs along with IdP partnerships – Same privacy issues as with the Liberty Alliance solution myVocs – Identity Proxying – Relies on a single fully trusted IdP which coordinates with all other IdPs – Rarely workable trust relationship as the proxy IdP is trusted absolutely

New Concept - Setup John Linking Service 1: Initial Login iBay.com Rainforest.com 2: Ref: IdP1 4: Ref: IdP2 3: Ret: {Uid1423} 5: Ret: {Uid9687} UserPIDIdPLOA JohnUid1423iBay.com{1 | 2 | 3 | 4} JohnUid9687Rainforest.com{1 | 2 | 3 | 4} Note: A separate user-controlled ACL-like table is also maintained by the Linking Service for user control over interactions between SPs and IdPs.

New Concept – Setup (Cont.) In order to setup a federation of identities: The user (1) contacts the Linking Service, (2) is referred to their chosen IdP with whom they have an identity. (3) A random unique identifier is created for the user between the IdP and the LS. (4) The process repeats for additional IdPs as desired by the user. UserSPPIDIdP JohnPaybuddy.comUid1423iBay.com John*Uid9687Rainforest.com

Usage Scenario – Accessing Restricted Content on Rainforest.com John Rainforest.com (SP) Idp1: Un/pw login screen Linking Service 1: Login Request 2: Redir: IdP1 3: Ret: {attributes}, Ref1 4: Ref: LS... IdP2IdPn... 5: Ref: IdP3 – IdPn 6: Ret: {attributes} 2.5: login interaction 7: Ret: {aggregated attributes}

Usage Scenario (Cont.) In order to authenticate using a federation of identities: The user (1) contacts the Service Provider, (2-3) is referred to the SP’s authentication mechanism/IdP. If the SP finds this sufficient, the process stops here, otherwise: (4) The SP refers the user to the LS which (5-6) queries the IdPs which have the user on record, and (7) returns the aggregated attributes of the user to the SP for determination of whether the user is properly authenticated and authorized. Note: The SP can also perform the aggregation itself by having the LS return the attributes from the various IdPs to it instead of returning back an aggregated set.

Level of Assurance (LOA) [1] Four levels: 1(lowest) – 4(highest) Registration LOA – Defined by mode of authentication used for initial registration/provisioning Authentication LOA – Defined by the mode of authentication used for return access Session LOA – Defined by the mode of authentication chosen for a given session Registration LOA must dominate Authentication LOA Once authenticated with an LOA of X, only attributes from IdPs whose LOA dominate X may be aggregated, thus maintaining a baseline standard of assurance.

Further Details Implementation details are discussed in the paper, but are not discussed here due to scope and brevity. Such details include the use of public key encryption for secure communication between entities and embedding the abstract model discussed here into SAML and the Liberty Alliance and CardSpace protocols.

Reference [1] Chadwick, D. W., & Inman, G. (2009). Attribute aggregation in federated identity management. Computer, 42(5),