1 / 10

Overview of “Attribute Aggregation In Federated Identity Management”[1]

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

overton
Download Presentation

Overview of “Attribute Aggregation In Federated Identity Management”[1]

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Background • Foundation • Identity Providers (IdP) • Service Providers (SP) • Attributes • Federated Identity Management • ABAC-Based • Unify IdPsIn 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

  3. 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 IdPwhich coordinates with all other IdPs • Rarely workable trust relationship as the proxy IdP is trusted absolutely

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

  5. 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.

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

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

  8. 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.

  9. 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.

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

More Related