Escolar Documentos
Profissional Documentos
Cultura Documentos
(2013) 12:173200
DOI 10.1007/s10207-012-0189-y
REGULAR CONTRIBUTION
1 Introduction
In recent years, identity management aspects, such as enduser authentication and authorization, have been addressed
by several initiatives. In these approaches, trust links are
established among different service providers and identity
providers, in order to grant end users access to resources
or services, with a single identity. Widely recognized examG. Dlera Tormo (B)
Security Group, NEC Laboratories Europe,
69115 Heidelberg, Germany
e-mail: gines.dolera@neclab.eu
G. Lpez Milln G. Martnez Prez
Department of Information and Communications Engineering,
University of Murcia, 30071 Murcia, Spain
123
174
123
2 Requirements
Organizations belonging to identity federated environments
are starting to demand a finer user access control. At the same
time, end users are starting to request added-value services.
We have defined a set of desirable features of any identity
management system both taking into account basic features
found in the literature [11,33,52,53] and considering ongoing systems demands. From those features, a list of requirements that any advanced identity management system should
fulfill has been obtained. Since this document is focused on
advanced identity management systems, we leave other basic
requirements out of the enumeration, such as database or credential management, although they can be easily found in the
literature. In order to present such requirements, we have cataloged them in four general topics.
2.1 Security related requirements
Confidentiality, integrity: Any system that makes use
of sensitive information must assure that information is
shared only between authorized entities; in addition, it
must assure that the information is valid and complete.
In this way, an identity management system has to use
secure communications channels, in order to guarantee
data confidentiality and integrity.
Logging and auditing: When something unexpected happens, the lack of logs can result in significant difficulties
in dealing with the failure. Additionally, providing logging and auditing can act to discourage attackers who are
concerned that their attack will be detected or that they
will leave a trail which can be tracked back to them [43].
Identity management systems must incorporate an effective logging and auditing mechanism able to trace the
relevant events happened in the system. This mechanism
should guarantee that an end user or an entity cannot deny
performing an operation or initiating a transaction. To
achieve this, the identity management systems may trace
sent and received messages and internal operations.
End-user privacy for service access: An identity management system should be designed in such a way that
the information revealed to the service provider is just
that necessary to perform the authorization process. The
system must ensure that the end-user identity is just
known by her identity provider, guaranteeing end-user
privacy. Therefore, the identity management systems
should deploy mechanisms for hiding users identities,
for instance making use of pseudonyms to represent the
principal [25,44].
Integration with certification and validation services:
Identity management systems make use of digital certificates to establish trust relationship between different
components. For example, digitally signing communica-
tion messages or validating HTTPS/SSL [49] connections. These relationships can be managed by a trust
management infrastructure, which is normally used for
validating digital certificates. In this way, integration with
certification services, as is suggested by [19], simplifies management and communication with these trust
infrastructures. It is desirable for an identity management
system to be integrated with this kind of services, for
instance implementing XKMS [20], in order to simplify
certificate validation and revocation information.
Advanced services support: Current implementations
of authentication and authorization systems are mostly
focused on protecting basic web services. Nevertheless,
they should extend their capabilities in order to help
their integration in other application environments, like
Grid [28], WS-* [29,31], or even network services [32].
Identity management systems should be easily extendible
to support different kind of technologies.
Based on standards: As advanced in the previous item,
each identity management system requires to define different data structures and to make use of diverse communication protocols. For instance, it is necessary to
establish structures for defining policies or protocols
for exchanging information between providers. With the
objective of facilitating integration with current services,
it is desirable that, as much as possible, the identity management systems are based on standards such as SAML,
XACML or X509. This requirement not only ease the
adoption of the system, but also enables the integration
with future services being, therefore, easily extended to
support ongoing functionalities.
2.2 Authentication requirements
Strong authentication: Using strong authentication provides more protection for sensitive information than
mechanisms based on shared secrets, such as usernamepassword mechanisms. Supporting strong authentication
mechanisms, such as biometric techniques [61] or digital
certificates with its associated trust infrastructure, such
as PKI [1] helps to avoid impersonation or identity theft.
Advanced identity management systems must allow the
use of strong authentication mechanisms.
Level of assurance: Since there are different kinds of
authentication mechanisms, the service providers should
be able to know how much they can trust in an authentication assertion that an end user presents. In order to
achieve that, levels of identity authentication assurance
have been described [7]. It is desirable that the level of
assurance of processes and mechanisms, used for identity
validation and authentication, can be defined by the service providers, according to the assessment of the risks
and sensitivity of the offered services. On the other side,
175
123
176
3 Related work
This section starts by describing some widely used identity management systems, which deploy authentication and
authorization capabilities. We briefly analyze how they meet
the presented requirements. Finally, a comparative table has
been added in order to summarize differences and limitations
of each described system.
Shibboleth [17] is an initiative of Internet2 developed with
the aim of sharing resources between research groups. Shibboleth defines a Service Provider and an Identity Provider,
so when an end user tries to gain access to a resource in the
Service Provider she is redirected to the Identity Provider
of the organization where she belongs to, in order to get an
authentication assertion. As it is based on basic web access,
that is, HTTP, it does not offer support for advanced web
services. Additionally, the Shibboleth Service Provider is
not able to specify how the authentication must be done,
so each organization can use the authentication mechanism
it desires. Nenadic et al. [37] describes how to provide Level
of Assurance capabilities to Shibboleth; however, the current implementation does not really achieve it. Furthermore,
123
177
123
123
Yes
Yes
Yes
Yes
Yes
Liberty
Alliance
PAPI
OpenID
PERMIS
Yes
Yes
Yes
Yes
Logging
and
auditing
Shibboleth Yes
Confident
and
integrity
Security related
Yes,
unlinking
real name
with DN
No
Yes
Yes, but
implementation
dependent
in some
cases
Yes
End-user
privacy
for service
access
No
No
No
Yes
No
Yes
No
No
No
No
Integration Advanced
with certifi- services
support
cation and
validation
services
Partially
Yes
Partially
Yes
Partially
Based on
standards
No
Implementation
dependent
Yes, through
P.K. certificates
Implementation
dependent
Through
external
modules
Strong
authent.
Authentication
Yes, although
anyone can
become a
OpenID
provider
Only if it
is supported
by
Identity
Provider
No
Yes
No
Level of
assurance
Yes
Yes
No
No
No
Implementation
dependent
No
Yes
Yes
Administration
Provides
tools for
some
aspects, but
for others,
it is
necessary
to use
external
tools
Yes
No
No, configuration
with XML
files
Implementation
dependent
Advanced
Permission Integrated
attributedelegation user-friendly
based authoadmin.
rization
No, although No
it has
modules
which allow
to ask an
external
service
No
No
Yes
Yes
Single
Sign-On
Authorization
No
Yes
Not in
ID-IF. In
ID-WSF
user is
asked
for
consent,
but she
cannot
define
ARPs
No
Through
external
editors
Privacy
management by
the user
178
G. Dlera Tormo et al.
179
End user
HT
S
TP
HT
MISTRAL
Identity
Provider
Authentication DB
TP
MISTRAL
Service
Provider
SAML
XK
M
S
MS
XK
SAML
SAML
PKI
XK
M
S
XK
o
in C
Adm
A dm
in C
End user
(administrative part)
n so
le
XACML
Attribute Release
Policies
o
ML
SA
User Attribute DB
MISTRAL
MISTRAL
Attribute
MISTRAL
Attribute
Provider
Attribute
Provider
Provider
nso
SAML
MISTRAL
MISTRAL
Authorization
MISTRAL
Authorization
Provider
Authorization
Provider
Provider
XACML
Access Control
Policies
le
XACML
v3
Attribute Delegation
Policies
Since managing end-user attributes and managing authentication are two different processes, we introduce the Attribute
Provider In this way, the Identity Provider is only in charge
of the authentication process, while the Attribute Provider is
in charge of managing end users attributes and controlling
the access to them. Furthermore, some end users could have
their attributes deployed in several Attribute Providers, even
some of them could be outside the domain of the Identity
Provider. For instance, some students could maintain academic attributes in their universities although other personal
attributes, such as age or driver license number, are managed by their city councils. Introducing this element also
allows making distinction between database for authentication and database for attributes. The former stores end-user
credentials, such as passwords or digital certificates; the latter manages end-user information, such as roles, departments
they belong to, or postal addresses. In addition, two supplementary databases are managed by the Attribute Provider in
order to give control to the end users: an attribute release policy database, in order to allow privacy management, and an
attribute delegation policy database, in charge of establishing
delegation capabilities on the fly, as described below.
In the same way, the Service Provider should differentiate between providing services and performing access
control. The access control procedure determines who is
authorized to get each resource, usually performed by a Policy Decision Point (PDP), directly managed by the Service
Provider in conventional solutions. Instead, in the proposed
architecture, we introduce the Authorization Provider, having an element which any Service Provider can delegate
the authorization process. In this sense, the Authorization
Provider could manage access control of different Service
Providers, even it could be located outside the Service
Provider domain. Take, for instance, organizations composed
by different subsidiaries providing services although the
access control decisions are taken by the headquarters. Similarly, the Service Provider could make use of different Authorization Providers to take an access control decision. The
Authorization Provider holds a database where access control
policies will be managed and defined in a standard language,
(XACML), allowing advanced attribute-based authorization.
Therefore, management of authorization aspects does not
entail any change in the Service Provider. Furthermore, introducing this element the Service Provider can include access
control without deploying complex authorization processes.
All the presented elements communicate with each other
making use of SAML 2.0 messages. SAML is used in this
architecture for requesting and responding both authentication, attributes and authorization decision statements. Each
SAML message will be digitally signed by the message issuer
and validated by the recipient, while both sides log these
messages, as the logging and auditing requirement describes.
Complementing this process by making use of secure communications channels, such as SSL/TLS, the confidentiality
and integrity requirement is granted. In order to validate the
signed messages, there should be established a trust rela-
123
180
AC Filter
Manager
End user
AC Filter
Manager
Resource
Resource
MISTRAL
Authentication and
Authorization
Validator
Other
Authentication and
Authorization
Validator
SAML
Encoder/Decoder/
Validator
XKMS Client
Other
Encoder/Decoder
ry/
u
teQ
bu
ttri nse
LA spo
M
e
R
SA
SAMLAuthZDecisionQuery/
Authorization
Response
Provider
SA
M
LA
Re uthN
sp R
o n eq
s e ue
s
t/
Identity
Provider
SAML/Cookie/etc
123
in order to check if an end user has already been authenticated and authorized before supplying the resource. Those
resources have to deploy a filter (Access Control Filter Manager) which intercepts the end user requests before it reaches
the resource and asks the Authentication and Authorization
Validator module if that request is allowed to access that
resource.
The Authentication and Authorization Validator follows
the SAML Web Browser SSO Profile [9], so it checks first
if the end user has been previously authenticated verifying
that she presents a valid authentication statement contained
in a SAML assertion. SAML messages hide end users identifiers making use of pseudonymous, so they meet the enduser privacy requirement. Once authenticated, the Service
Provider asks the Authorization Provider for an access control decision sending an authorization query. Depending on
the Authorization Provider response, the Service Provider
will send an authorization error back, or it provides access to
the resource, and optionally, it performs other actions according to that response.
End-user attributes are needed in order to take access control decisions. Even though the SAML assertion, which contains authentication information, may also contain end-user
attributes, the Service Provider can itself request them to
the Attribute Provider if additional information is needed.
For instance, the Service Provider of a digital library could
request the role of the end user before knowing that she
belongs to a specific university. Since both components
belongs to the same security domain (i.e., they are within
the same trust boundary), the Service Provider could directly
request the Attribute Provider.
As depicted in Fig. 2, MISTRAL is compatible with other
access control mechanisms deployed on the Service Provider,
such as Shibboleth or Liberty Alliance authentication, as
shown in the Compatibility with existing solutions section
below. Furthermore, due to the fact that resources are protected by separated filters, the Service Provider can choose
which resources will be protected by MISTRAL and which
181
Attribute
Provider
XKMS Client
XKMS Client
Web login
interface
XKMS
Service
DB Client API
TPS
SAMLAttributeQuery/
Response
SAML
Encoder/Decoder/
Validator
Credentials
Validator
Authentication
DB
HT
SAMLAuthNRequest/
Response
Authentication
Service
End user
will be protected by other mechanism. By contrast, our architecture is focused not only on protecting simple web services
(i.e., HTML or PHP), but also it allows to protect servlet
resources [50], which can be executed on application containers.
4.2 Identity Provider
The Identity Provider, Fig. 3, performs the authentication
process, asking for and checking end users credentials. If the
end user is successfully authenticated, the Identity Provider
submits an authentication statement, which is required by the
Service Provider, as shown before.
Since there are numerous ways to authenticate end users,
the system should allow the Identity Provider to easily choose
the authentication methods offered to the end users, depending on the strength required. In addition, the mechanism used
must be specified along with the authentication statement in
order to fulfill the Level of Assurance requirement. For example, some Service Providers could assert that they require
users to be authenticated using strong authentication mechanism to avoid impersonation for certain kind of services.
To validate end users credentials, MISTRAL deploys
the Credentials Validator module. That module implements
different validation mechanisms, so it uses different ones
depending on the kind of credentials the end user makes use
of. For instance, if credentials are login and password, the
Credentials Validator will access the Authentication Database (e.g., LDAP server [55]) containing encrypted end-user
login/password information.
This module enables support for strong authentication,
which is a system requirement previously described. The end
user is able to be authenticated through her public key certificate, and the system is able to check it. In order to validate the
certificate, the Credentials Validator uses a XKMS Client. It
asks the PKI services, which store end-user certificates and
manage its associated information, such as revocation status.
Furthermore, making use of this strong authentication
method, based on digital certificates, this architecture avoids
the vulnerability where malicious Service Providers can supplant the Identity Provider, that is, phishing, trying to gain
user-password information [34].
Additionally, regarding the requirements, the Identity
Provider supports Single Sign-On following the SAML Web
Browser SSO Profile [9], complemented with HTTP sessions. The end users could recover authentication assertions
once, and again, once they have submitted their credentials.
This standard also provides privacy, due to authentication
assertions make use of pseudonym, instead of revealing the
real end users identity.
4.3 Attribute Provider
The Attribute Provider, Fig. 4, manipulates private end-user
information, and it is in charge of both managing enduser attributes and providing these attributes only to authorized requesters. This provider follows the SAML Assertion
Query/ Request Profile [9] acting as a SAML Authority.
The Attribute Provider has an Attribute Service module,
which recovers end-user attributes from the User Attribute
Database. That database can be implemented in many ways,
allowing LDAP access or making use of any other database
access technology. It should contain all available end-user
attributes, such as roles, department the end user belongs to,
telephone number, or any other information.
This kind of provider has already been introduced by certain identity management solutions, even though it on occasion belongs to the Identity Provider, or it is supposed to
be implicit in other component. The presented solution is
extended in order to manage end-user privacy as well as
enable advanced functionalities, such as allowing recovering attributes from different sources. The Attribute Policy
Decision Point module is in charge of taking decisions about
releasing attributes, before returning them to the requester.
This module recovers and checks attribute release policies,
following the XACML standard, where each end user specifies the Service Providers, or organizations, that are allowed
to get each attribute [22]. More than that, this module is
123
182
SAML
SAMLAttributeQuery/
Encoder/Decoder/
Response
Validator
Service
Provider
Attribute Service
DB Client API
User Attribute DB
XKMS Client
Attribute Policy
Decision Point
Authorization
Provider
XACML
Evaluator
XACML
Attribute Release
Policies
XACML
v3
Attribute Delegation
Policies
SAMLAttributeQuery/
Response
SAML
Encoder/Decoder/
Validator
Policy Decision
Point
DB Client API
XACML
SAMLAuthZDecisionQuery/
Response
XKMS Client
XACML
Evaluator
Access Control
Policies
Service
Provider
123
which the end user is trying to access (e.g., URL), the actions
over that resource (e.g., read, write), and other environment
variables (e.g., time, network load, etc.).
To this end, it implements a Policy Decision Point (PDP),
and, as well as the Attribute Provider, the Authorization
Provider follows the SAML Assertion Query/ Request Profile acting as a SAML Authority. This profile is complemented
with the XACML Attribute Profile of the SAML specification, which establishes a mapping between both standards.
This way, the Authorization Provider receives authorization
queries, and it takes an access control decision, sending the
statements back containing the decision.
In order to take a decision, the Policy Decision Point has
to analyze access control policies. These policies are defined
following the XACML standard. The PDP has to recover
those policies from the database and check them with its
XACML Evaluator, in order to know if the end user is authorized, according to her attributes.
The evaluation process could require end-user attributes
which have not been recovered in the authentication process.
183
123
184
HTTPS
Administrator
Web
Interface
Admin
Interface
Admin
HTTPS
User
Interface
Authentication
DB
DB Manager
LDAP
API
XML-DB
API
Other
Other
DB API1 ... DB APIn
XACML Encoder
End User
User Attributes
DB
XACML
Attribute Release
Policies
PKI Manager
XACML
Access Control
Policies
PKI
5 Architecture analysis
Once we have described the architecture for identity management, we describe the main processes, showing the interactions between different components, in order to analyze
the system behavior into specific access control scenarios.
123
Service
Provider
End user
185
XKMSService
(PKI)
Identity
Provider
DB Client
API
GetResource(HTTPS)
I require Level X of
Assurance
ValidateAuthN
HTTP Redirect
SAMLAuthnRequest
XKMSValidate
Login Form
Credentials
CheckCredentials
P.K. Certificate Validation
(Optional)
SAMLResponse
GetAuthenticationInfo
HTTP Redirect
ValidateAuthN
XKMSValidate
Authenticated
meeting the Level
X of Assurance
123
186
123
Authorization
Provider
187
Attribute
Service
Attribute
Provider
Attribute Policy
Decision Point
XKMSService
(PKI)
Authorize request
HTTPGet
XKMSValidate
SAMLAttributeQuery
Recover Attributes
Authz fail, needed:
User role + country
GetAttributes
CheckARP
CheckADP
SAMLResponse
XKMSValidate
roles (XACML-RBAC [4]), with the ability to define inheritance relationships between them. The definition of these
policies follows the XACML specifications, falling outside
the scope of this work.
These policies are analyzed by the XACML evaluator,
which takes into account the end-user attributes, the resource,
the actions, and other environment variables. As a result, it
takes the decision whether the end user is allowed or not.
XACML policies allow defining Obligations, which specify
not only if the end user is (or not) allowed but also actions
that should be performed by the Service Provider if some
conditions happens, such as give a specific quality of service
or provide a restricted version of the resource that accomplishes the advanced authorization requirement.
With the result of that decision, a SAMLAuthorizationStatement is generated indicating the decision taken, that is,
permit or deny, and the actions to be performed. The statement is sent back to the Service Provider in a SAMLResponse,
whose signature will be validated. Finally, depending on the
decision, the Service Provider supplies the resource to the
end user, or sends an authorization error back, and performs
the actions proposed by the decision.
5.4 Administration requirements
The administration task in the proposed identity management
solution involves the components management in a unified
way. The administration process can differentiate between
123
188
123
6 Implementation
The solution proposed in this work has been fully implemented as an open-source project named Mistral-IdM [16].
In this section, we describe our experiences deploying the
proposed architecture and the implementation details.
This architecture has been developed making use of Java
Servlet Technology [50]. Therefore, this architecture can
be deployed in application containers, such as Tomcat [5].
Each provider is a servlet to which end users and other
providers send queries, making use of HTTPGet or HTTPPost through HTTPS connections. Between providers connections are used to send SAML messages. In order to create
and manage these messages, the OpenSAML 2 libraries [45]
have been used.
As previously described, this architecture makes use
of XKMS clients to validate trust relationships between
providers. Both the XKMS Client and the XKMS Service are implemented making use of the OpenXKMS
libraries [8] (OpenXKMS-Client-1.1b and OpenXKMSWebService-2.3a), which provide connectors to the PKI in
order to manage certificates. Furthermore, an additional module has been developed in order to connect the XKMS service
with the UMU-PKIv6 [58]. UMU-PKIv6 offers basic certification services, as the issuance, renewal, and revocation of
public key certificates, as well as advanced services like time
stamping or online OCSP-based certificate validation.
The main implementation details of the different modules
are now described.
In the Service Provider, there are two main modules: the
Access Control Filter Manager and the Authentication
and Authorization Validator. The former is in charge of
intercepting end users requests before they get access
to the resources. In order to achieve that, this implementation has developed a Java Filter and a Security
Realm. System administrators can choose between these
alternatives to protect each resource. The Java Filter is
loaded by the application container before the servlet
processes the incoming request, catching and checking
end-user requests. Similarly, the Security Realm defines
constraints that all requests must fulfill (authentication
and authorization in this case) before calling the servlet
dispatcher. To check the requests, both Filter and Realm
make use of the Authentication and Authorization Validator module.
Yes, through
attribute release
policies
Yes, RBAC
and
delegation
through
XACML v3
Yes, admin
module
Integrated
Privacy
user-friendly management
admin.
by the user
Yes: Authz
Provider +
XACML
Yes: HTTP
sessions +
SAML
Advanced
attributebased
authorization
Yes: SAML,
XACML,
XKMS
Strong
authent.
Yes,
provides
API to
be used
in other
environments
Yes, making Yes,
use of
through
pseudonyms XKMS
Advanced
Integration
services
with
certification support
and validation
services
Yes
MISTRAL
Yes
End-user
privacy
for service
access
Confident. Logging
and
and
integrity auditing
Security related
Based on
standards
Authentication
Level of
assurance
Single
Sign-On
Authorization
Permission
delegation
Administration
189
The Authentication and Authorization Validator is implemented as a library, which is able to check authentication
and authorization over SAML messages. Furthermore, it
is able to query the different providers, or redirect end
users, in order to get the SAML statements. Although
this API is used by the Java Filter, it can also be deployed
by any resource servlet as an independent authentication
and authorization module, without application container
support.
Identity, Attribute and Authorization Providers. The main
task of the rest of the providers on this architecture,
besides managing SAML messages, is to get and check
information from databases. In order to access to databases in a uniform way, a database client API (DB API
Client) has been developed in Java. This API implements
all methods needed to perform database operations, such
as getAttributes, setPolicies, or renameUser, abstracting
the providers from a specific technology.
Additionally, the Attribute Provider and the Authorization Provider have to check Attribute Release Policies
and Access Control Policies, respectively, making use of
the XACML Evaluator. This evaluator could deploy any
mechanism which takes decisions according to XACML
policies. In our implementation, the evaluator deploys an
API based on UMU-XACML-Editor [15], which is able
to load, edit, and save XACML policies from XML files.
Databases. To store both end-user attributes and authentication information, we use LDAP directories, which
are optimized for fast reads and deploy a wide range of
schemas.
Otherwise, both Attribute Release Policies and Access
Control Policies are stored on eXist-DB [35] databases.
eXist-DB allows storing and working with XML files, so
it is feasible to manage XACML policies.
The Administration Module provides a friendly interface, which can be managed via web, in order to make
the administrator tasks easier. We use AJAX technology making use of ZK-AJAX framework [56], which
allows creating interactive web pages, linking functions
and events to Java methods. This way, this interface is
linked to DB API Client, in charge of maintaining databases. It is also in charge of databases synchronization in
order to avoid inconsistencies.
One of the main purposes of this module is managing
access control policies in an easy way. In the one hand, the
Administration Module back-end manages XACML policies, allowing specifying complex policies, such as defining
which subjects are allowed to perform a specific action over a
given resource, under certain environment conditions. On the
other hand, the front-end presents an intuitive policy editor
to define this kind of policies abstracting the administrator
from the complexity of the standard, although without lim-
123
190
123
SAML
HT
TP
S
Shibboleth
Service
Provider
S
TP
HT
Shibboleth
Identity
Provider
End user
SAML
SAML
MISTRAL
Identity
Provider
End user
MISTRAL
Attribute
Provider
(a)
HT
TP
S
MISTRAL
Service
Provider
SAML
S
TP
HT
191
MISTRAL
Authorization
Provider
(b)
7 Performance results
This section describes a testbed of the introduced implementation, which includes authentication and authorization
profiles. The main aim of this testbed is demonstrating the
viability of the proposed architecture in terms of performance. The suitability of the proposed architecture for real
scenarios and the integration with existing solutions have
been described in the previous section.
Firstly, we perform tests of Shibboleth, in order to establish a reference point to compare our implementation, as no
other similar comparative analysis has been found in the
literature. Secondly, evaluations of the different phases of
the profiles have been performed, with different system configuration, based on possible scenarios. Finally, the results
obtained have been analyzed to validate the feasibility of the
architecture proposed. That is, although MISTRAL offers
more functionality than existing solutions, response times
have not increased notably. Finally, the results of analyzing
a real scenario are described.
7.1 Shibboleth testbed
The scenario for this testbed is composed by the two
basic Shibboleth components, Identity Provider and Service
Provider, with a clean installation, that is, without additional
plug-ins or complex configurations. The Shibboleth Identity
Provider is implemented to be deployed in an application
container. It supplies SAML authentication assertions and
end-user attributes according to Attribute Release Policies.
The Shibboleth Service Provider offers a module for Apache
web server, which interacts with a daemon in charge of run-
123
192
Hardware
OS
Supplicant
Identity Provider
Ubuntu
fs:ext3
Ubuntu
fs:ext4
Ubuntu
fs:ext4
Ubuntu
fs:ext4
Service Provider
IdP Database
Base software
8.10 Linux Kernel 2.6.27
10.04 Linux Kernel 2.6.32
10.04 Linux Kernel 2.6.32
10.04 Linux Kernel 2.6.32
123
the scenario are shown in Table 3. These elements are connected through a local 100 Mbs network.
This testbed evaluates the time elapsed since the end user
sends a resource query to the Service Provider until she gets
that resource, taking into account authentication, authorization and attribute release times. Authentication time includes
end-user redirection to the Identity Provider, end-user password recovery from the IdP Database (LDAP directory),
authentication performance based on end-user password,
and authentication assertion issue. The authorization process
evaluates a simple rule based on one end-user attribute.
Finally, the attribute recovery process includes also accessing to the IdP Database and providing the attribute statement.
193
Hardware
OS
Supplicant
Service Provider
PKI
Authentication Database
Ubuntu 10.04
fs:ext4
Ubuntu 10.04
2.6.32 fs:ext4
Ubuntu 10.04
2.6.32 fs:ext4
Ubuntu 10.04
2.6.32 fs:ext4
Identity Provider
Attribute Provider
Authorization Provider
Base Software
Kernel
Linux Kernel
OpenLDAP 2.4.21
Linux Kernel
eXist-db 1.4.0
Linux Kernel
eXist-db 1.4.0
Kernel
Kernel
Kernel
Kernel
123
194
123
195
Furthermore, we make use of the XACML-RBAC specification in order to achieve role hierarchy. The system defines
five roles, from role 1 to role 5, so that role n inherits the permission of role n 1. This way, to evaluate permission of role
5, the Authorization Provider also evaluates the permission
of the previous four roles.
For each role, it has been defined one XACML policy
containing 10 rules, and each end user accessing to the system
is supposed to be in possession of role 5, so 50 XACML
rules are analyzed per end user request. Results of this test
are summarized in Fig. 16.
From this figure, having 50 simultaneous requests, we can
see that the medium time elapsed for each is 3,872 ms. This
increment is due to the policies evaluation, as we can see
in Fig. 17, which in this scenario takes an important part of
the time (43 %). However, the results obtained in this testbed
are similar to the results of the Shibboleth testbed, although
this scenario implements added-value services, such as Level
of Assurance, advanced authorization, or Attribute Release
Policies checking.
Since response time increases, the percentage of timeout
requests is higher, as we can see in Fig. 18. Similar to Shibboleth, this configuration of MISTRAL works fluently with less
than about 190 concurrent requests, and the service would be
unsatisfactory attending more than 240 requests simultaneously.
123
196
123
197
fore, the digital library redirects the end users to the identity
provider of the university when authentication is required,
also achieving Single Sign-On.
In the identity provider of the university, both students
and staff could be authenticated either using a common
username/password credential mechanism or making use
of a digital certificate, which is included in a smart card
that the university provides to each of its member. Staff
members are used to authenticate with their digital certificates, while students usually prefer authentication based on
username/password. For this testbed, we assume that 20 %
of the end users make use of their digital certificate for
authentication.
In a similar way, end users attributes cannot be directly
accessed by the digital library, since they are managed by
the university database applications. However, the university
would offer an attribute provider, as our architecture defined,
where external services can access certain end-user attributes
if they have properly authorization to get them.
The digital library has to launch an authorization process
to determine whether an end user is granted to get a specific book. Hence, the service provider of the digital library
sends a request to its authorization provider to perform such
a process. In the university context, since end users are organized on roles, the privileges of each of them directly depends
on the roles they have. Therefore, the authorization provider
123
198
16
32
Average time elapsed (s) 0.162 0.286 0.458 0.759 1.477 2.632
123
References
1. Adams, C., Lloyd, S.: Understanding Public-Key Infrastructure:
Concepts, Standards, and Deployment Considerations. Macmillan
Technical Publishing, New York (1999)
2. Alcaraz Calero, J., Milln, G., Prez, G.: Towards the homogeneous
access and use of PKI solutions: design and implementation of a
WS-XKMS server. J. Syst. Archit. 55(4), 289297 (2009)
3. Alsaleh, M., Adams, C.: Enhancing consumer privacy in the liberty alliance identity federation and web services frameworks. In:
Privacy enhancing technologies: 6th international workshop, PET
2006, Cambridge, UK, June 2830, 2006; Revised Selected Papers,
p. 59. Springer New York Inc (2006)
4. Anderson, A.: XACML profile for role based access control
(RBAC) (2004)
5. Apache: Apache tomcat (2007). http://tomcat.apache.org/
6. Bouzida, Y., Logrippo, L, Mankovski, S.: Concrete-and abstractbased access control. Int. J. Inf. Security 10(4), 223238 (2011)
7. Burr, W., Dodson, D., Polk, W.: Electronic authentication guideline. NIST Special Publication 800, 63 (2004)
8. Calero, J.M.A., Lpez, G., Martnez, G., Dlera, G., Krebs, S.,
Fiechter, S.: OpenXKMS libraries. http://xkms.sourceforge.net/
9. Cantor, S., Hughes, J., Hodges, J., Hirsh, F., Mishra, P., Philpott,
R., Maler, E.: Profiles for the OASIS Security Assertion Markup
Language (SAML) V2. 0 (2005)
10. Castro-Rojo, R., Lpez, D.: The PAPI system: point of access to
providers of information. Comput. Netw. 37(6), 703710 (2001)
11. Chadwick, D., Otenko, S., Xu, W.: Adding distributed trust management to shibboleth. In: NIST 4th Annual PKI, Workshop, pp.
314 (2005)
12. Chadwick, D.W., Zhao, G., Otenko, S., Laborde, R., Su, L.,
Nguyen, T.A.: PERMIS: a modular authorization infrastructure.
Concurr. Comput. Practice Experience 20(11), 13411357 (2008).
doi:10.1002/cpe.1313. http://www.cs.kent.ac.uk/pubs/2008/2834.
Online ISSN: 1532-0634
13. Crampton, J., Khambhammettu, H.: Delegation in role-based
access control. Int. J. Inf. Security 7(2), 123136 (2008)
199
35. Meier, W.: eXist: an open source native XML database. Web, webservices, and database systems (2002)
36. Milln, G.L., Prez, M.G., Prez, G.M., Skarmeta, A.F.G.: PKI-based
trust management in inter-domain scenarios. Comput. Security
29(2), 278290 (2009). doi:10.1016/j.cose.2009.08.004. http://
www.sciencedirect.com/science/article/B6V8G-4X1SB4C-2/2/
fd545f200197fbc3be20701b22eb5b72
37. Nenadic, A., Zhang, N., Chin, J., Goble, C.: FAME: adding multilevel authentication to Shibboleth. In: Proceedings of the Second
IEEE International Conference on e-Science and Grid Computing,
p. 157. IEEE Computer Society (2006)
38. OASIS: eXtensible Access Control Markup Language TC v2.0
(XACML) (2005). http://docs.oasis-open.org/xacml/2.0/access_
control-xacml-2.0-core-spec-os.pdf
39. OASIS Standard: assertions and protocols for the OASIS Security
Assertion Markup Language (SAML) version 2.0 (2005)
40. Parducci, B., Lockhart, H., et al.: XACML v3. 0 administration and
delegation profile version 1.0. Committee Specification 01 (2010)
41. Parducci, B., Lockhart, H., et al.: XACML v3. 0 core specification.
Committee Specification 01 (2010)
42. Prez, M., Lpez, G., Skarmeta, A., Pasic, A.: Advanced policies for the administrative delegation in federated environments.
In: Third International Conference on Dependability (DEPEND),
2010, pp. 7682. IEEE (2010)
43. Peyton, L., Doshi, C., Seguin, P.: An audit trail service to enhance
privacy compliance in federated identity management. in: Proceedings of the 2007 Conference of the Center for Advanced Studies
on Collaborative Research, pp. 175187. ACM (2007)
44. Pfitzmann, A., Hansen, M.: Anonymity, unlinkability, undetectability, unobservability, pseudonymity, and identity managementa
consolidated proposal for terminology. http://dud.inf.tu-dresden.
de/Anon_Terminology.shtml V0.31 (2008)
45. Project, O.: Opensaml 2 libraries. https://spaces.internet2.edu/
display/OpenSAML/Home
46. Recordon, D., Fitzpatrick, B.: OpenID authentication 2.0-final
(2007)
47. Recordon, D., Jones, M., Bufu, J., Daugherty, J., Sakimura, N.:
Openid provider authentication policy extension 1.0. Available in
http://www.openid.net (2008)
48. Reed, D., Chasen, L., Tan, W.: OpenID identity discovery with XRI
and XRDS. In: Proceedings of the 7th Symposium on Identity and
Trust on the Internet, pp. 1925. ACM (2008)
49. Rescorla, E.: SSL and TLS: Designing and Building Secure Systems. Addison-Wesley, Reading, MA (2001)
50. Roman, E., Patel, R., Brose, G.: Mastering Enterprise Java Beans.
Wiley-India, New Delhi (2008)
51. Snchez Garca, S., Gmez Oliva, A., Prez Belleboni, E., Pau de la
Cruz, I.: Solving identity delegation problem in the e-government
environment. Int. J. Inf. Security 10(6), 351372
52. Schlager, C., Nowey, T., Montenegro, J.A.: A reference model for
authentication and authorisation infrastructures respecting privacy
and flexibility in b2c eCommerce. In: International Conference on
Availability, Reliability and Security, pp. 709716 (2006). http://
doi.ieeecomputersociety.org/10.1109/ARES.2006.13
53. Schlager, C., Pernul, G.: Authentication and authorisation
infrastructures in b2c e-commerce. Lecture notes in computer science (2005)
54. Schlager, C., Sojer, M., Muschall, B., Pernul, G.: Attribute-based
authentication and authorisation infrastructures for e-commerce
providers. Lecture notes in computer science. vol. 4082, p. 132
(2006)
55. Sermersheim, J.: Lightweight directory access protocol (LDAP):
the protocol. RFC 4511 (proposed standard) (2006). http://www.
ietf.org/rfc/rfc4511.txt
56. Staeuble, M., Schumacher, J.: ZK developers guide: developing
responsive user interfaces for web applications using Ajax, XUL,
123
200
and the open source ZK rich web client development framework.
Packt Publishing (2008)
57. SWITCH: Swiss Education and Research Network. http://www.
switch.ch/
58. University of Murcia, Department of Information and Communications Engineering: UMU-PKIv6. http://pki.dif.um.es/
59. Ustaoglu, B.: Integrating identity-based and certificate-based
authenticated key exchange protocols. Int. J. Inf. Security 10(4),
201212 (2011)
123
Copyright of International Journal of Information Security is the property of Springer Science & Business
Media B.V. and its content may not be copied or emailed to multiple sites or posted to a listserv without the
copyright holder's express written permission. However, users may print, download, or email articles for
individual use.