Definition of An Advanced Identity Management Infrastructure

Int. J. Inf. Secur.
(2013) 12:173200
DOI 10.1007/s10207-012-0189-y
REGULAR CONTRIBUTION
Definition of an advanced identity management infrastructure

Gins Dlera Tormo Gabriel Lpez Milln
Gregorio Martnez Prez
Published online: 27 December 2012

Springer-Verlag Berlin Heidelberg 2012
Abstract In recent years, organizations are starting to

demand a finer user access control in order to offer addedvalue services, while end users desire more control over their
private information. Several approaches have been proved
to be efficient in protecting basic scenarios. However, in
scenarios requiring advanced features, such as advanced
authorization capabilities, level of assurance facilities or
effective privacy management, certain issues still need to
be addressed. In this work, we propose an identity management infrastructure, based on the SAML, XACML and
XKMS standards, which extends current approaches in order
to achieve the required features. We include a performance
analysis to show the feasibility of this architecture.
Keywords Identity management Authentication and
authorization infrastructure Validation services SAML
XACML XKMS
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
ples of these approaches, such as Shibboleth [17], Liberty

Alliance [60], OpenID [46] or PAPI [10], make use of different mechanisms, like SAML [39] or HTTP cookies [26],
in order to represent authentication information and end-user
attributes, from identity providers to service providers. Service providers can then make use of end users attributes to
take access control decisions, while the identity providers are
in charge of their authentication.
These approaches have been proved to be efficient in
protecting basic identity management scenarios, being also
applicable in federated environments. However, organizations belonging to identity management environments are
starting to demand a finer user access control in order to offer
added-value services. In like manner, end users increasingly
desire more control over which information could be shared
between entities. In scenarios requiring advanced features,
such as advanced authorization capabilities, level of assurance facilities or effective privacy management, other issues
still need to be addressed, especially those related to trust
relationships establishment and integration with certification
services.
As an example, let us suppose the case where a digital
library, through its service provider, offers certain amount of
scientific document per year to their subscribers, for example, researchers of a given university. To provide a document, the service provider not only requires the end users
to be authenticated proving that she belongs to the university, but also the access control decision is based on users
attributes, such as her roles, or other conditions. Furthermore, some required attributes could be outside the domain
where the authentication is performed. Take, for instance,
those students taking part of any exchange program, having
their information in another university, or those cases where
personal attributes are managed in the city council instead.
Additionally, some end users should be able to temporally
123
174
transfer authority to others to perform specific actions, for

instance if a Ph.D. advisor would like to grant permission
to one of its Ph.D. student for purchasing some documents
during a specific period of time. In any case, the privacy is
a must for this service, being the universities responsible of
maintaining that privacy by hiding the real end-user identity
and releasing only those attributes explicitly allowed by the
end user in an attribute release policy. Let us also suppose
that the end user should be authenticated making use of a
digital certificate or other strong authentication mechanisms
to avoid impersonation and other attacks (e.g., phishing).
The work presented in this paper firstly describes a set
of requirements, in order to summarize demanded features,
which an advanced identity management system should
meet. In this document, we consider as advanced identity
management systems those providing services with stringent security demands, based on web services. That is, these
systems not only consist on offering resources to the end
users, but also allow performing certain actions over such
resources in a controlled way through web services. For
instance, banking systems allowing end users to perform
certain operations via web, where strong authentication and
authorization mechanisms must be enforced or university
systems, where end users information should be retrieved
from different sources and trust relationships and privacy
issues should be therefore managed. The requirements,
used to compare current identity management solutions, are
based on both previous literature and current organizations
needs.
The main objective of this work is to propose an identity management infrastructure, based on standard technologies, which extends current approaches in order to achieve
all the presented requirements. The proposed infrastructure
introduces components in order to manage and supply enduser attributes, the Attribute Provider, with privacy control and delegation capabilities, as well as components to
manage access control policies and to take access control
decisions, the Authorization Provider. This infrastructure
achieves, among other things, advanced authentication and
authorization capabilities, providing more authority to the
end users. Additionally, it integrates certification and validation services in order to improve reliability in trust relationship. These issues can be taken to federated environments.
The rest of this paper is structured as follows. Section 2
presents a set of requirements that advanced identity management systems should fulfill. Section 3 briefly introduces
related proposals that motivate our work. Section 4 describes
the proposed architecture, while Sect. 5 analyzes its behavior and how it meets the presented requirements. Then,
implementation details are presented in Sect. 6, and Sect. 7
describes performance results that have been obtained in
order to validate the proposed architecture. Finally, in Sect. 8
we present our conclusions and remarks.
123
G. Dlera Tormo et al.
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
the identity providers should send the level of assurance

of its performed tasks, and an agreement between them
should therefore exist to exchange that level of assurance
information.
Single sign-on: Users of Web services usually had to
manage one set of authentication credentials for every
service they were registered with. Single Sign-On (SSO)
[14] has been proposed as a solution to the usability, security, and management implications of this situation. From
the end-user perspective, in a system running an authentication process, it is desirable to make use of a SSO
mechanism, in order to provide the resources offered,
but not having to re-authenticate each time.
2.3 Authorization requirements

Advanced attribute-based authorization: The main function of an access control system is to decide whether an
end user is allowed or not to access a resource offered
by the service provider. To this end, it should execute an
authorization process that meets the following requirements:
The authorization mechanism should be able to
recover end-user attributes, which will be available
at the end-user identity provider, and asks a Policy
Decision Point (PDP) [38], which takes an access
control decision.
The set of access control policies should be based
not only on end-user authentication, but also on the
end-user attributes and taking into account additional
environment factors, like date, network load, etc [38].
Service providers not only know whether the end user
is allowed or not to gain access to a resource but,
according to Schlager et al. [54], the system should
be able to specify actions associated to the decision
taken, which should be run by the service provider.
For instance, an end user could have a specific quality
of service according to her role on the system.
Permission delegation: In some identity management
scenarios, it is common that a holder of a privilege
attribute wants to delegate such privilege to another person, without involving the service provider or having to
reconfigure anything in the system [13,51]. For instance,
an end user may want to transfer their role to other end
user for performing a specific action over certain conditions, for example, when she is on vacation. Therefore,
in advanced identity management environments, the system should provide the ability to delegate authorization
privileges from one end user to another. Additionally, delegation should be performed on the fly by writing certain
delegation policies for example.
123
176
2.4 Administration requirements

Integrated user-friendly administration: Identity management systems usually require managing a wide range
of data, such as end-user information, creating or deleting
end users, changing password or associating digital certificates, etc. Likewise, they manage end-user attributes,
creating, changing and managing them. These systems
are also in charge of defining and deploying access control policies. An additional feature should be administrated, such as managing the public key infrastructure,
level of assurance, etc. This information is stored on
different databases which make use of specific technologies, so administrators need to make use of and to understand different tools to manage all of them. Therefore, it
is desirable for any potential system to provide a userfriendly interface where administrators can manage each
element of the system.
Privacy management by end user: Extending the previous item, an end user should be allowed to restrict
what information about her will be released to service
providers, from the organization the end user belongs
to. Furthermore, any end user should be able to choose
which attributes she wants to make use when accessing
a specific service. Hence, the system should allow each
end user to configure her privacy preferences for each
service [23], for instance defining certain privacy rules
in their virtual profiles.
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
it just provides basic authentication mechanisms, but external

modules are required to make use of strong authentication.
In the same way, Shibboleth does not allow advanced
authorization and just elementary decisions based on enduser attributes are achieved. For instance, it does not allow
taking access control decisions based on the time of day
or other environmental conditions, as required by not few
organizations nowadays. Moreover, access control policies
in Shibboleth are not based on standards. Another limitation is that even though Shibboleth supports attribute release
policies defined by end users, it needs external GUI editors,
such as ShARPE [30]. In the same way, it does not provide
any friendly system administration interface either, having to
manage the system editing XML files manually.
Liberty Alliance [60] was founded by more than 200
organizations, such as SUN and IBM, with the objective of
developing a set of standards for implementing a federated
identity architecture. Liberty Alliance also makes a distinction between Service Provider and Identity Provider, but they
are grouped into Circles of Trust (CoT). In this way, the end
users just need to authenticate in an Identity Provider to gain
access to services of any component into the CoT, in a transparent and secure way. The CoTs establish trust relationships
between providers; however, they do not integrate any validation service.
In addition, Liberty Alliance develops only concepts
and standards which allow compatibility between different
implementations by third party companies, but there is not
a reference implementation. Moreover, an implementation
following Liberty Alliance specifications does not have to
support neither strong authentication nor advanced authorization. Since there are different Liberty Alliance implementations, end users should carefully look at the privacy
policy of the system in question [3,52]. Furthermore, Liberty
Alliance provides a framework where end users are asked
for confirmation when their attributes are requested, but they
cannot define attribute release policies.
Point of Access to Providers of Information (PAPI) [10]
was developed by RedIRIS, a Spanish NREN (National
Research and Educational Network), as an access control
system to protect resources with authorization capabilities.
In PAPI, end users have a website listing all digital resources
they may access after a successful authentication at the
Authentication Server (i.e., Identity Provider) in their home
domain. Selecting one of these resources, the end user is redirected to the Point of Access (i.e., Service Provider) which
performs the authorization process acting as a web proxy
between the end user and the target resource. However, if
advanced authorization should be performed, that process
has to be delegated to external modules. Even though PAPI
supports strong authentication with digital certificates, it is
not integrated with any validation service. It does not support neither Level of Assurance nor permission delegation
nor advanced web services. In current implementations, end

users are not able to define their ARPs. Furthermore, there is
not any friendly administration tool for managing the system.
OpenID [46] is an open and decentralized solution supported by big companies, such as Google, Verisign, or AOL.
It makes use of HTTP cookies and supports Single Sign-On,
in order to allow end users to log on different services with
the same digital identity without having to register or be
approved by any central authority. However, it is not integrated with any validation service. One of the main properties
of OpenID is that end-user identifiers are URLs or XRIs, so an
end user obtains an OpenID URL that can be used to log into
all OpenID-enabled websites. However, OpenID requires end
users to supply the same OpenID identifier in all sites and
in subsequent interactions within the same site. Therefore,
the end users have to create and manage different OpenID
accounts if they want to have a certain level of privacy. Additionally, OpenID does not define any authorization process
because it deals mainly with authentication, but, as result of
the absence of central authority, anyone who implements the
OpenID standard can become an OpenID provider, implementing whatever authentication process. Hence, although
[47] describes how to specify Level of Assurance, it is difficult for both service providers and end users to maintain a
list of reliable OpenID providers.
PERMIS [12] is maintained by the University of Kent
in the UK and takes part of the US NSF Middleware Initiative software release. It was designed as an authorization infrastructure which uses X.509 attribute certificates to
hold an end users credentials for hierarchical Role Based
Access Control (RBAC). In this way, PERMIS acts as a PDP
returning a granted or denied response according to the policy applicable at that time. PERMIS is focused primarily
on authorization, so it allows defining advanced access control policies supporting permission delegation with a friendly
editor, but policies are not based on standards. Moreover,
this solution does not deploy either authentication services
or integration with validation services, so it needs integration with external service providers and identity providers.
Thus, the system will only have Level of Assurance or Single
Sign-On capabilities if they are also supported by the identity provider. Since PERMIS uses just a distinguished name
(DN) for the storage and retrieval of attributes, privacy can
be guaranteed if the certificates are bound to a pseudonym,
and the authentication mechanism does not match the end
user real name with the DN. However, a provider getting the
DN can access all available attributes.
Following the described digital library example, these
solutions could achieve certain access control to determine
which users could access the services, although the trust relationships with the different universities must be directly managed by the service provider. In some solutions, the privacy of
the users is not rightly controlled, allowing the digital library
177
to trace which documents have been obtained by each user.

Other described requirements, such as permission delegation,
are difficult to achieve in these architectures.
To summarize, Table 1 presents a table comparing current
identity management solutions. It shows how these solutions
meet the presented requirements.
4 Proposed architecture
In basic identity management scenarios, organizations offer
services or share resources managing the access control
through service providers. To authenticate end users, there
are organizations responsible for asserting identities to end
users through identity providers. It is supposed that identity
providers and service providers trust each other, since they
are considered to be within the same trust boundary. However, this classical approach is not enough to achieve the
requirements identified as part of this work, as shown in the
previous section.
To address the stated requirements, this work proposes an
identity management architecture based on standards which
extends that approach. It allows strong authentication and
advanced authorization mechanisms with privacy management and level of assurance capabilities. Furthermore, it is
integrated with certification and validation services, in order
to maintain trust relationships between components [59].
Additionally, the proposed architecture deploys an administration module in order to administrate the system components in a friendly way.
The proposed architecture, named MISTRAL, is shown
in Fig. 1. In this architecture, an end user interacts with
both the Service Provider, trying to gain access to protected
resources, and the Identity Provider, sending her credentials
in order to be authenticated. However, these processes are
complemented by introducing further components, although
end-user interactions are similar than those of the presented
solutions. That is, end users are abstracted from the addedvalue functionality.
The organization the end user belongs to (the university in the aforementioned example) provides to the Service Provider (of the digital library, following the same
example) authentication assertions, although it also requires
attributes of the users. These attributes may be requested
at any time of the access control process, either after performing authentication or during the authorization process,
requesting them in order to take an access control decision.
Furthermore, the organization must ensure end-user privacy,
so, apart from hiding real identities, attribute release policies
should be checked before providing any end-user attribute.
All cited identity management solutions restrict the exchange
of attribute information to the login process, but, as shown in
previous section, this is not sufficient to achieve the requirements.
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
Table 1 Summary of how existing solutions meet the proposed requirements
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
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
Fig. 1 MISTRAL architecture
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

Attribute
Provider
AC Filter
Manager
End user
AC Filter
Manager
MISTRAL Enabled Service Provider
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
Fig. 2 Service Provider architecture
tionship between the issuer and the recipient. These trust

relationships are managed using a Public Key Infrastructure
(PKI) through the certification path validation process, which
involves: path discovery, signature verification, and revocation status checking [36].
The PKI determines the trust boundaries by controlling
the trust relationships between the different components. In
this way, although the components of the architecture could
belong to different organizations or domains, they all establish their own security domain, also determining the trust
boundaries. In this sense, it could be easily determined which
services, for instance those offered by the Service Provider,
could cross a boundary.
Current solutions have to implement specific PKI connectors or establish trust relationships statically. However,
advanced solutions should be able to deal with any PKI
dynamically, without requiring significant redesign or complex system adjustments. To this end, an XKMS client [2]
is integrated in MISTRAL components, in order to ask the
PKI with the aim of verifying communication messages. The
XKMS client also allows verifying public key certificates
used by end users, for example, for strong authentication.
Since this architecture makes use of different databases,
depending on the kind of information they maintain (from
end users data or attributes, to control policies) an administration module has been added. This module manages such
information in a unified and friendly way through web interfaces. In the following sections, we describe each component
of the proposed architecture.
4.1 Service Provider

In the proposed architecture, the Service Provider, Fig. 2,
only manages those web resources that the organization
wants to share, delegating authentication to the Identity
Provider and authorization to the Authorization Provider.
However, it needs a mechanism to protect shared resources,
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

Service
Provider
181
MISTRAL Identity Provider

PKI
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
Fig. 3 Identity Provider architecture
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

MISTRAL Attribute Provider
Identity
Provider
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
Fig. 4 Attribute Provider architecture

Attribute
Provider
SAMLAttributeQuery/
Response
MISTRAL Authorization Provider
SAML
Encoder/Decoder/
Validator
Policy Decision
Point
DB Client API
XACML
SAMLAuthZDecisionQuery/
Response
XKMS Client
XACML
Evaluator
Access Control
Policies
Service
Provider
Fig. 5 Authorization Provider architecture
also in charge of evaluating the attribute delegation policies,

which define the ability of end users to authorize other end
users, on the fly, to hold some of their attributes if specific
conditions happen [40]. The management of these policies
can be achieved by either the end users or the administrator
through the Administration Module, as shown below. In this
way, it accomplishes the privacy management by the enduser requirement and enables the permission delegation, as
we have shown in Architecture Analysis section below.
Summarizing, the Attribute Provider receives attribute
queries and send attribute statements back with attributes
allowed. The requester can be any module of the MISTRAL
architecture once the trust relationship has been established.
4.4 Authorization Provider

The Authorization Provider, depicted in Fig. 5, executes
authorization processes based on end-user statements and
attributes (e.g., roles, department, address), the resource
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.
However, since the Authorization Provider can also ask the

Attribute Provider, these attributes could be recovered while
completing the access control decision. Additionally, that
enables that only adequate attributes are requested, as we
have shown in the Architecture Analysis section below.
4.5 Databases
As depicted above, MISTRAL makes use of different databases to store different kinds of information, from enduser information, such as authentication data or end-user
attributes, to control policies, such as attribute release policies or access control policies. In this proposal, we differentiate five kinds of databases:
Authentication Database: This database maintains necessary information to authenticate end users. For instance,
it can maintain a list of usernames and encrypted passwords or a list of usernames and associated digital certificates. Therefore, this database can be implemented
with any technology which supports end-user credentials,
although it should assure that this database is only accessible by the Identity Provider in order to fulfill security
requirements.
User Attribute Database: All known end users attributes
are maintained in this database. This database manages
both system information, such as roles assigned to an end
user or department an end user belongs to, and personal
information provided by the end users themselves, such
as real name or address. Furthermore, these attributes
should follow a common schema, known by each component, such as eduPerson [21], which provides a common
list of attributes and definitions for building generalpurpose institutional directories. In order to maintain
end-user attributes privacy, this database should be only
accessible by the Attribute Provider.
Attribute Release Policies Database: Even though this
architecture is based on trust relationships, not all Service Providers are allowed to obtain each end-user
attributes. So, this database maintains the policies which
the Attribute Provider makes use in order to know what
end-user attributes can be transferred to a requester. In
this way, XACML policies are defined by either systems
administrators or end users.
Attribute Delegation Policies Database: This database
maintains XACML v3.0 policies [41], which permit
authorized end users to create new policies to delegate
certain attributes to others. In other words, policies which
control who can create policies. XACML v3.0 introduces
the PolicyIssuer element in order to establish the policy
creator, allowing evaluating if that end user is authorized
to delegate specific attributes. Moreover, these policies
183
allow defining under which conditions that delegation is

applicable.
Access Control Policies Database: In order to fulfill the
advanced attribute-based authorization requirement by
making use of standards, the access control policies are
defined following XACML. Furthermore, we follow the
XACML-RBAC (Role Based Access Control) profile [4]
to support hierarchical roles [6]. As previously mentioned, these policies are maintained by the Authorization
Provider.
4.6 Administration module

Identity management systems require managing different
components and databases, which store different kinds of
information, as shown in the previous section. To manage
this information, different components and tools are needed,
some of them requiring to have a deep knowledge of the
technology being deployed. Furthermore, some of these databases need to be synchronized in order to avoid inconsistencies in data.
It is not only necessary to know how to use components
for managing databases, such as LDAP manager, but also
knowledge about XACML policies definition or attributes
schemas is needed. Moreover, the system administrators have
to maintain certificates and trust relationship between components. This task would be undesirable for administrators
if they have to manage each component and database independently. With the aim to lighten the administrator tasks in
the proposed architecture, we introduce the Administration
Module, which is able to manage all these issues.
The Administration Module, Fig. 6, is available via web
browser since it implements an Administrator Web Interface.
This visual interface provides to the administrator the tools
needed to manage each component of the system, such as
databases or policies, in a user-friendly way. Thereby, the
administrator, making use of this interface, is able to register or delete end users independently of the database type
and edit the authentication information; administrate enduser attributes and Attribute Release Policies; manage the
PKI, creating, revoking, and validating public key certificates; and establish access control policies without having
knowledge about the complex XACML standard.
In the same way, end users can also make use of the
Administration Module, with restricted capabilities, in order
to update their own features in a controlled and user-friendly
way. That includes managing authentication information as
well as other features related to user-centric approaches, such
as attribute release policies and attribute delegation policies.
The Administration Module presents a simple interface to
the end users, in order to allow them to manage the different features without requiring further technical knowledge.
123
184
MISTRAL Administration Module
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
Fig. 6 Administration console architecture
For instance, end users can establish attribute release policies

just selecting from a list the entities allowed to get each of
their attributes, or defining default permissions, as we show
in the following section.
The Administrator Web Interface interacts with the DB
Manager module. That module implements different APIs
needed to manipulate each database used by the system, such
as LDAP or the interface to manage XML databases. It also
provides a common API in order to abstract the Administrator Web Interface from databases implementation details
and other factors of the system. Therefore, if a new type of
database needs to be managed by the system, the database
management implementation will be added to the DB Manager with no changes in the rest of components.
The DB Manager also provides the modules XACML
Encoder and PKI Manager. The former is in charge of
abstracting the definition of both access control policies and
attribute release policies. The PKI manager implements necessary methods to administrate the PKI, such as create new
end-user certificates or manage certificates establishing relationships between entities. It implements PKI connectors in
order to be in touch with an external PKI already deployed.
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
These processes are grouped into security, authentication,

authorization and administration subsections. In this way,
they can be related to the requirements presented in Sect. 2,
in order to summarize how the proposed architecture accomplishes them.
As the authentication and authorization processes only
extend the SAML Web Browser SSO Profile [9], we just
explain the added-value aspects of our solution. The basic
SAML message interaction between the Identity Provider
and the Service Provider falls outside the scope of this work.
5.1 Security related requirements
As well as the cited solutions, this architecture makes use of
secure communication channels, such as SSL/TLS, in order
to safeguard the confidentiality and integrity. Additionally,
in order to check integrity and authenticity of SAML messages, each one must be digitally signed, and the receiver
of this message must validate the signature. Information of
received and sent messages is logged and audited. These
logs are locally stored or could be managed making use of
syslog protocol. In case of abnormal behavior the log information could be analyzed. Additionally, the providers only
accept messages from reliable components. For instance, the
Identity Provider does not provide any answer either to an
unsigned authentication query or to a query signed by an
unreliable Service Provider.
Those trust relationships are managed making use of
the standard XKMS Service which meets the integration
with certification and validation services requirement. This
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
Fig. 7 Authentication process
service allows recovering and validating digital certificates,

abolishing the need for managing them in a local way and
without having to bind the providers implementation with
the services of a specific PKI.
The architecture is not only based on protecting basic web
services, but also it can be deployed to provide advanced
services support. For instance, the protected resources can
be deployed on an application container. The Implementation section above introduces an API that allows protecting
different kinds of applications or services.
Following with requirements, this architecture accomplishes end-user privacy for service access by making use of
pseudonyms. In this sense, the SAML authentication assertions, generated by the Identity Provider, does not reveal any
real end-user identity.
Going back to the example of a digital library whose
Service Provider offers scientific documents to universities or
research companies, making use of this architecture the digital library could establish secure communications without
requiring managing trust relationships directly. The digital
library could generate log information, not only for statistical purposes, but also for guaranteeing that the entities cannot
deny performing a transaction. Additionally, the subscribers
preserve their users privacy, so the digital library neither can
know the real identity of the user accessing their resources

nor links different transaction performed by the same user.
5.2 Authentication requirements

The authentication process is performed by the organization
which manages end-user credentials, as depicted in Fig. 7.
In common identity management scenarios, the authentication service is needed by the Service Provider, but the
authentication process is delegated to the Identity Provider.
To achieve that, the Service Provider has to previously know
where the end user belongs to, or it could make use of any discovery service [27]. That is necessary in case the MISTRAL
architecture is being deployed in federated environments. For
instance, when a non-authenticated end user wants to get a
resource, the Service Provider redirect her to a service where
she can choose the Identity Provider to be redirected, or it is
automatically selected making use of other discovery techniques [48].
Along with the HTTP Redirect, a SAMLAuthnRequest
message is generated. This message specifies the Service
Provider information, also including the LoA required, as
shown in Fig. 7. This way, it does not only indicate to the Iden-
123
186
tity Provider that an end user authentication is required, but

also the minimum requirements to perform a valid authentication. Take, for instance, the case where the Service Provider
is offering a critical service, such as banking operations, so it
must to be sure that the end user has been authenticated using
a strong authentication mechanism to avoid impersonation.
Since each Service Provider needs to send a SAMLAuthnRequest to the Identity Provider, this mechanism may
entail a privacy risk, in the sense that the Identity Provider
could track end user Service Provider visits [34]. In order
to avoid that, the infrastructure allows end users to get the
authentication assertion (i.e., SAMLAuthStatement) before
accessing any Service Provider. That is, the end user firstly
gets an authentication assertion in the Identity Provider, and
then, she tries to access the resources, contained in different Service Providers, presenting the authentication assertion.
As response to the authentication request, the Identity
Provider presents the login web page, where the end user
is able to choose among different authentication methods,
as shown above. Depending on the used method, the Identity Provider executes different actions, in order to check if
the credentials are valid. For instance, if the end user makes
use of login-password through MS-CHAP protocol [62], the
Identity Provider could read the database which contains this
authentication information. However, if the end user makes
use of her digital certificate instead, in order to enforce
a strong authentication mechanism, the CheckCredentials
process asks the XMKS Service for an end-user certificate
validation. Therefore, the Identity Provider is abstracted from
the details of the implementation of the certification service.
Additionally, the Identity Provider makes use of HTTP
cookies, establishing sessions, in order to avoid the end users
to re-authenticate each time. This meets the Single SignOn requirement. Furthermore, following the normal operating mechanism, the SAML assertion, which the end users
abstractly obtain after authenticating, can be used several
times in the Service Provider, without requiring subsequent
queries to the Identity Provider. For instance, although an end
user performs the authentication process in their university
to get documents from a digital library, where the university
is subscribed, this architecture avoids the university to trace
the documents the end user has obtained.
After the login process, a SAMLAuthStatement is generated. That statement contains Identity Provider information and time-stamps, and it also specifies the authentication
method that has been used to achieve the Level of Assurance
requirement (LoA). It is worth mentioning that the SAML
message generated does not reveal either the real end users
identity or any other private information about her, as it makes
use of pseudonyms in order to preserve privacy, as previously
presented. That is, the aforementioned digital library could
not trace the documents each end user has obtained.
123
5.3 Authorization requirements

To achieve a complete access control process an authorization
procedure should be executed. As shown in the requirement
section above, that procedure may evaluate complex rules
taking into account different aspects, not only regarding to
the end user, and allowing as fine-grain access control as
needed. Furthermore, this process should be also in charge
of defining additional actions to be performed, such as handle
several successive accesses from the same source, in order to
avoid DoS attacks or provide specific quality of service [24].
This authorization process could be launched by the Service Provider when an authenticated end user tries to get
access to a protected resource, in order to know if that end
user is allowed to gain access to the resource. However, as
commented in the previous section, the authorization process
is performed out of the Service Provider. Alternatively, this
task is delegated to the Authorization Provider, which allows
setting and managing access control policies independently
of the Service Provider management. This way, the Service
Provider load is decreased, since it is not in charge of analyzing the authorization rules, but only providing resources
and services.
Unlike most of the previously cited solutions, in MISTRAL, the communication between the Service Provider and
the Authorization Provider, as well as the access control policies definition, is fully based on standards. In particular, the
Authorization Provider communication is performed following the SAML Assertion Query/ Request Profile [9], while
access control policies follow the XACML standard. In this
way, it enables more effective deployment of new Service
Providers. Additionally, several related Service Providers can
share access control policies, or even they can attach the same
Authorization Provider without having to reconfigure their
elements.
The authorization process commonly requires the enduser attributes at any time during the process, in order to
take an access control decision. These end-user attributes
can be recovered by the Identity Provider while it performs
the authentication process and sends them along with the
SAML authentication statement, or they can be recovered
by the Service Provider when it notices that the authentication statement does not contain them. In doing so, end-user
attributes could be known before the authorization process
begins.
Nevertheless, this infrastructure also allows that the
Authorization Provider recovers the end-user attributes,
while authorization process is being performed. In such a
case, only needed attributes will be recovered, as described
in Fig. 8. Take for instance the case where the example digital library needs to get the role of the end user within the
university to check if the end user is a researcher, although
it does not need to know other attributes such as the real
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
Can this requester get

user role + country?
CheckARP
CheckADP
Has this end user

applicable delegated
attributes?
SAMLResponse
XKMSValidate
Fig. 8 Attribute recovery
end-user name or her email address. Either the Identity

Provider or the Service Provider or Authorization Provider
can get end-user attributes sending a signed SAMLAttributeQuery to the Attribute Provider, also following the SAML
Assertion Query/ Request Profile [9]. The provider which
runs this process depends on the system configuration.
Before the Attribute Provider sends attributes back, it gets
and checks the Attribute Release Policies, in order to guarantee end-user privacy. In a similar way, it checks if the end user
has any additional attribute delegated by other end user, coping with the delegation requirement. For instance, a Ph.D.
advisor would like to grant permission to one of its Ph.D.
students for purchasing some documents during a specific
period of time. To perform that process, the Attribute Delegation Policies are evaluated, analyzing if exist any policy
related to that end user, applicable in such moment and valid,
that is, if that policy has been issued by an end user with
enough permission to define this kind of delegation. According to those policies, it generates a signed SAMLResponse,
containing the SAMLAttributeStatement which represents the
end-user attributes. This statement specifies attribute name
and attribute value pairs.
Once having the end-user attributes, the Authorization
Provider gets the XACML policies from the Access Control
Policies database making use of DB Client API. As shown
above, these policies define attribute-based access control.
Furthermore, this infrastructure extends the XACML basic
profile to include a recommended XACML AttributeId for
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
the system management, achieved by the administrator, and

the management achieved by the end users. The latter is
related to aspects that end users control, in order to define
their own preferences or specific behavior in the system. They
both are managed by the friendly administration module.
On the one hand, running the administration module in
administrator mode, it allows managing resources and its
related access control policies, as well as controlling the trust
relationship between providers. As previously described, the
access control can be achieved defining XACML policies,
while trust relationships can be easily controlled making use
of the XMKS client. Nevertheless, the administrator neither
has to manage policies directly nor have deep knowledge of
standards. The administration module presents a simple and
intuitive interface guiding the administrator to achieve such
managements.
On the other hand, invoking the module as an end user,
it permits managing policies with regard to the end-user
attributes, in such a way that privacy can be managed by
end users. The Attribute Release Policies are supported following the architecture proposed by Hommel [22]. That proposes a schema where this kind of policies is also defined
through the XACML standard, allowing the end users to
establish a set of rules in order to specify their preferences. Each rule fixes the attribute name as a Resource tag,
while the Subject tags are the set of Service Provider which
can or cannot get that attribute. To define the rules, the
administration console presents a list of Service Providers
deployed by the architecture, although the end user could
also add others or defining default actions if a new Service Provider is requesting user attributes. Furthermore,
they can specify to be asked when a Service Provider
requests attributes instead of predefining the rules beforehand.
The Attribute Delegation Policies are supported making
use of an adapted version of the XACML v3.0 Administration and Delegation Profile [40]. It focuses on the difference
between having the capability of performing an action and
having the capability to delegate that capability. The latter
is related to be authorized in creating policies in order to
enable a delegation [42]. Making use of the administration
module, end users can generate these policies, through an
interface, establishing when the delegation is applicable, for
instance, if it should be activated only during a specific time
period. The generated Attribute Delegation Policies will be
evaluated when end-user attributes need to be recovered, as
shown above.
Similar to the user-friendly interface for administrator, the
administration module presents a simple web interface to the
end users, abstracting them from the complexity of the standards. End users do not have to either edit policies directly or
have further knowledge of security or technical issues. The
purpose of this interface is offering a tool where end users
123
can intuitively manage their identity preferences similar to

how they manage a profile in common social networks.
Table 2 summarizes how MISTRAL fulfills the proposed
requirements.
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
Table 2 Fulfillment requirement table for MISTRAL
Based on
standards
Authentication
Level of
assurance
Yes, through Yes, carried

P.K.
by the
certificates
SAML
assertions
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
Fig. 9 Overview of the administration web console
iting the functionality. Furthermore, it could be adapted for

specific scenarios.
For instance, Fig. 9a depicts how the policy editor could
represent the access control policies that a digital library
could establish. In this case, as it is expressed by the first rule,
the documents are allowed to be read by any subject owning
the attribute (or Role in this specific example) researcher.
Although it is not shown in Fig. 9a, the editor also allows
defining conditions or other environment features for applying the defined rules, as it is allowed by XACML standard.
In this sense, additional features could be expressed or the
policies could even be complemented with other standards
and/or technologies.
123
For example, it could be specified that a rule is only

applicable between 9 a.m. and 5 p.m. or it could specify
complex rules which allow an entity get certain information
if and only if it is for a specific purpose. Another example of policy definition could be to control that an end user
has to be authenticated with a specific strong mechanism to
get access to some critical resources. The editor also allows
defining obligations describing additional procedures to be
performed besides allowing, or not, performing the action.
In any case, the editor could be extended or adapted to fulfill
demands of more complex scenarios.
The Administration Module could be also invoked by the
end user, in such a way they can modify their attribute release
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)
Fig. 10 Shibboleth and MISTRAL compatibility
policies or delegate one of their attributes to other user. In this

case, as depicted in the Fig. 9b, the end user is permitting
the digital library service provider to obtain their role, but
not the rest of their attributes. Additionally, as shown in the
Fig. 9c, the end user could delegate one of their roles to other
user, granting this latter end user to read documents from the
digital library.
6.1 Compatibility with existing solutions

Since our architecture makes use of the SAML standard, it
can be integrated with existing SAML-based solutions as
well, such as Shibboleth, currently deployed in real scenarios as an authentication and authorization infrastructure. As previously commented, Shibboleth makes use of
SAML to exchange authentication information between the
Service Provider and the Identity Provider. Since MISTRAL also follows this standard, the Shibboleth Service
Provider is allowed to request authentication to the MISTRAL Identity Provider, supporting strong authentication.
In the same way, the MISTRAL Service Provider is able to
query authentication and attributes to the Shibboleth Identity Provider, while performing advanced authorization (see
Fig. 10).
Therefore, organizations which have deployed this kind
of solutions, such as the Swiss Education and Research Network (SWITCH) [57] can also deploy MISTRAL, having
both solutions working simultaneously. However, this integration could impede added-value services, such as Level of
Assurance, Attribute Release Policies, friendly administration interface, or advanced services support.
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
Table 3 Shibboleth testbed components

Element
Hardware
OS
Supplicant
Pentium IV 2 GHz 512 MB RAM
Identity Provider
Intel Core 2 Duo 2.33 GHz 3.9 GB

RAM
Intel Core 2 Duo 2.33 GHz 3.9 GB
RAM
Intel Core 2 Duo 2.33 GHz, 3.9 GB
RAM
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
ab (Apache HTTP server benchmarking tool)

Apache Tomcat 6, JDK 6, Shibboleth IdentityProvider 2.1.5
Apache web server 2.2.14, Shibboleth ServiceProvider 2.3.1
OpenLDAP 2.4.21
Fig. 11 Shibboleth scalability result
Fig. 12 Erroneous requests in Shibboleth
ning access control processes. Additionally, we make use of

an LDAP directory, named IdP Database, to store end-user
credentials and attributes.
For this testbed, we simulate end-user requests making use
of ab Apache HTTP server benchmarking tool [18], which
performs several concurrent HTTP or HTTPS connections.
This application has been adapted to send end-user credentials when they are solicited, as well as for supporting web
redirection. We named Supplicant to the component in charge
of performing the end-user requests.
The deployed scenario applies the basic Shibboleth configuration, which includes signing and checking SAML messages through digital certificates stored in local hard disk.
Details of the hardware and software elements used to deploy
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
Table 4 MISTRAL testbed components

Element
Hardware
OS
Supplicant
Pentium IV 2 GHz, 512 MB RAM
Service Provider
Intel Core 2 Duo 2.33 GHz,

3.9 GB RAM
3.9 GB RAM
3.9 GB RAM
3.9 GB RAM
Ubuntu 8.10 Linux

2.6.27 fs:ext3
Ubuntu 10.04 Linux
2.6.32 fs:ext4
Ubuntu 10.04 Linux
2.6.32 fs:ext4
Ubuntu 10.04 Linux
2.6.32 fs:ext4
Ubuntu 10.04 Linux
2.6.32 fs:ext4
PKI
Pentium IV 2 GHz, 512 MB

RAM
Ubuntu 8.10 Linux Kernel

2.6.27 fs:ext3
Authentication Database

3.9 GB RAM
3.9 GB RAM
3.9 GB RAM
3.9 GB RAM
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
User Attribute Database

Attribute Release Policies
Database
Access Control Policies
Database
Each test execution simulates a specific number of end

users requesting protected resources simultaneously. Several
executions were performed adjusting the number of concurrent end users from 1 to 100. Moreover, in order to avoid
random inconsistencies, the test was repeating 25 times for
each number of concurrent end users, getting the average
values.
Figure 11 shows the average time by end user in requesting
a dummy resource, given a simultaneous number of end users
requesting the same resource. For instance, if 50 end users
are requesting a resource simultaneously, each end user experiences a medium delay of 4,012 ms in getting that resource.
As normal behavior in these scenarios, while simultaneous
end-user accesses increase, the average response time is also
increasing. The relation between the average time and the
number of simultaneous end-user accesses provides a good
metric about server performance.
Additionally, we analyzed the maximum number of concurrent requests the system is able to support. We consider
that a request is not answered if its response delays more than
30 s. In this way, we performed tests in order to indicate the
percentage of timeout requests when a given number of end
users send requests concurrently. The results of these tests
are summarized in Fig. 12.
We can see that this system supports up to 190 concurrent
end users fluently. That is, having up to 190 concurrent
requests, less than 1 % of those have become timeout
requests. Since that, the system starts misbehaving, and working with more than 250 end users, the system behavior
becomes unacceptable.
Base Software
Kernel
Linux Kernel 2.6.32
ab (Apache HTTP server

benchmarking tool)
Apache Tomcat 6, MISTRAL
ServiceProvider 1.0
Apache Tomcat 6, JDK 6,
MISTRAL IdentityProvider 1.0
MISTRAL Attribute Provider 1.0
MISTRAL AuthorizationProvider
1.0
UMU-PKIv6 7.2.1,
OpenXKMS WS 2.3,
OpenLDAP 2.4.21
OpenLDAP 2.4.21
Linux Kernel
OpenLDAP 2.4.21
Linux Kernel
eXist-db 1.4.0
Linux Kernel
eXist-db 1.4.0
Kernel
Kernel
Kernel
Kernel
7.2 Description of the MISTRAL testbed

Taking the previous results as reference values, we evaluated
the performance of the proposed solution. There is a direct
translation between the proposed architecture and the elements of this testbed. The Supplicants component simulates
end users accessing to protected resources, making use of ab
(Apache HTTP server benchmarking tool).
Details of the hardware and software elements used to
deploy the scenario are shown in Table 4. Hardware used on
this testbed has the same characteristics than the hardware
used on the previous one, as well as both testbeds use equivalent versions of software, in order to enable comparison
between them.
7.3 MISTRAL base test

The first test carried out over this testbed is used to study the
authentication and authorization profiles previously defined.
These profiles include the end user sending a resource query
to the Service Provider, a login-password authentication
process, the attribute recovery achieved by the Attribute
Provider, and the authorization process, which is performed
by the Authorization Provider. Added-value services are also
considered, such as Level of Assurance or Attribute Release
Policies checking. As well as the previous test, the assertion
management times have been taken into account, that is for
instance, the creation of SAML messages and components
has been deployed in a local 100 Mbs network.
123
194
Fig. 13 MISTRAL base performance results
The scenario developed for this test defines one access

control policy with a unique rule, indicating that end users
have to be in possession of a specific attribute to grant access.
So delegation has not been taken into account. That policy is obtained and evaluated for each end-user request. The
authentication is performed through the Tomcat Realm module, asking the end users for their login and password. As
it is not necessary to validate the providers public key certificates for each sequential request, XKMS validation is not
taken into account in this test.
As well as the previous testbed, these tests have been
focused on relation to the scalability of the service. Each test
execution simulates a specific number of end users requesting a protected resource simultaneously. Figure 13 shows
the values calculated after the execution of each test 25
times.
In this case, 50 end users requesting resources simultaneously experience a medium delay of 2,627 ms. This decrease
is because our implementation is lighter than the Shibboleth one, and the testbed deployed for this first test does not
include all the added-value services considered in the design
and implementation of MISTRAL. In the following section,
a more realistic configuration is deployed.
We have also analyzed the influence of the different
phases during the authentication and authorization profiles.
The specific measurements taken from the testbed are the
following:
Authentication This phase involves all authentication
tasks. That is, the end users sending authentication
information making use of her credentials, the Identity
Provider requesting the Authentication Database to get
end-user credentials, and finally credentials validation.
In this test, the credential used is the end-user password.
Attribute Recovery. This phase includes all processes
related to attribute recovery. That is, requesting to the
User Attribute Database, as well as requesting to the
Attribute Release Policies Database, and evaluating
the XACML policies, in order to maintain privacy.
123
Fig. 14 MISTRAL base time components
Access Control Policies analysis. This is the evaluation

of XACML policies in order to take the decision of permitting or denying the end-user requests. This decision
is performed by the Authorization Provider according to
end-user attributes.
SAML Creation. This is the time that the different
providers take to create and sign the SAML responses
with the OpenSAML libraries. Depending on the provider,
these responses contain the result of the authentication or
authorization processes or the end-user attributes.
Others. Time spent by the rest of processes running in the
proposed solution, such as signature validation, management of incoming SAML messages with the OpenSAML
libraries, or additional servlet control.
The percentage of execution time of each phase is depicted
in Fig. 14. It shows that authentication and attribute recov-
195
Fig. 15 Erroneous requests in MISTRAL for base test
Fig. 16 MISTRAL access control performance results
ery phases take the highest part of the time, 24 and 29 %,

respectively. That is largely due to the considerable time
taken in accessing the databases, especially those which have
to establish connection with an LDAP directory. In addition, this figure shows that the time taken for SAML creation messages also takes a considerable part of the overall process (23 %). That is a reasonable percentage since
it includes message digital signing, which is a high-cost
process, yet necessary to establish the trust relationships
between providers.
Finally, considering a request as a timeout if it elapses
more than 30 s, Fig. 15 shows the concurrent requests the
system is able to support. It shows that it allows nearly 220
simultaneous requests fluently, while becomes unacceptable
with about 290 requests.
7.4 Access control policies test
Although the previous test shows that our solution is feasible, it is based on a basic scenario where only one
access control policy has been defined on the system. For
this second test, in order to deploy a more realistic scenario, a set of complex access control policies has been
defined.
For this test, the main end users attribute is their role, in
such a way that authorization decisions are based on roles.
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
In this case, having 50 simultaneous requests, the average

time elapsed for each one is 4,249 ms, which is mainly due
to the OCSP validation, which does include network time.
Finally, we introduce XKMS in these tests in such a way
the Identity Provider requests certificate status to the XKMS
Service instead. The XKMS Service, in turn, requests certificate status to the OCSP responder. This way, we can
appreciate the overhead caused by the XKMS Service, also
including network time. This test was performed in a similar way than previous test. Likewise, results are shown in
Fig. 20.
This test appreciably increments response time. With the
aim of comparing results, we can highlight in this test that,
having 50 simultaneous requests, the medium time elapsed
for each is 5,871 ms. That is 38 % more than performing a
direct OCSP request. We consider this result acceptable if
we take into consideration the advantages offered by using
XKMS, as previously commented.
7.6 Real system analysis
Fig. 17 MISTRAL access control time components
7.5 Certificate authentication test

In this section, we are presenting a set of tests in order to determine the introduced overhead by authentication based on
certificates with respect to common login-password authentication. Furthermore, these tests also analyze the overhead
generated by using XKMS in the authentication process, for
validating end user certificates [2].
First of all, activating client authentication on tomcat,
we performed a test using the SSL protocol to authenticate end users based on an X509 Certificate. Additionally,
after receiving end user certificate, the Identity Provider
performs an OCSP request to the UMU-PKIv6 OCSP
responder, in order to check current status of the enduser certificate [36]. Results of this test are summarized in
Fig. 19.
Fig. 18 Erroneous requests in MISTRAL for access control test
123
In this section, a testbed based on a real scenario is described.

We have defined an example scenario inspired by the University of Murcia structure and real access control requirements. The objective of this testbed is to analyze a digital
library service where both students and teacher staff from
the University of Murcia could access digital books, fulfilling certain requirements and features allowed by the defined
architecture.
Being more concrete, in the University of Murcia there
are 34,720 students, 2,489 teaching staff, while the libraries
own a total of 817,717 books (i.e., resources in this context).
The main use case in this scenario would define an end user
(student or teacher) interested in getting a digital book from
the digital library.
In case this digital library were deployed, end users do
not want to have another set of username/password just for
accessing the digital library service, but they would want
to make use of their university credentials instead. There-
197
Fig. 19 Certificate authentication with OCSP validation
Fig. 20 Certificate authentication with XKMS + OCSP validation
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
takes the access control decision based on the roles of the

end-user accessing.
Following our example, roles are defined in a hierarchical
way. For students, the role student is the root role, followed
by the faculty (e.g., Faculty of Computer Sciences) and the
degree (e.g., Computer Engineering). Additional roles or levels of hierarchical roles are added in some circumstances,
for instance for Ph.D. or Master students which could have
special rights for performing certain actions. In general, for
resolving access control decisions of students, the privileges
of 3 or 4 roles are usually checked. For instance, for a Ph.D.
student of computer engineering, the privileges of the following roles are checked: member of Computer Engineering,
member of Faculty of Computer Sciences, student, and
Ph.D. student.
In a similar way, staff members have the role staff as root,
followed by teacher in case they are teacher, the faculty,
and finally, the department which they belong to. In general,
for resolving access control decisions of staff members, the
privileges of 4 roles are usually checked. For instance, the
following roles are taken into account for determining
the authorization decision of a teacher of Computer Sciences:
member of Computer Engineering, member of Faculty of
Computer Sciences, teacher, and staff.
It is worth mentioning that some students could also be
staff member, and therefore, both chains of roles should be
123
198
Table 5 Example real scenario results

Concurrent request
16
32
Average time elapsed (s) 0.162 0.286 0.458 0.759 1.477 2.632
taken into account when access control decision is being

achieved. Furthermore, some students could have delegated
rights from any of their teacher or advisors, so delegated
policies have to be evaluated when they try to get a resource.
Finally, we have estimated that an average of 3 access
control policies may be defined for each role of the system
in order to define the digital library access control requirements. For instance, some books could only be accessed by
certain faculties members, or other only could be accessed
by teachers while some others could only be accessed during
working hours, etc.
As in the previous test, the average time for accessing
a resource depends on the concurrent accesses to the digital library resources. Table 5 summarizes the average time
that takes to access a book of the digital library. Having the
amount of students, teacher, policies, and resources that we
have previously described, if 8 end users are concurrently
getting a resource from the digital library, they could have
a response time from of about 0.759 s, while managing the
request of 32 concurrent end users would usually take less
than 2.7 s.
8 Conclusion and future work

Current identity management initiatives are mainly based on
solutions that only have proved to be efficient in protecting
basic identity management scenarios. However, in scenarios
requiring advanced features, such as advanced authorization,
Level of Assurance, privacy management, or integration with
validation services, other issues still need to be addressed.
These features have been depicted as requirements in order
to compare current approaches, showing their limitations.
This proposal presents an infrastructure which extends
current approaches, in order to meet the presented requirements, providing added-value services to identity management systems. It adds elements to share tasks between
different providers, making use of the SAML standard to
exchange authentication and authorization information. In
this way, it provides attribute management and advanced
access control management in a controlled and unified way,
following the XACML standard. In addition, this solution
gives the end users more control over information that is
shared among providers, as well as it is complemented
with permission delegation capabilities. Even though this
infrastructure introduces new modules, it is compatible with
previous approaches such as Shibboleth.
123
In order to improve reliability in trust relationships

between providers, this architecture deploys integration
with certification and validation services, which asks the
PKI to get updated information about certificates status.
Additionally, desirable features have been also accomplished, such as system administration, including specific
modules to manage policies and end user information in a
friendly way.
The solution achieved in this work is an open-source
identity management system implementation. Although this
implementation adds functionality to existing solutions, performance testbeds have been executed showing that response
times remain reasonable.
As future work, we are working toward extending this
architecture to be applied in inter-domain scenarios, focusing on aspect such as attribute aggregation or, moreover, techniques which allow specifying a concrete Level of Assurance
to each attribute, depending on where it has been recovered.
It is also worth incorporating other user-centric aspects, such
as user control through information cards.
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)

14. Clercq, J.D.: Single sign-on architectures. In: InfraSec02 Proceedings of the International Conference on Infrastructure Security,
pp. 4058, Springer, Bristol
15. Dlera, G., Bernal, J., Lpez, G., Martnez, G.: UMU-XACML-Editor.
http://sourceforge.net/projects/umu-xacmleditor/
16. Dlera, G., Lpez, G., Martnez, G.: Mistral-idm. http://mistral-idm.
sourceforge.net
17. Erdos, M., Cantor, S.: Shibboleth-architecture DRAFT v05 (2002).
http://shibboleth.internet2.edu/docs/draft-internet2-shibbole-tharch-v05.pdf
18. Foundation, A.S.: Apache HTTP server benchmarking tool. http://
httpd.apache.org/docs/2.0/programs/ab.html
19. Fragoso Rodriguez, U., Laurent Maknavicius, M., Incera Dieguez,
J.: Federated identity architectures. In: Proceedings of 1st Mexican Conference on Informatics Security 2006 (MCIS 2006)
(2006)
20. Hallam-Baker, P.M., Mysore, S.H.: XML key management specification (XKMS 2.0). World wide web consortium, recommendation
REC-xkms2-20050628 (2005)
21. Hazelton, K.: EduPerson object class specification. Internet2 Middleware Architecture Committee for Education, Directory Working
Group (MACE-Dir), DRAFT revision (2006)
22. Hommel, W.: Using XACML for privacy control in SAML-based
identity federations. In: Dittmann, J., Katzenbeisser, S., Uhl, A.
(eds.) Communications and Multimedia Security, Lecture Notes in
Computer Science, vol. 3677, pp. 160169. Springer (2005)
23. Hommel, W., Munich, L.: An architecture for privacy-aware
inter-domain identity management. In: Ambient Networks: 16th
IFIP/IEEE International Workshop on Distributed Systems: Operations and Management, DSOM 2005, Barcelona, Spain, Oct 2426,
2005: Proceedings, p. 48. Springer (2005)
24. Hsieh, G., Foster, K., Emamali, G., Patrick, G., Marvel, L.: Using
XACML for embedded and fine-grained access control policy.
In: International Conference on Availability, Reliability and Security, 2009. ARES09, pp. 462468. IEEE (2009)
25. Hughes, J., Consulting, P., Maler, E.: Security Assertion Markup
Language (SAML) V2. 0 technical overview. OASIS SSTC working draft sstc-saml-tech-overview-2.0-draft-08 (2005)
26. Juels, A., Jakobsson, M., Jagatic, T.: Cache cookies for browser
authentication. In: IEEE Symposium on Security and Privacy, 2006,
pp. 5305. IEEE (2006)
27. Kataoka, T., Nishimura, T., Shimaoka, M., Yamaji, K., Nakamura,
M., Sonehara, N., Okabe, Y.: Leveraging PKI in SAML 2.0 Federation for Enhanced Discovery Service. In: SAINT, pp. 239242.
IEEE Computer Society (2009)
28. Kesselman, C., Foster, I.: The Grid: Blueprint for a New Computing
Infrastructure. Morgan Kaufmann, Los Altos, CA (2004)
29. Lawrence, K., Kaler, C., Nadalin, A., Goodner, M., Gudgin, M.,
Barbir, A., Granqvist, H.: Web Services Trust Language (WSTrust) 1.3. OASIS Standard (2007)
30. Liong, B.: Shibboleth attribute release policy editor. http://www.
federation.org.au/twiki/bin/view/Federation/ShARPE
31. Lockhart, H., Andersen, S., Bohren, J., Sverdlov, Y., Hondo, M.,
Maruyama, H., Nadalin, A., Nagaratnam, N., Boubez, T., Morrison,
K., et al.: Web Services Federation Language (WS-Federation).
Web services security specification (2006)
32. Lpez, G., Cnovas, O., Gmez, A., Jimnez, J., Marn, R.:
A network access control approach based on the AAA architecture and authorization attributes. J. Netw. Comput. Appl. 30(3),
900919 (2007)
33. Lopez, J., Oppliger, R., Pernul, G.: Authentication and authorization infrastructures (AAIs): a comparative survey. Comput. Security 23(7), 578590 (2004)
34. Maler, E., Reed, D.: The venn of identity: options and issues in
federated identity management. IEEE Security Privacy 6, 1623
(2008). http://doi.ieeecomputersociety.org/10.1109/MSP.2008.50
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

60. Wason, T., Alliance, L., Hodges, J., Kemp, J., Thompson, P.: Liberty id-ff architecture overview (2003)
61. Wayman, J.: Biometrics in identity management systems. IEEE
Security Privacy 6(2), 3037 (2008)
62. Zorn, G.: Microsoft PPP CHAP extensions, version 2. RFC 2759
(informational) (2000). http://www.ietf.org/rfc/rfc2759.txt
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.

Definition of An Advanced Identity Management Infrastructure

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Definition of An Advanced Identity Management Infrastructure

Caricato da

Copyright:

Formati disponibili

Int. J. Inf. Secur.

Definition of an advanced identity management infrastructure

Published online: 27 December 2012

Abstract In recent years, organizations are starting to

ples of these approaches, such as Shibboleth [17], Liberty

transfer authority to others to perform specific actions, for

G. Dlera Tormo et al.

Definition of an advanced identity management infrastructure

the identity providers should send the level of assurance

2.3 Authorization requirements

2.4 Administration requirements

G. Dlera Tormo et al.

it just provides basic authentication mechanisms, but external

Definition of an advanced identity management infrastructure

nor advanced web services. In current implementations, end

to trace which documents have been obtained by each user.

Table 1 Summary of how existing solutions meet the proposed requirements

Definition of an advanced identity management infrastructure

Fig. 1 MISTRAL architecture

G. Dlera Tormo et al.

MISTRAL Enabled Service Provider

Fig. 2 Service Provider architecture

tionship between the issuer and the recipient. These trust

4.1 Service Provider

Definition of an advanced identity management infrastructure

MISTRAL Identity Provider

Fig. 3 Identity Provider architecture

G. Dlera Tormo et al.

Fig. 4 Attribute Provider architecture

MISTRAL Authorization Provider

Fig. 5 Authorization Provider architecture

also in charge of evaluating the attribute delegation policies,

4.4 Authorization Provider

Definition of an advanced identity management infrastructure

However, since the Authorization Provider can also ask the

allow defining under which conditions that delegation is

4.6 Administration module

G. Dlera Tormo et al.

MISTRAL Administration Module

Fig. 6 Administration console architecture

For instance, end users can establish attribute release policies

These processes are grouped into security, authentication,

Definition of an advanced identity management infrastructure

Fig. 7 Authentication process

service allows recovering and validating digital certificates,

know the real identity of the user accessing their resources

5.2 Authentication requirements

tity Provider that an end user authentication is required, but

G. Dlera Tormo et al.

5.3 Authorization requirements

Definition of an advanced identity management infrastructure

Can this requester get

Has this end user

Fig. 8 Attribute recovery

end-user name or her email address. Either the Identity

the system management, achieved by the administrator, and

G. Dlera Tormo et al.

can intuitively manage their identity preferences similar to

Table 2 Fulfillment requirement table for MISTRAL

Yes, through Yes, carried

Definition of an advanced identity management infrastructure

G. Dlera Tormo et al.

Fig. 9 Overview of the administration web console