Published on March 3, 2014
A Model for Privacy Enhanced Federated Identity Management Rainer Hörbe, EUSTIX Alliance
Privacy Issues in Federated Identity Management
Technical Privacy Controls for FIM Standard FIM (e.g. SAML WebSSO) PE-FIM • Data minimization: • Limited unobservability by TTP • IdPs release only required • IdP/AP talks to groups of attributes, only to authorized services, cannot identify services service • Limited unlinkability between services • Limited unlinkability between • Identiﬁers are targeted services • Impersonation • Messaging, payment and • (HoK) delivery are pseudonymized; ! e.g. IdP will proxy SMTP ! trafﬁc from targets email address to registered one Rationale for enhanced privacy: scaling federation across vertical sectors
Software Architecture Research Group Architectural challenge: Technical controls to Provide and evaluate enhance privacy principles, techniques, and tools to support and facilitate the development and evolution of softwareintensive system
Software Architecture Research Group Options for technical controls Provide and evaluate Identity escrow (zero-knowlege proof) principles, techniques, Late binding (separate authN from attributes) and tools to support Proxy pool (hub+spoke with many hubs) and facilitate the User-based IdPs (PAD, IMI) development and Pseudonym SP, targeted evolution(PE-FIM) attributes of softwareintensive system !5
1.5 The Privacy-enhanced FIM Architecture (PE-FIM) This model proposes an approach to federated identity management (FIM) that is privacy-friendly with respect to the requirements defined above. It is based on a 3-tier architecture that is an extended hub-and-spoke model with privacy by design principles applied to it. The hub is called the service broker (SB) in this model. Software Architecture Research Group High-level Architecture. The very outset of the PE-FIM model is the introduction of a secure pseudonymous channel to support requirements R1, R2 and R3. The desired property of this bidirectional channel is that an IdP and an SP, or two SPs, can communicate about a principal, where (a) the SPs are pseudonymous to the IdPs, (b) the principal is pseudonymous to the SPs and (c) the IdP’s and SP’s identities are vouched for by the certificate authority. Pseudonym SP one-time Providecertiﬁcates evaluate and ! principles, techniques, and pseudonymous secure channel tools to support ! Service and facilitate the Provider ! development and ! message ﬂow message ﬂow Service evolution of softwareBroker intensive system IdP trusts CA Identity Provider Certiﬁcate ! Authority Fig. 2. High-level Architecture It is assumed, but not shown in!6the picture above, that trust has been established be-
Software Architecture Research Group Pseudonymous SP Provide 3-tier architecture (hub-and-spoke) and evaluate principles, techniques, Service broker (hub) does not see user attributes and tools to support SP issues one-time encryption keys signed by CA and facilitate the Group signatures would work as well development and Unobservability improves with number of services evolution of softwareper Service Broker intensive system !7
Software Architecture Research Group Provide and Targeted Attributes (e-mail) evaluate principles, techniques, Targeted email for SP is targeted id @to support SB and tools and @ IdP Targeted email for SB is targeted id facilitate the development and SB, IdP act as MTA and rewrite address evolution of softwareintensive system !8
Software Architecture Research Group Provide and evaluate Pseudonymous Payment & Delivery principles, techniques, and tools to support Virtual credit cards and facilitate the Intermediate PO-boxes(?) development and evolution of softwareintensive system !9
Software Architecture Research Group Out of scope Provide and evaluate Display names (could beprinciples,+ number) ﬁrst name techniques, and tools to support IP-Addresses (need overlay networks) and facilitate the development and ! evolution of softwareintensive system !10
What else? The model can be applied to SAML BAE, WSTrust and OIDC as well. A proﬁle for SAML looks like this:
Certiﬁcate Authority 1 1 IdP-side Metadata Feed SP-side Metadata Feed 2 7 1 3 1 Service Broker MX Login IdP 9 1 10 1 SAML 5 1 Proxy 2 1 4 1 SP App 9 1 AP MX 8 1 Consent Service (4) /AuthnRequest/extension/pefim:SPCertEnc/ds:KeyInfo/.. (6) /Assertion/Advice/EncryptedAssertion
Project Status Development underway for PoC using OpenAM, Shibboleth and pysaml2 Demo @ EEMA/Vienna April 2014 Pilot project: EDI-federation in Austria !13
A Model for Privacy-enhanced Federated Identity Management ... The current state-of-the-art in federated identity management with respect to privacy ...
A Model for Privacy-enhanced Federated Identity Management. Rainer Hoerbe ... A Model for Privacy-enhanced Federated Identity Ma... Available from de.arxiv.org
... A Model for Privacy-enhanced Federated Identity Management. ... An identity provider cannot trace which services a user is using ...
... federated identity management ... the need for new account registration through automatic "federated provisioning" or the need to redundantly ...
View 1751 Federated Identity Management posts, ... CloudCockpit webtop APIs A federated identity ... A model for privacy-enhance federated identity ...
Federated Identity Management FIM Definition ... Federated Identity Management (FIM) is a model that enables companies with ... Federated Identity ...
Federated architecture ... to interpret the federated model and compile ... and identity management. Federated identity systems link a ...
... security approaches and programming models. Within a federated system, identities and their ... and Federated Identity Management requires ...