D2.1 Trust, Security and Privacy Approaches for Reliable Entity Management

skillfulwolverineSoftware and s/w Development

Dec 2, 2013 (3 years and 8 months ago)

411 views




OKKAM


Enabling
a

Web Of Entities

Grant Agreement No. 215032

D2.1 Trust, Security and Privacy Approaches for Reliable
Entity Management


Document Number

D2.1

Document Title

Trust, Security and Privacy Approaches for Reliable Entity
Management

Version

2.0

Status

Final

[
REVISED
]

Work Package

WP2

Deliverable Type

Report

Contractual Date of Delivery

31 December 2009

Actual Date of Delivery

02 December 2013

Responsible Unit

PCA
-
5

Contributors

UMA

Keyword List

S
ecurity, digital certificates, access control, web services
security,

proxy security, trust, privacy, semantic
s
.


Dissemination level

PU


D2.1



Trust, Security
and Privacy Approaches for Reliable Entity Management


© OKKAM Consortium
-

FP7
-
IST
-
215032

Version

2
.
0


Page
2

of
112


Change History

Version

Date

Status

Author (Unit)

Description

0.1

10/11/09

Draft

Antonio Maña (UMA)

Initial draft.

0.2

20/11/09

Working

Hristo Koshutanski (UMA)

Filled in security proxy
implementation section

0.3

17/12/09

Working

Antonio Maña (UMA)

Filled in access control section.

0.4

18/12/09

Working

Ernesto J. Pérez
(UMA)

Added proxy performance
diagram, and Web services
security.

0.5

11/01/10

Working

Gimena Pujol (UMA)

Added delegation subsection.

0.6

19/01/10

Working

Marioli Montenegro (UMA)

Added semantic schema
subsection.

0.7

01/02/10

Working

Jose Ruiz (UMA)

Added entity evolution list
subsection.

0.8

08/02/10

Working

Antonio Maña (UMA),
Hristo Koshutanski (UMA)

Added appendixes.

0.9

10/02/10

Working

Antonio Maña (UMA),
Hristo
Koshutanski (UMA)

Completed all sections.

1.0

11/02/10

Final

Antonio Maña (UMA),
Hristo Koshutanski (UMA)

Minor changes on structure and
text descriptions.

2
.0

30
/
06
/10

Revised

Antonio Maña (UMA),
Hristo Koshutanski (UMA)
,
Ernesto J. Pérez (UMA)
,
Jose Ruiz (UMA)

R
evis
ion

over v1.0. Added
more accurate measurements
showing
improved security
performance,
added
certificate
revocation support,
added
protected

APIs description
,
updated description of entity
evolution lists,
and
added
detailed

comparison of ENS
security
and

single sign
-
on

approaches
.


D2.1



Trust, Security
and Privacy Approaches for Reliable Entity Management


© OKKAM Consortium
-

FP7
-
IST
-
215032

Version

2
.
0


Page
3

of
112


Executive Summary

The OKKAM
provides a scalable and sustainable infrastructure, called the

Entity Name
System

(ENS), for making systematic reuse of global and unique entity identifiers.
Th
is

deliverable

describes
trust
,

security and privacy approaches for reliable entity management of the
ENS.

It first describes an OKKAM se
curity and trust infrastructure.
Trust in OKKAM is based on
certificate authorities that qualify both
ENS

repositories an
d
OKKAM
user
s

by means of digital
certificates
.

There are three main security elements underpinning
the
OKKAM security
infrastructure: (i) Digital certificates qualifying OKKAM entities; (ii) A
doption of widely
used
certificate
-
based security and trust
standards; (iii) Realization of security pr
oxy concept
facilitating access,
usage

and future development

of
the

ENS. The OKKAM security
infrastructure has been realized and put in practice as of ENS v2 release.

The document presents

an

OKKAM access control

model as synergy of a semantic access
control specification and an interactive trust negotiation enforcement mechanism. The synergy
enables a scalable policy specification to the large
-
scale
ENS repository of entities,
and
automated enforcement of those s
pecifications
to

OKKAM users.

Several security components have been presented, some of them important for ENS v3

release
, while others important for future ENS evolution, beyond the project lifetime.

There are
six

appendixes enclosed to the deliverable pre
senting additional information to the
core document text, which
have

been considered important for completeness of the document
.

Current deliverable (v2.0) is a major revision of its predecessor (v1.0) where several aspects
have bee
n added. Namely, it was
added more accurate measurements showing the improved
security performance
, added a separate section of detailed security evaluation
, added a
description of certificate revocation support as of ENS v3, improved description of protected
ENS APIs, and finall
y added an appendix on comparison of ENS security vs single sign
-
on
approaches.


The main conclusion
out of

security
evaluation is that the developed ENS security solution is
not a bottleneck for
the
ENS performance. The security solution meets with more t
han
200%

the
performance time recommended in the official Y
2

review report
, and
evaluates to
4 secure QPS
(queries per second)
of

ENS single
-
core response to secure query (WS API) requests.
A
reduction of

20%

of ENS QPS capacity
is measured by the
security overhead
given

5 QPS
matching capability (as reported during Y2 review)
.

The formal response has been added as
an
appendix to deliverable
D5.6

and

a summary
of it
is included
in

Appendix A
.



D2.1



Trust, Security
and Privacy Approaches for Reliable Entity Management


© OKKAM Consortium
-

FP7
-
IST
-
215032

Version

2
.
0


Page
4

of
112




TABLE OF CONTENTS

1.

INTRODUCTION

................................
................................
................................
................................
.............

7

2.

SECURITY AND TRUST I
NFRASTRUCTURE

................................
................................
........................

11

2.1.

ENS

A
RCHITECTURE

................................
................................
................................
................................
...............

11

2.2.

OKKAM

S
ECURITY AND
T
RUST
I
NFRASTRUCTURE

................................
................................
...........................

12

2.3.

OKKAM

C
ERTIFICATE
M
ANAGEMENT

................................
................................
................................
................

13

2.3.1.

Certificate Revocation

................................
................................
................................
................................
.......

16

2.4.

P
ROXY
-
BASED
S
ECURITY
D
ESIGN AND
I
MPLEMENTATION

................................
................................
...............

17

2.4.1.

Secured Access to Protected ENS APIs

................................
................................
................................
.......

19

2.4.2.

Security
-
specific APIs

................................
................................
................................
................................
.........

23

2.4.3.

Key Web Services Security
Standards Adopted

................................
................................
.....................

26

2.4.4.

Proxy Architecture Inside View

................................
................................
................................
.....................

26

2.4.5.

ENS
-
side Security Scalability

................................
................................
................................
.........................

29

2.4.6.

End
-
users Authentication via ENS Web Front
-
ends

................................
................................
............

29

2.4.7.

Proxy Interactions with ENS

................................
................................
................................
..........................

31

2.4.8.

Business
-
driven Security Management

................................
................................
................................
.....

33

2.4.9.

ENS Security Opt
imization

................................
................................
................................
..............................

33

2.5.

S
ECURITY
P
ERFORMANCE

................................
................................
................................
................................
......

34

3.

ACCESS CONTROL

................................
................................
................................
................................
........

40

3.1.

S
EMANTIC
A
CCESS
C
ONTROL
M
ODEL

................................
................................
................................
..................

40

3.1.1.

Access Control based on Attribute Certificates.

................................
................................
.....................

41

3.1.2.

Overview of the Semantic Access Control System for WS

................................
................................
.

42

3.1.3.

High
-
level Functional Arch
itecture for OKKAM

................................
................................
....................

44

3.1.4.

The Semantic Policy Language

................................
................................
................................
.....................

44

3.1.5.

Se
mantic Definition of Access Policies in OKKAM

................................
................................
................

47

3.2.

A
CCESS
C
ONTROL
E
NFORCEMENT
:

A
UTOMATED
T
RUST
N
EGOTIATION

................................
.......................

49

3.3.

S
EMANTIC
S
CHEMA
A
PPROACH FOR
E
NABLING
F
INE
-
GRAINED
A
CCESS
C
ONTROL

................................
.....

51

3.3.1.

Introduction

................................
................................
................................
................................
...........................

51

3.3.2.

The Role of Semantic Schemas for the FGAC

................................
................................
..........................

54

3.3.3.

Proposed Semantic Schema Model

................................
................................
................................
..............

54

4.

TOWARDS ENS V3

................................
................................
................................
................................
.......

60

4.1.

S
EMANTIC
A
CCESS
C
ONTROL
D
EPLOYMENT

................................
................................
................................
.......

60

4.2.

D
ELEGATION

................................
................................
................................
................................
.............................

60

4.3.

C
ERTIFICATE
-
CODED
R
ESTRICTIONS

................................
................................
................................
....................

62

5.

ADDITIONAL SECURITY
COMPONENTS
................................
................................
...............................

64

5.1.

S
UPPORTING
E
XTERNAL
I
DENTITY
P
ROVIDERS

................................
................................
................................
.

64

5.2.

S
EMANTIC
I
NTEROPERABILITY OF
C
ERTIFICATES

................................
................................
..............................

65

5.2.1.

Automated Trust Negotiation with Seman
tic Interoperability of Credentials

.......................

67

5.3.

E
NTITY
L
IFECYCLE
M
ANAGEMENT
:

EEL

................................
................................
................................
.............

68

5.3.1.

Entity Evolution List Generator

................................
................................
................................
....................

69

5.4.

Q
UERY
F
ILTERING

................................
................................
................................
................................
....................

72

5.5.

Q
UERY
F
ORWARDING
C
ONTROL
................................
................................
................................
............................

73

5.6.

M
ATCHING
:

M
ATCHING
M
ODULE
R
EPLACEABILITY

................................
................................
..........................

73

6.

CONCLUSIONS

................................
................................
................................
................................
...............

75

BIBLIOGRAPHY

................................
................................
................................
................................
....................

76

APPENDIX A. ENS CERT
IFICATE
-
BASED SECURITY AND S
INGLE SIGN
-
ON

................................
......

79


D2.1



Trust, Security
and Privacy Approaches for Reliable Entity Management


© OKKAM Consortium
-

FP7
-
IST
-
215032

Version

2
.
0


Page
5

of
112


APPENDIX B. BACKGROU
ND AND RELATED WORK

................................
................................
................

84

APPENDIX C. ROADMAP
OF ENS SECURITY FEAT
URES

................................
................................
..........

92

APPENDIX D. SECURITY

REQUIREMENTS OF ENS

................................
................................
....................

93

APPENDIX E. ENTITY E
VOLUTION LI
ST API

................................
................................
............................

101

APPENDIX F. OKKAM US
ER DATA PRIVACY POLI
CY

................................
................................
............

104




D2.1



Trust, Security
and Privacy Approaches for Reliable Entity Management


© OKKAM Consortium
-

FP7
-
IST
-
215032

Version

2
.
0


Page
6

of
112


LIST OF
FIGURES

F
IGURE
1.

ENS

A
RCHITECTURE
[22]
................................
................................
................................
....................

12

F
IGURE
2.

OKKAM

S
ECURITY
I
NFRASTRUCTURE
G
LOBAL
V
IEW

................................
................................
......

13

F
IGURE
3.

OKKAM

C
ERTIFICATE
I
NFRASTRUCTURE

................................
................................
..........................

14

F
IGURE
4.

C
LIENT
-
S
ERVER
M
ODEL OF
S
ECURITY
P
ROXY

................................
................................
...................

18

F
IGURE
5.

API
-
LEVEL
P
ROXY
-
BASED
C
OMMUNICATIONS

................................
................................
...................

20

F
IGURE
6.

S
ECURITY
P
ROXY
I
NSIDE
V
IEW

................................
................................
................................
............

27

F
IGURE
7.

E
ND
-
USERS
A
UTHE
NTICATION TO
ENS

VIA THE
OKKAM

W
EB
F
RONT
-
END

...............................

30

F
IGURE
8.

C
LIENT
-
SIDE
P
ROXY
I
NTERACTIONS WITH THE

ENS

................................
................................
........

32

F
IGURE
9.

L
OCALHOST
(
LEFT
-
HAND SIDE
)

AND
T
EST
P
LATFORM
(
RIGHT
-
HAND SIDE
)

M
EASUREMENTS

....

35

F
IGURE
10.

ENS

SECURITY OVERHEAD

................................
................................
................................
.................

38

F
IGURE
11.

ENS

SECURITY OVERHEAD
:

FINE
-
GRAINED MEASUREMENTS

................................
.........................

3
9

F
IGURE
12.

O
VERVIEW OF THE
SAC

AC

SYSTEM

................................
................................
..........................

44

F
IGURE
13.

O
VERALL POLICY INSTAN
TIATION AND ENFORCEM
ENT PROCESS

................................
..................

44

F
IGURE
14.

C
ONCEPTUAL MODEL OF
THE
SPL

L
ANGUAGE

................................
................................
.........

46

F
IGURE
15.

(
A
)

C
ONSULTING
_A
CCESS
.
XML
P
OLICY AND
(
B
)

SRR

E
XAMPLE

................................
........

46

F
IGURE
16.

PAS

FOR THE
C
ONSULTING
_A
CCESS
.
XML

................................
................................
........................

47

F
IGURE
17.

A
UTOMATED
T
RUST
E
STABLISHMENT FOR
A
DMINISTRATOR
A
CCESS
................................
..........

50

F
IGURE
18.

E
XAMPLE OF END
-
USE
R
GUI

FOR CREATING AN ENTI
TY DESCRIPTION

................................
.........

55

F
IGURE
19.

R
ELATIONS BETWEEN AN
ENTITIES AND
SSD
S

................................
................................
................

59

F
IGURE
20.

C
ERTIFICATE
D
ELEGATION
M
ECHANISM
O
VERVIEW

................................
................................
......

61

F
IGURE
21.

E
NTITY
C
REATION WITH
C
ERTIFICATE
-
CODED
R
ESTRICTIONS

................................
.....................

63

F
IGURE
22.

A
UTOMATED TRUST NEGO
TIATION WITH A SEMAN
TIC INTEROPERABILITY
................................
..

67

F
IGURE
23.

E
NTITY
E
VOLUTION
L
IST WORKFLOW

................................
................................
..............................

68

F
IGURE
24.

EELG
ENERATOR STRUCTURE

................................
................................
................................
............

70

F
IGURE
25.

EELG
ENERATOR INTERACTION

DIAGRAM

................................
................................
........................

70

F
IGURE
26.

EELG
ENERATOR CLASSES

................................
................................
................................
..................

71

F
IGURE
27.

EELG
ENERATOR WITH AN
EEL

DISPLAYED

................................
................................
....................

72

F
IGURE
28.

M
ATCHI
NG MODULE REPLACEABI
LITY INFRASTRUCTURE
................................
...............................

74

F
IGURE
29.

E
NTITY
E
VOLUTION
L
IST
API

STRUCTURE

................................
................................
...................

101

F
IGURE
30.

EEL

CLASS STRUCTURE

................................
................................
................................
...................

101

F
IGURE
31.

E
NTITY
E
VOLUTION CLASS STRUC
TURE

................................
................................
..........................

102



D2.1



Trust, Security
and Privacy Approaches for Reliable Entity Management


© OKKAM Consortium
-

FP7
-
IST
-
215032

Version

2
.
0


Page
7

of
112


1.

Introduction

OKKAM
provides a scalable and sustain
able infrastructure, called the
Entity Name System

(ENS), for
making systematic reuse of global and uni
que entity identifiers. The ENS
stores
identifiers for entities and provides a collection of core services needed to support their pervasive
reuse.
The p
roject is collaboratively developed by its
community of
users using the Project’s
software, the ENS cor
e services, and any third
-
party services based on the Project’s software and
the
core services.

Trust, security and privacy
approaches
,

undertaken in OKKAM
,

are
mainly determined by the
open
and
decentralized

interactions

of OKKAM
community of users.

The
open nature defines
that OKKAM aims at providing services to any user, organizat
ion or company having any
benefi
t of
using

the
OKKAM for
its
own needs.
On the other side, the project is open to any
public contribution
of

users, organizations and co
mpanies. The public nature

of OKKAM is that
it serves to the
publi
c and
, at the same time,

it is
open to contribution by the public.


The
decentralized

style of OKKAM is determined by the fact that
t
he ENS stays “hidden”
to

all interactions
of

the
OKKAM co
mmunity, but
provides core services, both security and
functional services, to its users.
Let us take, for example, the OKKAM
Web

Front
-
end
1
.

It is an
external to ENS application that provides Web
-
based GUI of ENS entity creation, administration
and life c
ycle management.
Regarding security and trust aspects, t
he front
-
end is first registered
to the ENS as
a
le
gal OKKAM entity

and then

it
is approved as
an
intermediary se
rvice provider
to ENS in order to
provide the entity creation service

on
behalf of

end
-
users.
This
use case
is

discussed
in

Section
2.4.6
.

The important asp
ect of this example is
that

end
-
users interact
with

the

(hidden)

ENS
in a decentralized w
ay
via the
OKKAM
Web front
-
end.


Driven by the open and decentralized community interactions,
it has been
designed

that

t
rust
in the OKKAM infrastructure is based on certificate authorities that qualify
both
OKKAM
repositories and
user privileges by means of digital certificates.
Digital certificates are well
suited for decentralized peer
-
to
-
peer identification and authorization. Management of digital
certificates as well as privacy of their usage
are

key
issue
s

in OKKAM
,
addressed
by the concept
of security proxies
.


The main cornerstone of the OKKAM security architecture
,
and
also a pillar
for

business
-
driven security,

is the development of security proxies on both client
-
side and ENS
-
side. The
role of security prox
ies

is to encaps
ulate security, trust and privacy control aspects into a
transparent
configuration
-
only component
that provides
high
-
level
security abstraction
to

users
,
application
developers and

administrators of

the
ENS.

A
ny
usage of
ENS

services

or contribution to ENS
is subject to

the

security, trust and privacy
aspects

of the ENS.

Secure and trusted
usage

of

the core ENS services is
driven by access
control based

on
digital certificates attesting users’ privileges.

There are two main
access cont
rol
dimensions identified
:




E
ffective acces
s control enforcement mechanism

between clients and the ENS,
and



S
calable

and flexible

access control specification
for

large
-
scale

ENS
repositories
.

A
ccess control enforcement
.
Effective access control enforcement is
achieved

by means of

bilateral user
-
to
-
ENS trust establishment
allowing users and the ENS
build confidence in each
other
to proceed with a service access.





1

OKKAM Web Front
-
end: http://api.okkam.org


D2.1



Trust, Security
and Privacy Approaches for Reliable Entity Management


© OKKAM Consortium
-

FP7
-
IST
-
215032

Version

2
.
0


Page
8

of
112


Credentials themselves convey sensitive information and may
become subject to unauthorized
misused and disclosure
.
Recent years have seen the emergence of a concept called trust
negotiation [
25
,
32
]. It is a policy
-
based technique that provides clients with the right to protect
their own credentials and
to
negotiate

with
servers

access to those credentials.

Trust negotiation

preserves peer’s privacy by control
ling

what
credentials are disclosed to what entities under
given conditions.

Thus
,

trust negotiation allows users and the ENS to mutually establish
confidence i
n each other

by requesting credentials until
sufficient trust is established for
accessing a service.

The trust negotiation mechanism adopted
in the

OKKAM security framework
is based on the
work [
13
,
14
]
.
The goal is to provide a generic access control
enforcement process to ENS, which
fits well in the OKKAM perspective of providing services to an open public/community domain
of individual users, organ
izations and private companies.

The negotiation approach

also
facilitate
s

future evolvement of the ENS i
n terms
of security requirements and settings.

A
ccess control

specification
.
The
large
-
scale
ENS repository
introduces

new
challenges related
to
access control specification and management

of policy requirements for the vast number of

repository entries
.
The access control specification
, adopted as part of the OKKAM security
framework,

is ba
sed on a
semantic access control (SAC)

model [
34
,
35
]

that
defines

in a scalable
and flexible way semantic abstraction of access policy specification from policy
applicability to
resources.

The SAC model
defines

access policies requirements
to

specific

semantic properties
,
and defines a separate policy applicability specification that, during run
-
time operations,
determines which semantic policies apply to
what
ENS

repository

entities

taking into account
both,
the
semantic

properties

of the
access polices and t
he
semantics of
ENS
entities
.
In that way,
a large amount of ENS repository entities could qualify to relatively few

access policies
specifications

and
,

as co
nsequence, facilitate scalable access control management.

The SAC
model also supports definition of RBAC
-
compliant models, which fits well for private ENS
nodes running under specific organizational settings.

One of the main OKKAM challenges is to allow users to use their own attribute schema for
describing entities on the Web. This open attribute schema
poses an inherent challenge

to the
access control protection of ENS entities.
I
t has been adopted a semantic

schema approach
to
enabl
e

SAC specification
s

for

the ENS repository entities.

Foundationally, the semantic schema
approach “enriches”
an

ENS entity description with

known semantic schema, so that the SAC
specification
deterministically defines protection
of ENS entities
based on the semantic schema
description.


By using the semantic
schema approach as a way to enable fine
-
grained semantic access
control, OKKAM supports another important end user aspect: end users are not expected
t
o
define

protection

for
the identities they create
, but are aware of
(able to determine)
what
semantic schemas best describe their entities.

Proxy
-
based
security implementation
.

To facilitate users,
application
developers and third
-
party ENS service providers, the OKKAM project has
developed a

security proxy

component
(both server
-

and client
-
side)
that abstracts all necessary security management and technological
aspects from application
-
level development.

W
e s
ummarize
key

proxy characteristics:



Decouple
s

security aspects from application aspects:

t
ransparent
and independent
management of security settings from application level,



Enable
s

even thin W
eb
S
ervices

applications, such as the ENS plug
-
ins for MS Word,
Firefox etc, to achieve a good level of security

and trust

with
the
ENS.


D2.1



Trust, Security
and Privacy Approaches for Reliable Entity Management


© OKKAM Consortium
-

FP7
-
IST
-
215032

Version

2
.
0


Page
9

of
112




Hide
s

the
complexity of Web Services security
standards and
technologies used
for

implement
ation of

secure and trusted communications with the ENS.



Integrates

authentication, access control and
automated
trust establishment,



Protect
s

privacy of
users’
and server’s
certificates from unauthorized disclosure,



Efficient and scalable security by deploying
server
-
side

proxy at any ENS core (in a cluster),



Provide
s

se
cure registration

functionality to OKKAM users
,



Facilitate
s

business
-
driven security
requirements
,



Enables uniform management of security, trust and privacy settings
with
the ENS and
private ENS nodes.

ENS

as
exclusive authority
.

The
OKKAM
ENS is the
exclusive
authority of all entities
created
by means of the OKKAM ENS system
.
In that context, any entity created
in the

ENS
inherits the security, trust and privacy aspects of the ENS as the sole authority of that entity. It is
not considered the case whe
re an entity created in the ENS inherits authority rules external to
the
ENS.

Even

if an entity from one ENS node replica is imported into another ENS node replica, no
“sticky policy”

is accepted for that enti
ty from the source node replica

but
,

instead, t
he imported
entity inherits the
already defined trust, security and privacy aspects of destination ENS node.
It
is the responsibility of the ENS administration manager (officially promoted by the OKKAM
consortium)
to harmonize all security, trust and priva
cy aspects across ENS replicas.

In
such a

way,
it

is achieved a unified and
consistent

implementation of the ENS authority rules on any
ENS node.


Support of user privacy rights
.
Appendix
F

shows the OKKAM user data privacy policy
.

The
project governs the
user private information as closely as possible to Regulation (EC) 45/2001
2
.

ENS security requirements

and analysis
.
Appendix

D

shows all identified security
requirements

that affect OKKAM
, such as
: protection against data mining attacks, protection
agains
t attacks based on publishing false information, control over data aggregation, etc
.

During the course of the project only the most
relevant
security aspects are
addressed, those
that most support ENS and its community start
-
up
, while the appendix
D

shows all identified
security requirements for completeness and future
ENS development
.
Refer to
Appendix
C

for

ENS security features roadmap.

T
here is a main assumption regarding ENS security, which is
that ENS protects only the
information stored in
side

the ENS and how access to that information is
managed
.
The ENS
security framework does not secure the Web of entities, or any data mining attacks based on
combination of ENS information and information on the Web.

Document structure
.

Preliminary descri
ptions of some of the elements described in this
document
have been

included in deliverables D5.1 and D6.1. However, these elements are also
described in this deliverable in order to make it self
-
contained, and to document their current
status.
The

documen
t has been structured to facilitate reading by both experts and non
-
experts in
security. For this reason, background

and supporting information

has been placed on
separate
appendixes

in order to
provide

a focus
ed

core document description
and

self
-
cont
a
ined
overall
deliverable.




2

REGULATION (EC) No 45/2001 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of
18 December 2000 on “the protection of individuals with regard to the proc
essing of personal data by the
Community institutions and bodies and on the free movement of such data”. Official Journal of the
European Communities, 2001.


D2.1



Trust, Security
and Privacy Approaches for Reliable Entity Management


© OKKAM Consortium
-

FP7
-
IST
-
215032

Version

2
.
0


Page
10

of
112


The rest of the deliverable is structured
as

following
:

Section
2

describes

the ENS security infrastructure, how secure and tr
usted communications
are managed, and what access control components are used to protect
ENS services.
The section
then describes h
ow the ENS security is faced and implemented by means of proxies, what access
control enforcement is performed to core ENS APIs
, and what security performance the proxy
implementation introduces
. All
security

elements described in
Section
2

have been
developed
and integrated

in the current ENS
v
2

release.

Section
3

is devoted to the description of the OKKAM access control model and its
realization.
The section

presents
the semantic access control model
, its semantic policy

specification
,

and how the sem
antic model is integrated with the
trust negotiation approach as
part

of the proxy concept realization.
A semantic schema approach

is introduced as a scalable
way of enabling the semantic access control model to the open schema approach of
entities’
descri
ption in
the
ENS
.

The final contribution of the OKKAM project is the release of ENS v3. Section
4

describes
the main elements considered for advancing security and

trust solution towards ENS v3 release.

Those

new elements
are
part of the ENS security roadmap for

ENS
v
3

release
.

Section

5

describes
some

supporting security aspects that have practical implication on future

ENS evolution
, beyond project lifetime
.

One of the

components
, the

entity evolution lists
,

ha
s

been
developed by the time being
and will be included as optional elements to the ENS offi
cial
release.

Section
6

concludes the document with an overview of its core contribution
.


There are
six

appendixes enclosed to the deliverable
presenting addition
al information to the
core document text, which has been considered important
for completeness of the document
.

Appendix A
presents a summary of the

response to
Y2 review comments regarding the ENS
security solution.
The formal response has been added as an appendix to deliverable
D5.6
.
The
appendix presents

that the designed ENS security is not more complex than
single sign
-
on
approaches

in terms of functionality, underlying interactions and cryptographic operations
.
It
also presents

why SSO solutions do not (naturally) fit to the needs of ENS
.

Appendix
B

presents background information on public key infrastructure and related to that
certificate management concepts and terminology
. It then

overviews related wo
rk on ac
cess
control approaches,
trust negotiation systems,

and Web Services security standards adopted for
securing
access to the ENS.

Appendix
C

shows the roadmap of ENS security features.

Appendix
D

shows in a structured way all ENS security requirements identi
fied with
description of their implication and legal aspects.

Appendix
E

shows the entity evolution lists structure and APIs for
convenience partners when
deploying this component.

Appendix
F

presents the OKKAM user data privacy policy. Th
e

user data privacy policy is
officially referenced at the ENS community portal
3
.

It
has

an important
role

for

ENS v2 release.





3

http://community.okkam.org


D2.1



Trust, Security
and Privacy Approaches for Reliable Entity Management


© OKKAM Consortium
-

FP7
-
IST
-
215032

Version

2
.
0


Page
11

of
112


2.

Security and Trust Infrastructure

This section describes the core and most important elements used for building secure and
truste
d OKKAM community
interactions
, as of ENS v2 onwards
.

There are
three

main design
goals worth mentioning at the beginning:



Defining

a

“backbone” of secur
e

and trust
ed

communications
with

ENS so that any evolution
of ENS
, and future decision making,

is

seamlessly supported without
requiring a redesign of
the

security infrastructure.

This
n
ecess
ity is underlined by a general OKKAM

design goal of

making
the ENS

flexible and easy to evolve.



A
dopt
ing

as much as possible
widely used

and well
-
defined security

and trust standards
as
building components of the security infrastructure
. Thus, maintaining
important

balance
between targeting the best possible solution
s, even

beyond state
-
of
-
the
-
art,
which
requir
e

a
bigger
deployment
effort
, and achieving interoperab
le standards
-
based communications with
the ENS.



Making
the usage of
security and trust solutions as transparent as possible to application
developers, ENS developers, and end
-
users.

2.1.

ENS Architecture

The

architecture of t
he ENS
has undergone a major evolution
from v1.1 to v2.
Figure
1

shows
the ENS as
(a)
a multi
-
core cluster view and

(b)

interaction of ENS with external application as
a
sing
le
-
core view.
The
ENS

Core cluster aims at providing high
-
level processing of
the core ENS
services by replicating ENS core functionalities on multiple machines (in a local area network)
all sitting behind a load balancer.

An application perspective is
that an application communicates with the cluster as it were
communicating with a single
-
server machine (
Figure
1
b). An important factor (and architectural
decision) h
ere is that the load balancer does session
-
less dispatching to any of the cores behind.
This decision ensures availability and scalability of the ENS services, and, at the same time,
poses an important requirement for the design of an access control model.

A single core behind the load balancer has a set of Web Services APIs used by external
applications to access the ENS.

There is an explicit layer in the

single
-
core
view
architecture,
called Access Manager, which is responsible for proper
dispatching of
f
unction calls

(behind the
APIs) and internal

messages from one layer of the core to another. We refer the reader to [
22
] for
details of the ENS architecture and description of its internal components.

The important aspect here is that security and trust so
lutions have been placed at the level of
the Access Manager, as the main layer where all communications external and internal between
different layers are processed.



D2.1



Trust, Security
and Privacy Approaches for Reliable Entity Management


© OKKAM Consortium
-

FP7
-
IST
-
215032

Version

2
.
0


Page
12

of
112




a) Multi
-
core Cluster View

b) Single
-
core
Interactions

Figure
1
. ENS Architecture

[22]

2.2.

OKKAM
Security

and Trust

Infrastructure

Security and trust aspects
of the

OKKAM
infrastructure
are focused on controlling access to
information stored on the ENS. The security architecture is based on
advanced use of certificate
technologies with a strategic goal of fostering the creation of a wide community of users, by
providing them with the full benefits of certificate technologies, such as capability of
establishing trusted and secure communication
s with ENS services, confidential communications
between end
-
users, between end
-
users and third party ENS service providers, as well as,
document authentication based on digital signatures.


Figure
2

shows a high
-
level view of ENS community interactions. Trust in ENS community is
based on certificate authorities that qualify the ENS, third party service providers and end
-
users
by means of

digital identity and attribute certificates. The ENS is fully compliant with X.509
[12] standard. The architecture allows scalable trust establishment in a distributed environment
by means of common trust
ed OKKAM certificate authorities
. The architecture
enables

the


D2.1



Trust, Security
and Privacy Approaches for Reliable Entity Management


© OKKAM Consortium
-

FP7
-
IST
-
215032

Version

2
.
0


Page
13

of
112


adoption of several widely used security technologies such as https
4
, Web Services security
standards
5
, and secure e
-
mail
6
.


Figure
2
.
OKKAM

Security Infrastructure

Global View


Communications to ENS high
-
performance c
luster (its core APIs) are based on Web Services
technologies. However, securing web services interactions and building a scalable authentication
and access control process is a non
-
trivial task, which involves the usage of several web services
security st
andards and proper synergy of them. In addition, certificate management and advanced
access control decision process to ENS services (given the open nature of ENS community) add
a
nother

layer on top of the complexity
of

communications with

ENS.

To
facilitate users, developers

and third
-
party ENS service providers, the OKKAM project
has adopted the use of a
security proxy

component that abstracts all necessary security
management and technological aspects from application
-
level development. Later bel
ow we
recall the main issues of the proxy component.

End
-
users

in

Figure
2

form those community users that use lightweight means to interact and
use
the
ENS services,

for example usin
g a dedicated ENS Web
-
front end

toolkit
7
.

2.3.

OKKAM

Certificate
Management


Figure
3

shows the public key and privilege management infrastructure (PKI/PMI) model

designed and deployed for the OKKAM community. Appendix B presents background on basic

PKI/PMI concepts.

The OKKAM

Global Root CA is the authority trust starts from. It can be seen as the

representative of the project consortium. The root is the most sensitive authority, which sets

up
trust in OKKAM infrastructure and in OKKAM community. In order to reduce the risk of




4

Secure HTTP communications
on SSL/TLS standard
.

5

WS
-
Security, WS
-
Tr
ust etc. at http://www.oasis
-
open.org/specs

6

OpenPGP
-
compliant e
-
mail security http://tools.ietf.org/html/rfc4880

7

ENS Web Front
-
end Toolkit at http://api.okkam.org


D2.1



Trust, Security
and Privacy Approaches for Reliable Entity Management


© OKKAM Consortium
-

FP7
-
IST
-
215032

Version

2
.
0


Page
14

of
112


compromising the global root and for the sake of better management, the OKKAM Global Root

CA delegates to a subordinate CA, called OKKAM CA Class 2, the responsibility to certify all

users and entities of the OKKAM community.


Figure
3
. OKKAM Certificate Infrastructure

In addition, the OKKAM Global Root CA has been defined with two more responsibilities:

(i)
certifying ENS nodes by means of identity and attribute certificates such as ENS Public

and ENS
private nodes
15
, and (ii)
certifying/promoting ENS Public managers. The former case

allows the
OKKAM consortium to keep control on what ENS systems are legally certified as ENS

systems
so that any third party can verify if it trusts that node as being part of the OKKAM

infrastructu
re.
When the OKKAM Root CA certifies a private ENS node this means that the

private ENS node
is part of the OKKAM community.

ENS public managers certified by the OKKAM Global Root CA represent the OKKAM
consortium
. The goal is to allow the OKKAM consortium

delegate responsibility of managing

the ENS to dedicated people. ENS public managers are the principle entities that can

approve
(delegate specific responsibility) to other key entities (such as who administrators of

ENS are,
who trusted entity creators a
re etc.) for the sake of well
-
being of the ENS.

All certificate management aspects have been provided as dedicated ENS APIs and accessed

via the security proxy administration GUI. The goal of
above certificate management of
responsibilities

is to better sc
ale to the expected ENS community expansion of users. The
certificate

model supports both short
-
live security tokens (for hours or days validity) and long
-
lived security tokens (for years validity) depending on specific conditions.






D2.1



Trust, Security
and Privacy Approaches for Reliable Entity Management


© OKKAM Consortium
-

FP7
-
IST
-
215032

Version

2
.
0


Page
15

of
112


The t
able
below

summ
arizes the permissions for each of the attributes.


Certified Attribute Name

Permissions on the

ENS

ENS Public Manager



High
-
level permissions on certificate management.



No permissions on entity creation, update, and life
-
cycle
operations

ENS Public
Administrator



Limited permissions on certificate management.



High
-
level permissions on entity creation, update, and life
-
cycle operations (such as merge, split, delete ENS entities)
including permissions on behalf of end
-
users.

ENS Public Trusted Entity C
reator



Permissions on create new ENS entities on behalf of end
-
users.



Permissions on update ENS entities on behalf of end
-
users.

ENS Registered User



Permissions on create new ENS entities.



Permissions on update ENS entities by append new attributes
only.


An interesting aspect of the ENS Public Manager attribute is that it has no permissions

allowed on entity creation and life cycle management. The main reason is to separate the

responsibility of this attribute from the other attributes (especially from t
he administrator
privileges),

that is, only permissions on certificate management. However, a public manager can

self
-
promote himself to become ENS administrator and thus obtaining the high
-
level permissions

on ENS operations. In this case, the access cont
rol policy will force him to use only one of

the
attributes at a
time, which

is forcing a separation of duty constraint on the presence of those

attributes.

To face scalability and flexibility when OKKAM communit
y grows enough, a user promoted
as ENS
administrator is given the right to promote registered users of being ENS trusted entity

creators.

Another interesting aspect is that of enabling feasible and scalable acc
ess to ENS by other
domains (organizations) with own PKI models and certifiable attri
butes by means of semantic

i
nteroperability of certificates,
as will be discussed in

Section
5.2
.

User registration
.
User registration is not required for some of t
he ENS services, such as all
query
-
based services. User registration is mandatory for creation, modification and life cycle
management of ENS entities.

Users register via an OKKAM front
-
e
nd
8

for obtaining a public
-
key

certificate (PKC) of
being legal OKKAM

users. Once registered, the users can be promoted to

take higher level of
permissions on ENS via the certificate management process above.

Upon registration, a user obtains its registration data in a single file encrypted with the
passw
ord
the user
specified during registration. The registration file strictly conforms to
PKCS12
9

standard. The registration data (file) contains comprehensive data structure enabling
end
-
users

to establish trust with other registered OKKAM entities. It has the following
(informally presented)

data elements:





8

http://register.okkam.org

9

Personal Information Exchange Syntax Standard: http://www.r
sa.com/rsalabs/node.asp?id=2138


D2.1



Trust, Security
and Privacy Approaches for Reliable Entity Management


© OKKAM Consortium
-

FP7
-
IST
-
215032

Version

2
.
0


Page
16

of
112


{
User private key, User PKC, OKKAM CA Class 2 PKC, OKKAM Global Root CA PKC
}


We refer the reader to Appendix F for details of OKKAM user data privacy policy where one
can find a comprehensive description of what user registration data is stored at the ENS, how the
ENS maintains that information, and what information the ENS logs on

each user interaction
with the ENS.

OKKAM project collects and retains the least amount of personally identifiable information.
A user is identified by its distinguished name, which is the composition of the following personal
information: First name/s,
Last name/s, Country of residence, Organization of current
employment, and E
-
mail address.

User registration requires also a username and a password.
N
ote that in contrast with classical
username
-
password systems, the username in OKKAM is only for conveni
ence of users when
using their registration data, and it has neither a special role in OKKAM nor it has to be unique.
Similarly, the password in OKKAM is used only at users' side to protect user registration data.
The ENS
does not

store users' passwords. T
he e
-
mail field is a mandatory part, used as a unique
identifier to avoid registration of duplicate records, and it provides the only means OKKAM
communicate with a user.

Attribute certification
. Obtaining any attribute certificate is a
non
-
automated proce
ss
involving
an approval by either an ENS public administrator or an ENS public manager. An
OKKAM

registered user contacts any of the
above
entities to get an approval by sending its
public
-
key certificate.

Upon approval, the administrator or the manager
uses the security proxy (its GUI) to get

authorized access to ENS certificate management APIs for user attribute certification. The ENS

in turn e
-
mails the user its new attribute certificate.

2.3.1.

Certificate R
evocation

Certificate revocation provides a means b
y which if
a user’s
private key
for

a given public
-
key cert
ificate is compromised then the user
is able to
inform of that to the CA

issued

the public
-
key certificate.
As a consequence, a
ny certificate verification party has to check if a user’s
presented
certificate has been revoked or not. We note that there could be several cases when a
certificate is to be revoked,
for

example,

if a user misbehaves with the ENS then an administrator
of the ENS
could

revoke user’s registration certificate making him unab
le to
further
use the
ENS.

Certificate revocation service facilitates
provision of revocation

and certification revocation
status service for supporting trusted third
-
party communications. The certificate revocation
services
are

made available

as
ENS
v3 release.

C
ertificate revocation
is

based on certificate revocation lists
10

(CRLs). CRLs
are

maintained
within the ENS cluster by means of persistent storage functionality of unified data storage and
retrieval within a cluster.

There are two certificate
revocation lists maintained by OKKAM.
Below we list the two URLs of those:



http://api.okkam.org/okkam
-
core/crl/
okkamall.crl



http://api.okkam.org/okkam
-
core/crl/
okkamauthorities.crl

The first CRL regards revocation certificates of all OKKAM entities


b
oth end users and
OKKAM authorities, while the second CRL regards revocation certificates of OKKAM



10

http://tools.ietf.org/html/rfc3280


D2.1



Trust, Security
and Privacy Approaches for Reliable Entity Management


© OKKAM Consortium
-

FP7
-
IST
-
215032

Version

2
.
0


Page
17

of
112


authorities only. The okkamall.crl is to be used by entities requiring validation of end
-
users such
as the ENS servers, the administration console and the EN
S web toolkit, while the
okkamauthorities.crl is to be used primarily by end
-
users when interacting with OKKAM front
-
ends or with the ENS.

The

okkamauthorities.crl is a subset of
the
okkamall.crl. Furthermore, okkamauthorities.crl is
expected to have dras
tically fewer revocation certificate entries with regards to the okkamall.crl,
as well as, having much less frequency of certificate revocation. The motivation for having
okkamauthorities.crl is to facilitate end
-
users (the most delicate use case) of effic
ient check for
certificate revocation status when interacting with the ENS and with the ENS front
-
ends.

End users should install okkamauthorities.crl into their web browsers, email clients etc.
OKKAM front
-
ends should install okkamall.crl into the applica
tion server when configuring to
accept end
-
users certificates. OKKAM security proxy is configured to use
a

dedicated ENS API
isCertificateRevoked(…) when interacting with the ENS.

T
he isCertificateRevoked(…) WS API provides the most up
-
to
-
date response (“f
reshness”) of
certificate revocation status compared to the CRL approach. The WS API is not an OCSP
11

responder

for remote verification
but it is provided to serve the security proxy functionality. The
WS API approach is not based on any underlying CRL data

but uses directly the persistent
storage data (where each revoked certificate has a single entry in the persistent storage).
However, there are several cases where locally cached CRLs have more benefits rather than
being constantly online connected to ENS

for certificate status check. For example, the OKKAM
front
-
ends use okkamall.crl when accepting HTTPS connections with end
-
user authentication.

Both CRLs above have been set to automatic update once
per

week, which gives reasonable
freshness of certificat
e revocation status.

A dedicated GUI of the security proxy facilitates
m
anagement of CRLs in OKKAM
. Access
to the respective APIs of certificate revocation is controlled access
for

administrators or ENS
managers.

We refer to the OKKAM community portal
documentation

s
ection for detailed
information of how to use
security
proxy GUI.

2.4.

Proxy
-
based Security
Design and Implementation

Facilitating secure and trusted interactions with ENS, it has been designed and developed
security proxy component on both, clie
nt
-
side and service
-
side. The main goal behind the proxy
design is to hide complexity and facilitate management of security technologies to OKKAM
users, application developers, as well as, to ENS core development itself.

Access to ENS APIs requires Web ser
vices technologies. There are well
-
defined security
standards for Web services that facilitate establishing secure and trusted interactions between
entities. The most relevant WS standards used for establishing secure and confidential
connections to ENS ar
e discussed later in the section.

Figure
4

shows the security proxy approach deployed in the ENS. All messages to and from
the ENS are communicated via the proxy components.

Another main goal behind the proxy design is to make
secure communications as transparent
as possible to OKKAM
-
enabled applications, as well as, provide necessary authentication and
access control mechanisms.




11

O
nline certificate status protocol

(
http://tools.ietf.org/html/rfc2560
)


D2.1



Trust, Security
and Privacy Approaches for Reliable Entity Management


© OKKAM Consortium
-

FP7
-
IST
-
215032

Version

2
.
0


Page
18

of
112



Figure
4
. Client
-
Server Model of Security Proxy

To achieve transparent an
d intuitive interactions with ENS it has been designed that the proxy
component implements all remote ENS APIs as they were locally deployed. Thus the proxy
component becomes as local replica of ENS APIs with respect to user
-
side applications.

Another main

achievement of the proxy is encapsulation of authentication and access control
mechanism for accessing ENS APIs. The main goal here remains the same


achieving as much
transparent as possible authentication and access control process to OKKAM
-
enabled
app
lications. The access control model deployed inside the proxy component is discussed in a
later section.

Technically, the proxy approach provides confidential channel between the user
-
side proxy
and the server
-
side proxy components. The confidential chann
el is established with a mutual
certificate security mechanism that uses both, client and server
-
side public
-
key (identity)
certificates to establish confidential communication channel between the client
-
side and server
-
side proxies.

A confidential channe
l is established if a user is a registered OKKAM user, i.e. a legitimate
OKKAM user. It is noticeable that the user
-
side proxy component works always on behalf of a
user, i.e. the proxy authorizes to ENS as being the user itself.

Once mutual authentication and a confidential channel are established, there is a mandatory
access control process that controls if a registered user is allowed to access requested ENS APIs.
The server
-
side proxy and a client
-
side proxy automatically negot
iate if more access rights are
necessary and present the necessary credentials (certified attributes).
S
ection

3

presents

in details
the negotiation concept and the

access control model.


D2.1



Trust, Security
and Privacy Approaches for Reliable Entity Management


© OKKAM Consortium
-

FP7
-
IST
-
215032

Version

2
.
0


Page
19

of
112


2.4.1.

Secured Access to Protected ENS APIs

The OKKAM consortium has decided to provide ENS functionalities as both REST
-
style web
services interfaces, and as SOAP and WSDL based web services. Public non
-
protected services
of ENS are expose
d as both REST
-
style and WSDL
-
based web services interfaces. All services
that have been defined as protected (controlled access) are accessible only by standard Web
Services technologies, i.e. by using SOAP protocol and WSDL.

Security of OKKAM considers
exclusively access to ENS services provided as standard Web
Services technologies. Access to ENS services provided as REST web services is beyond the
security scope of OKKAM. The REST services are provided to facilitate ENS usage in mashup
applications. As

said above, all REST services are public non
-
protected services that have
equivalent service functionality provided via standard Web Services interfaces.

The ENS provides all functionalities via Web Services APIs divided in two sets:
Public WS
APIs
12

and
P
rotected WS API
13
. The public APIs are available for public access by standard web
services means. The set of public APIs contains those APIs available for open and uncontrolled
access (e.g., all query
-
related APIs fall in this category).

All ENS APIs are m
ade publicly accessible but those of them that require protected access
have no functional “body” but instead always return an authorization exception with a message
“Unauthorized public access”. The reason to leave all ENS APIs public accessible is that a
ny
developer should use the public APIs to know what functionalities ENS provides and what
interface the developer has to conform to in order to use core ENS services and what input
message structure an API accepts.

The protected APIs require secure and co
nfidential communications with appropriate access
rights for their execution. An important security aspect here is that all public APIs are also
provided as protected APIs (with no controlled access but accessible over a secure
communication channel). In t
hat way, a user can enforce privacy and confidentiality on all
interactions with the ENS APIs including the non
-
protected APIs. For example, when a user
wants to avoid any intermediary third parties reading what he queries ENS for (or what he
interacts wit
h ENS for).

All interactions with protected ENS APIs are to be performed via the security proxy.
Figure
5

shows the API
-
level message flow of proxy
-
based communications. Applications can establish
direct communications or indirect via

proxy communications with the public APIs. The proxy
component replicates all ENS APIs, both public and protected ones, as locally accessible to
applications in order to make access to those API as much transparent as possible by application
developers.

T
he goal is to provide developers with uniform access management allowing all APIs to be
accessed via the proxy component without keeping in mind which of those require protected
access and which do not. The proxy component is aware of which APIs are protec
ted and for
those of no required protection the proxy just dispatches the respective requests/responses to the
public ENS APIs as shown in the figure.





12

http://api.okkam.org/okkam
-
core/WebServices?wsdl

13

http://api.okkam.org/okkam
-
core/WebServicesSecured?wsdl


D2.1



Trust, Security
and Privacy Approaches for Reliable Entity Management


© OKKAM Consortium
-

FP7
-
IST
-
215032

Version

2
.
0


Page
20

of
112



Figure
5
.
API
-
level Proxy
-
based Communications

If the proxy is configured to
enforce secure communications for all interactions to the ENS,
then it will dispatch all APIs invocations to the protected APIs. In that case, even if a non
-
protected API is locally invoked, the proxy will dispatch the request to the protected version of
t
his API at the ENS side.

The proxy component has two main usage modes: as a local host service and as a library. The
local host service implements the same WS APIs (interfaces only) but acce
ssible on local host
connection
14
. This is an important mode addres
sing the needs of so
-
called ”thin” applications,
such as plug
-
ins for third party applications, or applications that cannot use the proxy as a java
library, such as non
-
java based applications. In such case, an application invokes the WS APIs
on localhost
for accessing the remote WS APIs. The library usage, in contrast, provides the
respective ENS APIs as java APIs signatures for accessing the remote WS APIs, as described
later.

We list below the set of public APIs provided by ENS

(their Java signatures)
.
We omit the
input and output messages of APIs for the sake of simplicity of presentation. We mark in bold
those APIs that require protected APIs access.

Complete description of ENS WS APIs can be
found in
deliverable D5.7.

Public APIs

getEntity(...) throw
s OkkamCoreException

findEntity(...) throws OkkamCoreException

getAlternativeIds(...) throws OkkamCoreException

getOidsByAlternativeId(...) throws OkkamCoreException

getEntities(...) throws OkkamCoreException

getTypeTemplate(
...
) throws
OkkamCoreException

logSelectedEntity(...) throws RemoteException

lockEntity
(
...
) throws
OkkamAuthorizationException
, OkkamCoreException

lockEntities
(
...
) throws
OkkamAuthorizationException
, OkkamCoreException

unlockEntity
(
...
) throws
OkkamAuthorizationException
, OkkamCoreException




14

The proxy component is not necessarily to be run on a localhost but could also be run on a separate
machine with intranet access. However, in this case one needs to additionally secure access between the
application and the proxy.


D2.1



Trust, Security
and Privacy Approaches for Reliable Entity Management


© OKKAM Consortium
-

FP7
-
IST
-
215032

Version

2
.
0


Page
21

of
112


validateEntity
(
...
) throws
OkkamAuthorizationException
, OkkamCoreException

createNewEntity
(
...
) throws
OkkamAuthorizationException
, OkkamCoreException

deleteEntity
(
...
) throws
OkkamAuthorizationException
,
OkkamCoreException

mergeEntities
(
...
) throws
OkkamAuthorizationException
, OkkamCoreException

splitEntity
(
...
) throws
OkkamAuthorizationException
, OkkamCoreException

updateEntity
(
...
) throws
OkkamAuthorizationException
, OkkamCoreException

Below we list
the set of APIs available as protected APIs. We note that some of the protected
APIs are not in the public space of ENS APIs due to their specific to OKKAM needs, for
example, those APIs dedicated to be used by the ENS web toolkit and administration consol
e
front
-
end applications on behalf of users.

In the set of protected APIs there are also all APIs from the public space, which do not require
protected access. The decision of doing so is motivated by the need of privacy control of users
when interact with

the ENS. In that way, by configuring the security proxy, end users can
achieve complete security and privacy of their interactions with the ENS where the proxy will
tunnel all calls to the respective APIs in the set of protected services (named below as n
on
-
protected APIs for secure access).

Protected Access APIs

Access Control Requirements

lockEntity
(...) throws

OkkamAuthorizationException, OkkamCoreException

Administrator or trusted entity
creator privileged access.

lockEntities
(...) throws
OkkamAuthorizationException, OkkamCoreException

Administrator or trusted entity
creator privileged access.

unlockEntity
(...) throws
OkkamAuthorizationException, OkkamCoreException

Administrator or trusted entity
creator privileged access.

validateEntity
(...) throws
OkkamAuthorizationException, OkkamCoreException

OKKAM user or administrator or
trusted entity creator privileged
access.

createNewEntity
(String certificate) throws
OkkamAuthorizationException, OkkamCoreException

OKKAM user or administrator
pr
ivileged access.

deleteEntity
(String oid, String ticket) throws
OkkamAuthorizationException, OkkamCoreException

Administrator privileged access.

mergeEntities
(String[] oids, String
mergedEntity, String[] tickets) throws
OkkamAuthorizationException, Okkam
CoreException

Administrator privileged access.

splitEntity
(String oid, String[] splitEntities,
String ticket) throws
OkkamAuthorizationException, OkkamCoreException

Administrator privileged access.

updateEntity
(String ticket, String certificate)
throws
OkkamAuthorizationException,
OkkamCoreException

Administrator privileged access.

OnBehalf APIs

createNewEntityOnBehalf

(String certificate,
byte[] x509UserCert
) throws
OkkamAuthorizationException, OkkamCoreException

Administrator or trusted entity
creator privileged access.


D2.1



Trust, Security
and Privacy Approaches for Reliable Entity Management


© OKKAM Consortium
-

FP7
-
IST
-
215032

Version

2
.
0


Page
22

of
112


updateEntityOnBehalf

(String ticket, String
certificate,
byte[] x509UserCert
) throws
OkkamAuthorizationException, OkkamCoreException

Administrator or trusted entity
creator privileged access.

deleteEntityOnBehalf

(String oid, S
tring
ticket,
byte[] x509UserCert
) throws
OkkamAuthorizationException, OkkamCoreException

Administrator privileged access.

mergeEntitiesOnBehalf

(String[] oids, String
mergedEntity, String[] tickets,
byte[]
x509UserCert
)

throws
OkkamAuthorizationException, OkkamCoreException

Administrator privileged access.

splitEntityOnBehalf

(String oid, String[]
splitEntities, String ticket,
byte[]
x509UserCert
)

throws
OkkamAuthorizationException, OkkamCoreException

Administrator privileged a
ccess.

Non
-
protected APIs for secure access

getEntity(...) throws OkkamCoreException

Anonymous or OKKAM user

findEntity(...) throws OkkamCoreException

Anonymous or OKKAM user

getAlternativeIds(...) throws OkkamCoreException

Anonymous or OKKAM user

getOidsByAlternativeId(...) throws
OkkamCoreException

Anonymous or OKKAM user

getEntities(...) throws OkkamCoreException

Anonymous or OKKAM user

getTypeTemplate(
...
) throws OkkamCoreException

Anonymous or OKKAM user

logSelectedEntity(...) throws RemoteE
xception

Anonymous or OKKAM user

Important to
note

is the difference of on behalf functions from legal point of view. Those
functions logs internally the authors of the respective act of execution of those functions the end
-
user specified in the input par
ameter, and not the entity authorized to access those functions. For
example, upon execution of createNewEntityOnBehalf(…) by the ENS web toolkit, the security
module will log the following information: “An entity creator ID was authorized to execute
creat
eNewEntityOnBehalf function where the author of the entity creation act is the end user
ID”. Here the IDs are the identity of ENS web toolkit and end
-
user as described in the entity’s
X.509 public
-
key certificate.

Another important issue is that all on
behalf functions accept as input the same input
parameters as their corresponding functions but require one more argument


the public
-
key
certificate of the end
-
user wishing to execute those functions.

At this point, the security module does not consider
any delegation aspects that the end
-
user
does aim at accessing those functions via a front
-
end. The motivation is that the only entities
currently allowed to access those APIs are trusted to ENS (namely, administrators or trusted
entity creators).

The crea
teNewEntityOnBehalf(…) and updateEntityOnBehalf(…) are provided to serve the
purposes of the ENS web toolkit (entity creator), while delete, merge and split on behalf APIs
are designed to serve only the purposes of the administration console front
-
end. In

this way, we
achieve separation of responsibilities of both front
-
ends.


D2.1



Trust, Security
and Privacy Approaches for Reliable Entity Management


© OKKAM Consortium
-

FP7
-
IST
-
215032

Version

2
.
0


Page
23

of
112


2.4.2.

Security
-
specific APIs

In addition to the ENS APIs of functional aspects, there are APIs dedicated to security needs
only. Those APIs are dedicated to be used by the OKKAM security pr
oxy, but not exclusively.
Below we list those APIs.

Security
-
specific APIs

Functional Description/Access Control
(AC) Requirements

Public APIs:

public byte[]
getServerCertificate
()

Returns the public
-
key certificate of ENS
(replica) server.

public boolean
isCertificateRevoked
(
BigInteger serialNumber) throws
OkkamCoreException

Returns true if the certificate serial number
exists in the underlying certificate
revocation lists. Returns false otherwise.
This method is provided for most accuracy
of revocation status.

Protected Access APIs:

public byte[]
registerUser
(String
firstName, String lastName, String
username, String password, String email,
String organization, String country,
boolean storeUserPrivateKey)

throws RemoteException,
OkkamAuthorizationException

Registers user into the ENS persistent
storage. Returns a keystore file, in PKCS12
format, encrypted with the password of
registration.

Access to this API is given to any
application implementing WS
-
Security with
anonymous user
-
side certificate. For
example, user registration via the security
proxy GUI, where the security proxy
generates anonymous public
-
key certificate
for accessing the API over a security
channel (formed by following mutual
certificate security mechanism using

a
trusted server certificate and the anonymous
client certificate).

AC: Anonymous access

public void
removeRegisteredUser
(String
email) throws RemoteException,
OkkamAuthorizationException

Privileged removal of user data from the
ENS. Before removing user profile, this
function
first
revokes

all user’s associated
ce牴楦楣a瑥猠 a湤n 瑨e渠 牥浯癥猠 瑨攠 畳er
灲潦楬e⁦ 潭⁴桥⁰e牳楳ren琠獴潲o来K

䅃A⁁摭楮 獴牡瑯爠灲楶ile来搠dcce獳s