PresentationPDF Available

Presentation of "Preserving Privacy with Fine-grained Authorization in an Identity Management System"

Authors:

Abstract and Figures

Abstract—In policy-based management, service providers want to enforce fine-grained policies for their resources and services. Besides the assurance of digital identity, service providers usually need personal data for evaluation of access control policies. The disclosure of personal data, also known as Personally Identifiable Information (PII), could represent a privacy breach. This paper proposes an architecture that allows an individual to obtain services without the need of releasing all personal attributes. The architecture achieves that outcome evaluating the targeted policy in the domain of the identity provider, that is, policies are sent from service providers to identity providers to be evaluated, without the need of releasing some PIIs to the service provider side. We also present an implementation of a prototype using XACML 3.0 for fine-grained authorization and OpenID Connect for identity management. The prototype was evaluated through an use case representing an hypothetical scenario of a bookstore. The project demonstrated that for certain situations an user can restrict the release of PII data and still gain access to services.
Content may be subject to copyright.
Preserving Privacy with Fine-grained
Authorization in an Identity Management
System
Gerson Luiz Camillo, Carla Merkle Westphall, Jorge
Werner, Carlos Becker Westphall
Post Graduation Program in Computer Science
Department of Informatics and Statistics
Federal University of Santa Catarina
gerson.camillo@posgrad.ufsc.br,carla.merkle.westphall@ufsc.br
j.werner@posgrad.ufsc.br,carlosbwestphall@gmail.com
The Sixteenth International Conference on Networks, 2017
Introduction
Proposed Architecture
Prototype and Discussion
Conclusion and Future Work
References
Outline
1Introduction
Context
Problem
Related Work
2Proposed Architecture
Problem Statement
Proposed Architecture
3Prototype and Discussion
Prototype
Discussion
2 / 42
Introduction
Proposed Architecture
Prototype and Discussion
Conclusion and Future Work
References
Context
Problem
Related Work
Context: Authentication and Authorization Embedded
in Applications.
- For example: Java application using Spring Framework
(Spring Security).
- Spring 3: concept of Spring Expression Language
(SpEL), which provides authorization through built-in
expressions, like hasRole,hasPermission etc.
- Security separated from business logic.
3 / 42
Proposed Context: Authentication and Authorization
Externalized from Applications.
Figure 1: Proposed context of our work.
Research Problem.
Figure 2: Context and research problem.
Introduction
Proposed Architecture
Prototype and Discussion
Conclusion and Future Work
References
Context
Problem
Related Work
Research Problem.
- The attributes related to the user are known
Personally Identifiable Information (PII).
- The risks to personal information in service
providers (SP) are totally related to the amount of
collected attributes of individuals [1].
-Privacy aims to minimize the release of personal
information and/or prevent that attributes are linked to the
user [2][5][6].
-Privacy can be achieved by law,techniques, and
mechanisms.
-This work presents atechnique that aims to
minimize the disclosure of PII data.
6 / 42
Introduction
Proposed Architecture
Prototype and Discussion
Conclusion and Future Work
References
Context
Problem
Related Work
Context of Related Works.
- Different works and Privacy Enhancing
Technologies (PETs) have the purpose of increasing or
establishing privacy in the relationship between users and
service providers in IdM environment.
- This section restricts the descriptions of the works that
aim to provide privacy of personal data, as defined in EU
Directive 95/46/EC [4].
-Personal Data: piece of information that defines
directly or indirectly a natural person [4].
7 / 42
Introduction
Proposed Architecture
Prototype and Discussion
Conclusion and Future Work
References
Context
Problem
Related Work
Related Works.
Privacy-preserving Attribute-based Credentials (Privacy-ABC)
- Approach to authentication with private credentials in
IdM scenarios.
- The Privacy-ABC are technologies which enable users to
obtain credentials and derive unlinkable tokens that reveal
only a subset of attributes.
- They are based on cryptographic primitives, and two
examples of them are the schemes of Brand [11] and
Camenisch-Lysyanskaya [12].
8 / 42
Introduction
Proposed Architecture
Prototype and Discussion
Conclusion and Future Work
References
Context
Problem
Related Work
Related Works.
European projects PRIME [13] and PRIMELife [14]
-The Privacy-ABC were developed in the European
projects PRIME [13] and PRIMELife [14].
- IBM Identity Mixer (Idemix) [15][16] and the Microsoft
U-Prove [17] are commercial deployments based on
Privacy-ABC.
- Those technologies do not have a widespread use, owing
to the fact that the areas of user interface, policy
languages, and infrastructure need further research
[18][19].
- In addition, the Privacy-ABC have difficult understanding
and use [20].
- The ABC4Trust [21] project was created to overcome
some of those technical issues.
9 / 42
Introduction
Proposed Architecture
Prototype and Discussion
Conclusion and Future Work
References
Context
Problem
Related Work
Related Works.
User-Managed Access (UMA) [22]
-Profile of OAuth 2.0 and its principal aim is to able
users to manage the policies of their protected
resources (personal data, content, and services).
- The users are central in UMA, however, they may be
confronted with complex policies in Web scenarios, that
require complicated authorization choices and could
negatively affect the user’s privacy decisions.
10 / 42
Introduction
Proposed Architecture
Prototype and Discussion
Conclusion and Future Work
References
Context
Problem
Related Work
Related Works.
Chadwick and Fatema [23]
-Proposed an architecture that aims to provide
authorization services in cloud infrastructure. Privacy
is addressed by the use of sticky policies that consist
of privacy policies that are attached to the data.
- The premise was that the SPs in the cloud are reliable in
such a way that they will honor the privacy policies defined
in sticky policies.
11 / 42
Introduction
Proposed Architecture
Prototype and Discussion
Conclusion and Future Work
References
Context
Problem
Related Work
Related Works.
Architectures for policy decomposition [24] and policy federation [25][26]
-Aimed to provide confidentiality and privacy when
enforcing access control policies in distributed
environments. The proposed works are supported by
the XACML architecture because the entities of XACML
are specified to be easily distributed.
- The entities use SOAP/SAML protocols to convey the
request/response messages and the policies, all defined in
XACML specification [9].
- Despite the privacy achieved in some scenarios, the
models do not explicitly include user authentication
through identity management.
12 / 42
Introduction
Proposed Architecture
Prototype and Discussion
Conclusion and Future Work
References
Context
Problem
Related Work
Related Works.
Shibboleth 2.0 [27]
-It is a well-known example of implementation of the
Security Assertion Markup Language (SAML) protocol
[28] for IdM.
- However, some characteristics of Shibboleth 2.0 limit its
use in our architecture: the set of attributes are predefined
between the SP and IdP and there is no consent
mechanism (this was included natively in IdPv3).
- Thus, the SAML/Shibboleth 2.0 has a difficult integration
with RESTful Web API and mobile applications.
13 / 42
Introduction
Proposed Architecture
Prototype and Discussion
Conclusion and Future Work
References
Context
Problem
Related Work
Related Works.
OpenID Connect (OIDC) [3]
-The main advantages are the use of RESTful Web
APIs and the transport of data through Javascript
Object Notation (JSON) format.
- It is a recent specification for IdM and was developed on
the top of OAuth 2.0.
- OIDC is a natural choice for identity management in Web
2.0 environments.
14 / 42
Introduction
Proposed Architecture
Prototype and Discussion
Conclusion and Future Work
References
Context
Problem
Related Work
Related Works.
- Werner and Westphall [29]: They defined a model for an
IdM with privacy in cloud infrastructure. Even though
the authors have presented a model that tries to help users
to make decisions about their privacy, the architecture still
depends on SP to enforce the privacy policy.
- Ma and Sartipi [30]: They proposed an infrastructure
that integrates the OIDC to XACML for sharing
diagnostic images in cloud deployments. Their solution
transfers to the end user the management of policies,
which could be administrative burden when users have
data in different types of services.
15 / 42
Introduction
Proposed Architecture
Prototype and Discussion
Conclusion and Future Work
References
Problem Statement
Proposed Architecture
Problem Statement.
Research problem: the amount of PII data released in
IdM scenarios
Question: an user identified by IdP can access services
without releasing attributes to the SP?
Proposal: transfer of the security policy from the SP to the
IdP for evaluation.
The proposal of externalization and distribution of policy
evaluation have been studied before [25][26] (using
ABAC/XACML).
The proposed architecture uses the trust agreement
created to support a federated identity management to
federalize the authorization concerning PII data.
16 / 42
Introduction
Proposed Architecture
Prototype and Discussion
Conclusion and Future Work
References
Problem Statement
Proposed Architecture
Proposed Architecture: elements.
Authentication : through an User-Centric IdM (user
participates in every transaction, including the phase of
release personal data). Main roles: Identity Provider (IdP);
Service Provider (SP) or Resource Provider (RP) and
Relaying Party (RP).
Authorization : requirements for an access control model
based on attribute evaluation (formalized by the
Attribute-Based Access Control (ABAC)). The ABAC
evaluates rules and policies against the attributes of the
entities (subjects, resources, actions, and environment).
ABAC : the architecture is constituted by functional points:
PEP, PDP, PAP, and PIP.
17 / 42
Proposed Architecture: diagram
Figure 3: Proposed architecture. Our contribution is highlighted and
comprises PDP/PAP points and steps 6, 7 and 8 for conveying
policies.
Introduction
Proposed Architecture
Prototype and Discussion
Conclusion and Future Work
References
Problem Statement
Proposed Architecture
Proposed Architecture: steps
Steps 1 to 4 : authentication (Web SSO). In step 4, the IdP
generates a token that is redirected to RP. The token is an
authentication assertion and it corresponds to the user
credentials.
Step 5 : only occurs when end users have decided to
release personal attributes (PII data) to the RP
through the consent dialog.
Step 6 : the RP implements the ABAC model to protect
resources using fine-grained policies. If the end user have
denied access to the subject attributes, the PDP cannot
evaluate the applicable policy to the XACML request and
thus the PDP returns the Indeterminate response.
Steps 7 and 8 : transfer of the security policy from the SP to
the IdP for evaluation.
19 / 42
Introduction
Proposed Architecture
Prototype and Discussion
Conclusion and Future Work
References
Problem Statement
Proposed Architecture
Proposed Architecture: considerations
IdP domain : the information about the service of policy
evaluation is included in the metadata.
PDP points : the architecture of ABAC/XACML permits use of
different implementations for evaluation of the XACML
policy language.
20 / 42
Prototype: diagram
Figure 4: Prototype of the proposed architecture.
Introduction
Proposed Architecture
Prototype and Discussion
Conclusion and Future Work
References
Prototype
Discussion
Prototype: elements
RP domain : PEPClientApp, PDP-rp, and PAP. The
PEPClientApp owns and protects the access to resources
or services through the PEP. It intercepts the end-user
request and generates a XACML request for the PDP-rp to
obtain an access control decision. The PDP-rp evaluates
the XACML request against the policies, which protect the
services and resources. The PAP manages the access
control policies for the RP.
OP domain : OpenID Provider (OP), PDP-op, and UserInfo.
The OP is the IdP provider, which will authenticate the end
user and will provide claims about the user to the RP. The
PDP-op point evaluates the RP policies that are sent by
the PEPClientApp. The UserInfo is the repository of
end-user attributes.
22 / 42
Introduction
Proposed Architecture
Prototype and Discussion
Conclusion and Future Work
References
Prototype
Discussion
Prototype: software architecture
PEPClientApp : was constructed using base code of a sample
application which is included in the MITREid project. It
uses the Spring Framework to provide the security
elements for protection of the services.
OP (IdP) : was used the MITREid Connect because it is an
implementation of the OIDC standard.
PDP and PAP : was used the base code of the OpenAZ, which
is a reference implementation of the XACML 3.0 standard
and it supports REST interfaces and JSON messages for
communication among PDP, PAP, and PEP. It also enabled
the integration of the XACML with the OIDC.
The OpenAZ, MITREid Connect, and PEPClientApp are all
open-source software based on the Java language, and
they performed on the Tomcat Web server.
23 / 42
Introduction
Proposed Architecture
Prototype and Discussion
Conclusion and Future Work
References
Prototype
Discussion
Prototype: test case
Scenario
Online bookstore that sells books and offers service of reading
books. However, there are titles that need different types of
authorization because they are restricted material.
Authentication
The bookstore adheres to an IdM and obtains the
authentication result from an identity provider (IdP).
24 / 42
Introduction
Proposed Architecture
Prototype and Discussion
Conclusion and Future Work
References
Prototype
Discussion
Prototype: test case
Authorization
-Required characteristics: policy-based, fine-grained
controls, and dynamic management of access
controls.
- In addition, the outsourced authentication and
authorization need to adopt principles of RESTful
architecture style.
- These requirements are complied by XACML 3.0
standard for fine-grained authorization and OpenID
Connect for identity management.
25 / 42
Introduction
Proposed Architecture
Prototype and Discussion
Conclusion and Future Work
References
Prototype
Discussion
Prototype: test case
Policy identified as P1
-The following fine-grained policy was defined to
assess the use case: users authenticated by an IdP
and whose residence is in either of Japan, China, or
South Korea can view online books restricted by
locality. Besides, the books are only available between
December 1st and December 31, 2016.
- The policy is expressed in the XACML 3.0 language,
which is deployed in PAP. It will protect the resources at RP
domain besides other policies.
26 / 42
Prototype: flow
Figure 5: Authentication and consent screen.
Prototype: flow
Figure 6: Access to OpenID Provider User Info endpoint.
Prototype: flow
Figure 7: Authorization through XACML architecture.
Prototype: flow
Figure 8: Evaluation of RP policy in the domain of OP.
Introduction
Proposed Architecture
Prototype and Discussion
Conclusion and Future Work
References
Prototype
Discussion
Discussion: results
Transferring the authorization service from RP to the OP to
achieve privacy of PII data.
The architecture allowed an end user to access the protected
resources without releasing personal attributes to the RP. The
end user “Jackie” has not released the attribute country to the
RP. However, the PDP-op arrived at decision “Permit” because
it obtained the value of attribute country at OP domain.
Implementation of prototype showed low complexity
There was no need to change flows and specifications of the
OIDC and XACML. In contrast, the works and systems [13]-[19]
have to deal with the complexity of the PKI infrastructure and
questions related to integration, data formats, and user
interfaces. 31/ 42
Introduction
Proposed Architecture
Prototype and Discussion
Conclusion and Future Work
References
Prototype
Discussion
Discussion: results
Organizations do not need create security controls for PII data
Organizations that collect and store PII data should establish
security controls to provide the confidentiality of this information
[31][32]. This represents an administrative and operational
costs for those companies.
Usability
End users did not need to establish privacy policies to
manipulate their personal data. Besides, the SPs can modify
their authorization logic without updating them in the agreement
with the IdP. The proposals [22][23][29][30], which depend on
the user’s ability to define policies, may create risks to privacy
of PII due to an increase in management complexity.
32 / 42
Introduction
Proposed Architecture
Prototype and Discussion
Conclusion and Future Work
References
Prototype
Discussion
Discussion: results
Security
The aspects of confidentially, integrity, threats and security risks
are directly related to the measures adopted when
implementing the IdM infrastructure. The security measures for
OpenID Connect are those specified in the [3] and in the [33].
The [33] presents the threat model and security considerations
when implementing systems and protocols that use the
underlying protocol OAuth 2.0.
33 / 42
Introduction
Proposed Architecture
Prototype and Discussion
Conclusion and Future Work
References
Prototype
Discussion
Discussion: issues and limitations.
Limitation
There is a need of security mechanisms to protect the
confidentiality of RP policy when it leaves the domain of RP,
because it may contain sensitive information about the service
provider. This problem can be minimized considering the trust
relationship established between the OP and RP.
Anonymity
The anonymity depends on the IdM system used in the
architecture. Pseudonymity and anonymity can be obtained in
OIDC by the use of Pairwise Pseudonymous Identifier (PPID)
[3] for the value of sub claim. The PPID can be used in OIDC
without any problem in the proposed architecture.
34 / 42
Introduction
Proposed Architecture
Prototype and Discussion
Conclusion and Future Work
References
Prototype
Discussion
Discussion: issues and limitations.
Performance
There is a performance limitation regarding the authorization
actions because the architecture included steps to evaluate the
policy in the domain of OP. Solutions: works [34][35] that aim to
optimize PDP performance and the use of caching. The
question of performance can be considered a valid trade-off
between user privacy and the performance penalty to get an
authorization decision.
35 / 42
Introduction
Proposed Architecture
Prototype and Discussion
Conclusion and Future Work
References
Conclusions.
- The proposed architecture presents a new way of
obtaining privacy to users, when dealing with fine-grained
resource permissions. The SP policies are carried and
assessed in the domain of the IdP to avoid the release of
personal attributes to SP domain.
- This approach allows users to deny the release of
personal data to SP while getting a decision for accessing
resources or services.
- The outcome of the architecture is the minimization of
use, collection, and retention of personal data (PII), that
attends the principle of collection limitation from OECD
privacy guideline.
36 / 42
Introduction
Proposed Architecture
Prototype and Discussion
Conclusion and Future Work
References
Future works.
Future work might go towards research on the inclusion of
the decomposition of policies to protect the confidentiality
of some elements of the policy.
37 / 42
Introduction
Proposed Architecture
Prototype and Discussion
Conclusion and Future Work
References
References
References I
K. Cameron. The laws of identity. [retrieved: March, 2017]. [Online]. Available:
http://myinstantid.com/laws.pdf
S. Gürses, C. Troncoso, and C. Diaz. (2011) Engineering privacy by design. [retrieved: March, 2017].
[Online]. Available: http://www.cosic.esat.kuleuven.be/publications/article-1542.pdf
N. Sakimura, J. Bradley, M. B. Jones, B. d. de Medeiros, and C. Mortimore. (2014) OpenID Connect Core
1.0. [retrieved: March, 2017]. [Online]. Available:
http://openid.net/specs/openid-connect- core-1_0.html
EU.
Directive 95/46/EC of the European Parliament and of the Council, 1995.
J. Heurix, P. Zimmermann, T. Neubauer, and S. Fenz, “A taxonomy for privacy enhancing technologies,”
Computers & Security, vol. 53, pp. 1–17, 2015.
C. Landwehr et al., “Privacy and cybersecurity: The next 100 years,Proceedings of the IEEE, vol. 100, no.
Special Centennial Issue, pp. 1659–1673, May 2012.
V. C. Hu et al., “Guide to Attribute Based Access Control (ABAC) Definition and Considerations,NIST SP
800-162, 2014.
J. Vollbrecht et al., “AAA Authorization Framework,” RFC 2904, Tech. Rep., August 2000.
38 / 42
Introduction
Proposed Architecture
Prototype and Discussion
Conclusion and Future Work
References
References
References II
E. Rissanen, “eXtensible Access Control Markup Language (XACML) version 3.0 OASIS standard,” January
2013.
A. Pfitzmann and M. Hansen, “A terminology for talking about privacy by data minimization: Anonymity,
unlinkability, undetectability, unobservability, pseudonymity, and identity management,” 2010.
S. A. Brands, Rethinking public key infrastructures and digital certificates: building in privacy. MIT Press,
2000.
J. Camenisch and A. Lysyanskaya, “An efficient system for non-transferable anonymous credentials with
optional anonymity revocation,” in Advances in Cryptology – EUROCRYPT 2001, ser. Lecture Notes in
Computer Science. Springer, 2001, vol. 2045, pp. 93–118.
(2016) PRIME. The PRIME Consortium. [retrieved: December, 2016]. [Online]. Available:
https://www.prime-project.eu/
(2016) PrimeLife. PrimeLife Project Consortium. [retrieved: March, 2017]. [Online]. Available:
http://primelife.ercim.eu/
J. Camenisch and E. Van Herreweghen, “Design and Implementation of the Idemix Anonymous Credential
System,” in Proceedings of the 9th ACM Conference on Computer and Communications Security, ser. CCS
’02. New York, NY, USA: ACM, 2002, pp. 21–30. [Online]. Available:
http://doi.acm.org/10.1145/586110.586114
39 / 42
Introduction
Proposed Architecture
Prototype and Discussion
Conclusion and Future Work
References
References
References III
Identity Mixer. IBM Research. [retrieved: March, 2017]. [Online]. Available:
http://www.research.ibm.com/labs/zurich/idemix/
U-Prove. Microsoft Research. [retrieved: March, 2017]. [Online]. Available:
https://www.microsoft.com/en-us/research/project/u- prove/
C. A. Ardagna et al., “Enabling Privacy-preserving Credential-based Access Control with XACML and
SAML,” in 10th IEEE International Conference on Computer and Information Technology. IEEE, 2010, pp.
1090–1095.
P. Bichsel et al., “H2.2 - ABC4Trust Architecture for Developers,ABC4Trust, 2013.
J. Camenisch et al., “Concepts and languages for privacy-preserving attribute-based authentication,Journal
of Information Security and Applications, vol. 19, no. 1, pp. 25–44, 2014.
ABC4Trust - Project description. ABC4Tr ust EU Project. [retrieved: March, 2017]. [Online]. Available:
https://abc4trust.eu/download/ABC4Trust-Project- Description.pdf
T. Hardjono, E. Maler, M. Machulak, and D. Catalano, “User-Managed Access (UMA) Profile of OAuth 2.0,
Internet Engineering Task Force, Internet-Draft, January 2016, work in Progress.
D. W. Chadwick and K. Fatema, “A privacy preserving authorisation system for the cloud,Journal of
Computer and System Sciences, vol. 78, no. 5, pp. 1359–1373, 2012.
40 / 42
Introduction
Proposed Architecture
Prototype and Discussion
Conclusion and Future Work
References
References
References IV
D. Lin, P. Rao, E. Bertino, N. Li, and J. Lobo, “Policy decomposition for collaborative access control,” in
Proceedings of the 13th ACM symposium on Access control models and technologies. ACM, 2008, pp.
103–112.
M. Decat, B. Lagaisse, and W. Joosen, “Toward Efficient and Confidentiality-aware Federation of Access
Control Policies,” in Proceedings of the 7th Workshop on Middleware for Next Generation Internet
Computing, ser. MW4NG ’12. New York, NY, USA: ACM, 2012, pp. 4:1–4:6. [Online]. Available:
http://doi.acm.org/10.1145/2405178.2405182
——, “Middleware for efficient and confidentiality-aware federation of access control policies,” Journal of
Internet Services and Applications, vol. 5, no. 1, pp. 1–15, 2014. [Online]. Available:
http://dx.doi.org/10.1186/1869-0238- 5-1
M. Erdos and S. Cantor, “Shibboleth architecture draft v05,Internet2/MACE, May, vol. 2, 2002.
N. Ragouzis et al., “Security Assertion Markup Language (SAML) v2.0 Technical Overview,” 2008.
J. Werner and C. Westphall, “A Model for Identity Management with Privacy in the Cloud,” in 2016 IEEE
Symposium on Computers and Communication (ISCC), Messina, Italy, June 2016, pp. 463–468.
W. Ma and K. Sartipi, “Cloud-based Identity and Access Control for Diagnostic Imaging Systems,” in
Proceedings of the International Conference on Security and Management (SAM). Athens: The Steering
Committee of The World Congress in Computer Science, Computer Engineering and Applied Computing
(WorldComp), 2015, pp. 320–325.
41 / 42
Introduction
Proposed Architecture
Prototype and Discussion
Conclusion and Future Work
References
References
References V
OECD, Guidelines on the Protection of Privacy and Transborder Flows of Personal Data. Organisation for
Economic Co-operation and Development, 1981.
E. McCallister, T. Grance, and K. Scarfone, “Guide to Protecting the Confidentiality of Personally Identifiable
Information (PII),” NIST SP 800-122, 2010.
T. L. (ed.), M. McGloin, and P. Hunt, “OAuth 2.0 Threat Model and Security Considerations (RFC 6819),” RFC
6819, Internet Engineering Task Force, Informational, January 2013, [retrieved: March, 2017]. [Online].
Available: https://tools.ietf.org/html/rfc6819
S. Marouf, M. Shehab, A. Squicciarini, and S. Sundareswaran, “Adaptive reordering and clustering-based
framework for efficient XACML policy evaluation,” IEEE Transactions on Ser vices Computing, vol. 4, no. 4,
pp. 300–313, 2011.
A. Mourad and H. Jebbaoui, “Towards efficient evaluation of XACML policies,” in Pr ivacy, Security and Trust
(PST), 2014 Twelfth Annual International Conference on. IEEE, 2014, pp. 164–171.
42 / 42
ResearchGate has not been able to resolve any citations for this publication.
Conference Paper
Full-text available
Policy-based computing is taking an increasing role in providing real-time decisions and governing the systematic interaction among distributed cloud and Web services. XACML has been known as the de facto standard widely used by many vendors for specifying access control and context-aware policies. Accordingly, the size and complexity of XACML policies are significantly growing to cope with the evolution of web-based applications. This growth raised many concerns related to the efficiency of real-time decision process (i.e. policy evaluation). This paper is addressing this concern through the elaboration of SBA-XACML, a novel set-based algebra scheme that provides efficient evaluation of XACML policies. Our approach constitutes of elaborating (1) set-based language that covers all the XACML components and establish an intermediate layer to which policies are automatically converted, and (2) policy evaluation module that provides better performance compared to the industrial standard Sun Policy Decision Point (PDP) and its corresponding ameliorations. Experiments have been conducted on real-life and synthetic XACML policies in order to demonstrate the efficiency, relevance and scalability of our proposition. The experimental results explore that SBA-XACML evaluation of large and small sizes policies offers better performance than the current approaches, by a factor ranging between 2.4 and 15 times faster depending on policy size.
Article
Full-text available
The past and the future of privacy and cybersecurity are addressed from four perspectives, by different authors: theory and algorithms, technology, policy, and economics. Each author considers the role of the threat from the corresponding perspective, and each adopts an individual tone, ranging from a relatively serious look at the prospects for improvement in underlying theory and algorithms to more lighthearted considerations of the unpredictable futures of policy and economics.
Article
Privacy-enhancing technologies (PETs) belong to a class of technical measures which aim at preserving the privacy of individuals or groups of individuals. Numerous PETs have been proposed for all kinds of purposes, but are difficult to be compared with each other. The challenge here lies in the fact that information privacy is a comprehensive concept with solutions being diverse, with different focus and aims. As existing taxonomies cover information security-related aspects, while neglecting privacy-specific properties, this work aims at filling this gap by describing a universal taxonomy of PETs where the taxonomy aspects are selected such that they allow the categorization of PETs in different dimensions and properties to cover a wide area of privacy (user privacy, data privacy, …). It provides the reader with a tool for the systematic comparison of different PETs. This helps in identifying limitations of existing PETs, complementary technologies, and potential research directions. To demonstrate its applicability, the proposed taxonomy is applied to a set of key technologies covering different disciplines such as data anonymization, privacy-preserving data querying, communication protection, and identity hiding.
Article
Existing cryptographic realizations of privacy-friendly authentication mechanisms such as anonymous credentials, minimal disclosure tokens, self-blindable credentials, and group signatures vary largely in the features they offer and in how these features are realized. Some features such as revocation or de-anonymization even require the combination of several cryptographic protocols. The variety and complexity of the cryptographic protocols hinder the understanding and hence the adoption of these mechanisms in practical applications. They also make it almost impossible to change the underlying cryptographic algorithms once the application has been designed. In this paper, we aim to overcome these issues and simplify both the design and deployment of privacy-friendly authentication mechanisms. We define and unify the concepts and features of privacy-preserving attribute-based credentials (Privacy-ABCs), provide a language framework in XML schema, and present the API of a Privacy-ABC system that supports all the features we describe. Our language framework and API enable application developers to use Privacy-ABCs with all their features without having to consider the specifics of the underlying cryptographic algorithms—similar to as they do today for digital signatures, where they do not need to worry about the particulars of the RSA and DSA algorithms either.
Conference Paper
This paper presents our work in progress on efficient and confidentiality-aware access control for Software-as-a-Service applications. In SaaS, a tenant organization rents access to a shared, typically web-based application. Access control for these applications requires large amounts of fine-grained data, also from the remaining on-premise applications, of which often sensitive application data. With current SaaS applications the provider evaluates both provider and tenant policies. This forces the tenant to disclose its sensitive access control data and limits policy evaluation performance by having to fetch this data. To address these challenges, we propose to decompose the tenant policies and deploy them across tenant and provider in order to evaluate parts of the policies near the data they require as much as possible, while taking into account the tenant confidentiality constraints. We present a policy decomposition algorithm based on a general attribute-based policy model and describe a supporting middleware system. In the future, we plan to refine this work and evaluate the impact on performance using real-life policies from research projects.
Article
In this paper we describe a policy based authorisation infrastructure that a cloud provider can run as an infrastructure service for its users. It will protect the privacy of usersʼ data by allowing the users to set their own privacy policies, and then enforcing them so that no unauthorised access is allowed to their data. The infrastructure ensures that the usersʼ privacy policies are stuck to their data, so that access will always be controlled by the policies even if the data is transferred between cloud providers or services. This infrastructure also ensures the enforcement of privacy policies which may be written in different policy languages by multiple authorities such as: legal, data subject, data issuer and data controller. A conflict resolution strategy is presented which resolves conflicts among the decisions returned by the different policy decision points (PDPs). The performance figures are presented which show that the system performs well and that each additional PDP only imposes a small overhead.