Electronic Business: Concepts, Methodologies, Tools, and Applications (4-Volumes) P228 pptx

2204
Secure Authentication Process for High Sensitive Data E-Services
)LJXUH7KHORJLQFRQ¿JXUDWLRQHQWU\LQWKHORJLQFRQ¿J[POIRUWKHDSSOLFDWLRQ
)LJXUH7KH:HE[POFRQ¿JXUDWLRQ¿OHHQWU\GHFODULQJWKHORJLQIRUP
2205
Secure Authentication Process for High Sensitive Data E-Services
Focusing on Pitagora’s Authentication process,
DIWHUWKHGH¿QLWLRQRIWKH6HFXULW\'RPDLQWKH
VHUYOHWVSHFL¿FDWLRQVGH¿QHDVWDQGDUGPHWKRGRI
F R Q ¿ J X U L QJW KHORJ L QSURFHVVIR U :H E D S SOLFD W LRQV
WKURXJKWKHVSHFL¿FDWLRQLQ7RPFDW¶V Web.xml
¿OHRIWKH85/RIWKHORJLQSDJHDQGWKHORJLQ
error page (see Figure 3).
By means of a standard JSP page, the user
could insert login and password that was sent to
WKHORJLQPRGXOHVSHFL¿HGLQWKH$&7,21WDJ
,Q WKLV FDVH WKHSUHGH¿QHGPHWKRGIRU VHUYOHW
form-based authentication j_security_check,
that accepted as parameters username (named
j_username) and password (named j_password)
DQGUHIHUUHGWRWKHVSHFL¿HG6HFXULW\'RPDLQ
was used.
This solution was, however, not fully satisfac-
tory for the goals of the project. Albeit application
server authentication gave some notable advan-
tages, as for instance no need of code customiza-
tion and clear separation between business and
security components and high reliability levels,
it raised a major problems: it did not allow dif-
ferent implementations for different applications,
binding all the services to an unique authentica-

tion process. Logically different applications
that, potentially, require different authentication
mechanisms with different requirements can-
not live with this solution that imposes a single
authentication approach for all the applications
deployed on the same application server.
For this reason, also this solution was not
adopted, since it did not provide a suitable envi-
ronment for Pitagora’s applications.
Component Level Authentication
To conclude the roadmap, the most adopted solu-
tion in current e-services scenario is described,
relying on the insertion of components responsible
for the authentication process at the top of the
structure depicted in Figure 1. In this manner,
there is a strict integration between business and
security components and it is possible to customize
the authentication process for single application
needs. This solution implements a decentralized
authentication mechanism that requires the inser-
tion of customized code inside the business com-
ponents to manage the communication protocols
with the requestor, validate the received requestor
F U H G H Q W L D O V Z L W K W K H X V H U S U R¿OHLQ IRU P D W L RQVWRUHG
in the local user repositories, and allow or deny
the access request.
Also if this decentralized approach implied
different security implementations focused
on services goals and allowed ad-hoc security
implementations for each service, there were

many drawbacks that suggested refusing this
solution:
• increase of costs and time spent for logon
to multiple services: for each service the
XVHUKDGWRSURYLGHVHUYLFHVSHFL¿FFUHGHQ-
tials;
• username/password proliferation: for se
-
curity concerns, the user was stimulated to
choose a different username/password for
each service and, hence, she had to man-
age, protect, and remember several of these
information pairs;
• increasing of administration cost and time:
administrators had to deal with multiple
SUR¿OHVUHSRVLWRULHVZLWKYDULDEOHVFKHPD
and variable authentication policies;
• usability problems: user had to interact with
multiple logon interfaces.
From the account management point of view,
this approach required an independent manage-
ment of accounts in each domain and the use of
different authentication mechanisms. Several
usability and security concerns had been raised,
leading to a rethinking of the logon process aimed
at co-ordinating and, where possible, integrating
user logon mechanisms and user account manage-
ment tools for different domains.
The description of the most widespread meth-
ods to implement an authentication infrastructure,

2206
Secure Authentication Process for High Sensitive Data E-Services
suggested that an optimal solution had not been
found out. In the following, the idea of adopting
an emergent solution, named Single Sign-On,
that seemed the most suitable approach for se-
curing authentication processes in e-service, is
put forward.
SINGLE SIGN-ON: A SOLUTION
FOR SECURING AUTHENTICATION
PROCESS
A service/architecture that provides the requested
coordination and integration of access control pro-
cesses is called Single Sign-On (SSO) (Galbraith
et al. 2002; Single Sign-On, The Open Group,
2005) (see Figure 4). The advantages given by the
introduction of SSO architecture in a pre-exist-
ing multiservices intra-domain scenario could be
summarized as follows:
•reduction of:
(1) time spent by the users dur-
ing logon operations to individual domains,
(2) failed logon transactions, (3) time used
to logon to secondary domains, (4) costs
DQGWLPHXVHGIRUXVHUVSUR¿OHVDGPLQLVWUD-
tions;
• improvement to users security: the user has
to manage only a couple of username/pass-
word;
 VHFXUHDQGVLPSOL¿HGDGPLQLVWUDWLRQZLWK

a centralized administration point, system
administrators reduce the time spent to add
and remove users to the system or modify
their access rights (authorization);
• improvement of security through the en
-
hanced ability of system administrators to
maintain the integrity of user account con-
¿JXUDWLRQLQFOXGLQJWKHDELOLW\WRFKDQJH
an individual user’s access to all system
resources in a coordinated and consistent
manner;
• improvement of services usability.
From the point of view of economic feasibil-
ity, most available Return-On-Investment (ROI)
Figure 4. User Single Sign-On to multiservice domain
2207
Secure Authentication Process for High Sensitive Data E-Services
models available for SSO focus on cost reduction
rather than on the alleviation of damages, for
example, deriving from intrusions. While this is
a rather conservative approach, experience has
shown that even minor achievements like reduc-
ing Help Desk calls by eliminating password
SUREOHPVFDQJHQHUDWHVLJQL¿FDQWVDYLQJV6WXGLHV
by Forrester Research (www.forrester.com) con-
¿UPWKDWHOLPLQDWLQJSDVVZRUGFKDRVFDQOLJKWHQ
internal Help Desk burden by 50%. Anectodical
evidence has been brought up of a case where a
Single-Sign-On solutions eliminated 95% of all

password-related support calls. Helping users
gain quick, secure access to password-protected
applications can save everyone many minutes
of wasted time. Also, whenever sales force and
executives travel, they still can get access to the
applications they need. All these factors create a
boost in productivity. Also, integration and main-
tenance of SSOs being minimal, invest ments in
existing infrastructure are preserved. The Total
Cost of Ownership (TCO) for SSOs compares
favorably with other solutions on the market.
As clearly highlighted by the above list, many
of the advantages provided by a SSO solution re-
ÀHFWW KHG U D Z ED FN VU D L VH GE\WKHSUHY LRXVV ROXW LRQV
based on security customization at component
level. In the SSO approach, the primary domain
is responsible for collecting and managing all
user credentials and information used during
the authentication process, both to the primary
domain and to each of the secondary domains that
the user may potentially require to interact with.
This information is then used by Single Sign-On
services within the primary domain to support the
transparent authentication to each of the second-
ary domains whereby the user actually requests to
interact. The information provided by the user to
the primary domain can be used in several ways
to logon to secondary domains:
• directly
: the user information is forwarded

to a secondary domain as part of a secondary
logon;
• indirectly
: the user information is used to
U H W U LHYH R W K H U X V H U L G H Q W L ¿ F D W L RQD QGFUHGHQ -
tials information, stored within the Single
Sign-On management information base.
The retrieved information is then used for
a secondary domain logon operation;
•immediately
: a session is established with
a secondary domain as part of the primary
domain session initialization. Client ap-
plications are automatically invoked and
communications performed at the time of
the primary logon operation;
•temporarily
: information is stored or cached
and used when the secondary domain ser-
vices are requested.
SSO provides a uniform interface to user
accounts management interface, allowing a
coordinated and synchronized management of
component domains.
The aim of any SSO solution should be mak-
ing single sign-on to multiple sites as secure as
giving a username and password at each site. To
achieve this goal, different security issues need
to be taken into consideration.
First, SSO solutions should be based on strong

authentication mechanisms; with the traditional
password-based mechanism, the theft of a user
password could compromise the whole system and
even if the passwords are not stolen, storing pass-
words on a single server makes it a single point of
attack. Therefore, for high security environments,
DSDVVZRUGEDVHGPHFKDQLVPFDQQRWEHVXI¿FLHQW
DQGDFHUWL¿FDWHEDVHGDXWKHQWLFDWLRQHJEDVHG
RQ;FHUWL¿FDWHVLVSUHIHUDEOH
Another important aspect is related to the
security of the server where the authentication
LQIRUPDWLRQHJSDVVZRUGVRUFHUWL¿FDWHVLV
stored. A robust SSO implementation should
ensure the security of that server to prevent con-
¿GHQWLDOG DWDIURPEHLQJDFFHVVHGE\DPDOLFLRXV
party. Encryption is a viable solution for securing
the storage of the user credentials.
2208
Secure Authentication Process for High Sensitive Data E-Services
A SSO solution should then be designed to
guarantee that the key information cannot be
determined. For instance, keys could be stored
on a smart card or derived each time the user logs
on using the password.
The security of user’s credentials should be
preserved also during their transmission. It is
therefore mandatory to use SSL-encrypted con-
nections to protect the authentication information,
transmitted during the authentication process.
Finally, a particular challenge in SSO systems

is to provide for complete retrieval of identity
information while preserving its privacy. Innova-
tive SSO systems should be able to help the user
in determining the consequences of releasing her
identities to a counter-part in terms of potential
danger to her privacy.
Criteria are needed for evaluating tools with
respect to the privacy features they are expected
to enforce. This problem could be addressed by
obscuring the identity of each user so that to each
participant is presented a unique pseudonym.
SSO solution clearly seemed to be suitable to
Pitagora Project needs, addressing all require-
ments of security, reliability, and performance.
Many implementations have been presented to
the Internet community such as, the Central
Authentication Service developed by Yale Uni-
versity (Aubry, Mathieu & Marchal, 2004; Central
Authentication Service, 2004), Liberty Alliance
project (Liberty Alliance Project, 2005; Galbraith,
et al. 2002), a business and technology consortium
of more than 130 global organizations that was
constituted in 2001, and its SSO implementation
SourceID (SourceID, 2005), founded in 2001 by
Ping Identity Corporation Company, Shibboleth
(Shibboleth Project, 2005), an open source imple-
mentation, of Internet2/MACE, Java Open Single
Sign-On (JOSSO) (Java Open Single Sign-On,
2005), an open source J2EE-based SSO infra-
VWUXFWXUHKRVWHGE\6RXUFH)RUJHQHWDQG¿QDOO\

Microsoft Passport (Microsoft .NET Passport,
2005), one of the most known commercial Single
Sign-On implementation.
Central Authentication Service
Central Authentication Service (CAS) (Aubry,
Mathieu & Marchal, 2004; Central Authentica-
tion Service, 2004) is one of the frameworks that
imposes to open source community as an optimal
solution in SSO scenario, and consequently also
in Pitagora’s environment.
Central Authentication Service was developed
b y Ya l e U n i v e r s i t y t h a t i m p l e m e n t s a S S O m e c h a -
nism to provide a Centralized Authentication to a
single server through HTTP redirections. When an
unauthenticated user sends a service request, this
request is redirected from the application to the
authentication server and back to the application
if the user has been authenticated. The informa-
tion is forwarded by the authentication server to
the application during the redirections by using
VHVVLRQFRRNLHVVHHWKHGDWDÀRZLQ)LJXUH
CAS is composed of Java servlets running
over any servlet engine and provides a Web-
based authentication service. Its more interesting
characteristics are security, proxying features,
ÀH[LELOLW\UHOLDELOLW\DQGLWVQXPHURXVFOLHQWOL-
braries. In particular, the most important security
features are three:
++++
The CAS Server is therefore the only entity

that manages passwords to authenticate users and
WUDQVPLWVDQGFHUWL¿HVWKHLULGHQWLWLHV
CAS implementation, however, was not com-
pletely suitable for Pitagora’s needs and, hence
it was extended with the integration of strong
DXWKHQWLFDWLRQ PHFKDQLVPV DQG GLJLWDO FHUWL¿-
cates, leading to the implementation of CAS++,
as described in the following section.
CAS++
An improved version of CAS architecture has
EHHQGHYHORSHGWRIXO¿ODOOWKH3LWDJRUD¶VRSHQ
issues and requirements. This solution was named
2209
Secure Authentication Process for High Sensitive Data E-Services
CAS++ and it was an open source SSO system,
developed by Siemens Mobile Communication
S.p.A. and University of Milan, Department of
Information Technology of Crema (DTI), based
RQW KHX VHRI FHU WL¿FDWHVD QGI X OO\LQWHJ U DWH GZLW K
the JBoss security layer.
CAS++ solution integrated the CAS system
with the authentication mechanism implemented
b y a P u b l i c K e y I n f r a s t r u c t u r e ( PK I ) . C A S + + u s e d
standard protocols such as HTTPS, for secure
communications between the parties, and X.509
GLJLWDOFHUWL¿FDWHVIRUFUHGHQWLDOVH[FKDQJH
It is a fully J2EE compliant application in-
tegrable with services coded with every Web-
based implementation language. It enriched the
traditional CAS authentication process through

WKHLQWHJ UDW LRQRI ELRPHW U LFLGHQWL¿FDWLRQE\ ¿Q-
gerprints readers) and smart card technologies.
7KH VWURQJ DXWKHQWLFDWLRQSURFHVVÀRZ ZDV
composed by the following steps (see Figure 6):
 WKHXVHUUHTXHVWVDQLGHQWLW\FHUWL¿FDWHWR
WKH&$&HUWL¿FDWLRQ$XWKRULW\
2. the user receives from the CA a smart card
WKDW FRQWDLQV D ; LGHQWLW\ FHUWL¿FDWH
signed with the private key of the CA, that
FHUWL¿HVWKHXVHULGHQWLW\7KHFRUUHVSRQG-
ing user private key is encrypted with a
symmetric algorithm (e.g., 3DES) and the
key contained inside the smart card can be
decrypted only with a key represented by
XVHU¿QJHUSULQW.)LQJHUSULQW8VHU
 WRDFFHVVDVHUYLFHWKHSXEOLFNH\FHUWL¿FDWH
along with the pair username/password,
is encrypted with the CAS++ public key
(KPuCAS++) and sent to CAS++;
 &$6 GHFU\SWV WKH FHUWL¿FDWH ZLWK LWV
SU LYDWHN H\ YHU L¿H V W KHV LJ QDW X UHRQ W KHF H U-
WL¿FDWHZLWKWKH&$SXEOLFNH\DQGYHUL¿HV
WKHYDOLGLW\RIWKLVFHUWL¿FDWHE\LQWHUDFWLQJ
with the CA;
5. CAS++ retrieves from the CA information
DERXWWKHYDOLGLW\RIWKHXVHUFHUWL¿FDWH
 LIWKHFHUWL¿FDWHLVYDOLG&$6H[WUDFWVWKH
information related to the user, creates the
ticket (TGC, Ticket Granting Cookie) and
Figure 5. CAS Authentication Flow (from /consortium/espace/SSO 1B/cas/

eunis2004/cas-eunis2004-article.pdf)
2210
Secure Authentication Process for High Sensitive Data E-Services
returns it to the user encrypted with the pub-
lic key of the user (KPuUser). At this point,
to decrypts the TGC, the user must retrieve
the private key stored inside the smart card
E\PHDQRIKHU¿QJHUSULQW$VVRRQDVWKH
card is unlocked, the private key is extracted
and the TGC decrypted. This ticket will be
used for every further access, in the same
session, to any application managed by the
CAS++ Single Sign-On server.
For every further access in the session, the
user was authenticated by the service providing
only the received ticket (TGC, Ticket Granting
Cookie). Note that, to improve security, any com-
munication between entities (PKI, CAS++ and
User) was based on SSL (Security Socket Layer).
The advantages of this mechanism were that the
account management was centralized and sepa-
rated by the real application and the user had not
to remember username and password, since they
ZHUHORJLFDOO\FRQWDLQHGLQWKHFHUWL¿FDWHXVHG
during authentication phase. The introduction of
VPDUWFDUGVDQG¿QJHUSULQWVUHDGHUVGLGQRWDIIHFW
the system performance and did not require huge
additional costs.
CAS++ addressed authorization managing the
association of users’ identity with roles and leav-

LQJWRWKHVSHFL¿FVHU YLFHWKHWDVNRIGH¿QLQJDQG
managing the authorization policies (who can or
cannot execute which action on which resource).
CAS++ returned to the services the association
between user and role.
Federation
CAS++ is however not the best solution for
Pitagora’s needs. For instance, the concept of
federation (Galbraith et al. 2002), strictly related
to the concept of trust, could integrated in the
CAS++ solution because introduced the concept
of dynamic joining of SSO systems. The Liberty
Alliance protocol is the most representative ex-
DPSOHRIIHGHUDWLRQ,WZDVLPSOHPHQWHGWRGH¿QH
a federated SSO system. The Liberty Alliance
SURWRFROGH¿QHGWKUHHPDLQDFWRUV(1) Principal,
)LJXUH6LQJOH6LJQ2QDXWKHQWLFDWLRQZLWKFHUWL¿FDWH
2211
Secure Authentication Process for High Sensitive Data E-Services
that is the services requestor, characterized by an
LGHQWLW\SUR¿OH(2) Identity Provider (IdP), that
provides authentication assertions to the Princi-
pal; and (3) Service Provider (SP), that supplies
services to the Principal.
The Liberty infrastructure is based on the con-
cepts of Circle of Trust and Identity Federation:
• Circle of Trust
is a set of SPs and IdPs that
have trusted business relationships, based
on Liberty architecture, and operational

agreements and whereby can transact busi-
ness in a secure and apparently seamless
environment.
•Identity Federation
represents the linked
³ORFDOLGHQWLWLHV´WKDWXVHUVKDYHGH¿QHGIRU
multiple SPs. When an user authenticates to
a particular service, the provider supplies the
user with an assertion of the authentication
event. An identity federation is said to ex-
ist between the provider and other service
providers, when they are in the same Circle
of Trust. The authentication assertion is
used to link user identity across business
boundaries.
A user should be able to select the services
that the user wants to federate and defederate
to protect user privacy and to select the services
to which the user will disclose authorization as-
VHUWLRQV 7KLV PHFKDQLVP FRXOG DOORZ D ³XVHU
customization” of the Circle of Trust.
Focusing on the authentication process, the
¿UVW VWHS WR HQDEOH IHGHUDWHG 6LQJOH 6LJQ2Q
between all the providers is to establish a Circle
of Trust between IdPs and SPs. Single Sign-On
implementation in Liberty protocol is based on
the assumption that the user has already feder-
ated at least one Service Provider with an Identity
Provider of the same Circle of Trust. Before that
a user can access a resource/service, the user has

to logon at the Identity Provider. The user has to
provide the username and password and, if authen-
tication succeeds, the Identity Provider shows the
federated Service Providers available for the user.
After the selection, the user is redirected to the
Service Provider. The Service Provider sends then
a request to the Identity Provider for authentica-
WLRQFRQ¿UPDWLRQ,IWKH,GHQWLW\3URYLGHUVHQGV
through an HTTP redirection transparent for the
user, a positive response, the user gains access
to the Service Provider. If the Identity Provider
sends a negative response, the user is redirected
to authenticate again using the Federation Single
Sign-On process. This solution added to CAS++
implementation could give a complete answer that
IXO¿OVDOO6LHPHQVVHFXULW\UHTXLUHPHQWV
CONCLUSIONS
$URDGPDSWKDWGHVFULEHGDQGUHFDOOHGWKHÀRZ
that brought to the adoption of single sign-on
approach to secure critical remote applications,
managing high sensitive data and services, is
presented. First, three methodologies, currently
adopted to secure critical e-services, have been
described: operating system level authentica-
tion, application server level authentication, and
components level authentication. Second, the case
provided a description of single sign-on technol-
ogy. Then, CAS++ system is introduced, and,
¿QDOO\LWLVGHVFULEHGKRZLWFRXOGEHLPSURYHG
by mean of federation approach.

REFERENCES
Anisetti, M., Bellandi, V., Damiani, E. & Reale, S.
(2005). Localize and tracking of mobile antenna
in urban environment. In Proceedings of Inter-
national Symposium on Telecommunications,
Shiraz, Iran.
Ardagna, C.A., Damiani, E., Frati, F. & Montel,
M. (2005). Using open source middleware for
2212
Secure Authentication Process for High Sensitive Data E-Services
securing e-Gov applications. In Proceedings of
the First International Conference in Open Source
Systems(OSS 2005), 172-178, Genova, Italy.
Aubry, P., Mathieu, V., & Marchal, J. (2004).
ESUP-Portal: Open source single sign-on with
CAS (Central Authentication Service). In Pro-
ceedings of EUNIS04 - IT Innovation in a Chang-
ing World, Bled, Slovenia.
Bettini, C., Jajodia, S., Sean Wang, X. & Wije-
sekera, D. (2002). Provisions and obligations in
policy management and security applications.
In Proceedings of the 28th VLDB Conference,
Honk Kong, China.
Central Authentication Service (2004). Retrived
August 6, 2006, from nceton.
edu:9000/ display/CAS
Cremonini, M., Corallo, A., Damiani, E., De
Capitani di Vimercati, S., Elia, G. & Samarati,
P. (2005). Security, privacy, and trust in mobile
systems. In M. Pagani (Ed.), Mobile and wireless

systems beyond 3G: Managing new business
opportunities. (pp. 312-341) Hershey, PA: IRM
Press
Damiani, E., Khosla, R. & Grosky, W. (2003).
Human-Centered e-business. MA: Kluwer Aca-
demic Publishers.
Damiani, E. & Montel, M. (2005). Open source
HOHFWURPDJQHWLF ¿HOG PRQLWRULQJ DV HJRYHUQ-
ment service. In Proceedings of the Conference
on e-Government Electronic Democracy: The
challenge ahead (TCGOV 2005), Bozen, Italy.
Feldma n, S. (2000). The changi ng ga ce of e-com-
merce. IEEE Internet Computing, 4(3), 82–84.
Fleury, M. & Scott, S. (2003). The JBoss Group:
JBoss administration and development third edi-
tion (3. 2 . x S e r i e s). I n d i a n a p o l i s , I N: J B o s s G r oup,
LLC, Sams Publishing.
Galbraith, B., Hankison, W., Hiotis, A., Janakira-
man, M., Prasad, D. V., Trivedi, R., & Whitney,
D., (2002). Professional Web services security.
Wrox Press, Birmingsham, UK.
Java Open Single Sign-On (JOSSO). (2005). Re-
trieved August 6, 2006, from http://sourceforge.
net/ projects/josso/
JBoss (2005). Open source application server.
Retrieved August 6, 2006, from http://www.
jboss.org
Liberty Alliance Project. (2005). Retrieved August
6, 2006, from />Microsoft .NET Passport. (2005). Retrieved
August 6, 2006, from

Montel, M. (2004). Security aspects in a Web ac-
cessible monitoring system for the environmental
impact of mobile networks of 3rd generation.
Unpublished bachelor degree thesis, Free Uni-
versity of Bozen.
Shibboleth Project. (2005). Retrieved August 6,
2006, from />Single Sign-On, The Open Group. (2005). Re-
trieved August 6, 2006, from n-
group.org/ security/sso/
SourceID Open Source Federated Identity Man-
agement. (2005). Retrieved August 6, 2006, from
/>ENDNOTES
1
J2EE (Java 2 Platform, Enterprise Edition) is
a platform for building distributed enterprise
D S SOLFDW LRQV-((F R P S U LVHVDVSHFL¿FDWLRQ  
reference implementation and set of testing
suites.
2
EJB (Enterprise Java Bean) is a software
component, which provides a pure Java
2213
Secure Authentication Process for High Sensitive Data E-Services
environment for developing and running
distributed applications. EJBs are written as
software modules that contain the business
logic of the application.
3
The Java Naming and Directory Interface
( J N D I ) i s p a r t of t h e J a v a p l a t f o r m , p r o v i d i n g

WKHDSSOLFDWLRQVZLWKDQXQL¿HGLQWHUIDFHWR
multiple naming and directory services.
This work was previously published in the Journal of Cases on Information Technology, edited by M. Khosrow-Pour, Volume
9, Issue 1, pp. 20-35, copyright 2007 by IGI Publishing (an imprint of IGI Global).