ArticlePDF Available

Abstract

Single sign-on (SSO) is a mechanism that uses a single action of authentication to permit an authorized user to access all related, but independent software systems or applications without being prompted to log in again at each of them during a particular session. It reduces the risk for the administrators to manage users centrally, increases user productivity by allowing mobility and allows users to access multiple services or applications after being authenticated just once. This doesn’t mean that the SSO system unifies account information for all services, applications and systems, rather it hides such a multiplicity of account information into a single account that the user needs to login. Once the user login, the SSO system generates authentication information accepted by the various applications and systems. The concept of SSO can be used within an Intranet, Extranet or Internet. This report explores various methods of SSO and the advantages by adopting it. It also discusses on implementing various types of SSO and the protocols that are being used.
Procedia Technology 4 ( 2012 ) 134 139
2212-0173 © 2012 Published by Elsevier Ltd.
doi: 10.1016/j.protcy.2012.05.019
C3IT-2012
A Survey on Single Sign-On Techniques
V. Radhaa, D. Hitha Reddya
aInstitute for Development and Research in Banking Technology,
Road #1, Castle Hills, Masab Tank, Hyderabad – 500 067 (A.P), INDIA
Abstract
Single sign-on (SSO) is a mechanism that uses a single action of authentication to permit an authorized
user to access all related, but independent software systems or applications without being prompted to log in again at
each of them during a particular session. It reduces the risk for the administrators to manage users centrally,
increases user productivity by allowing mobility and allows users to access multiple services or applications after
being authenticated just once. This doesn’t mean that the SSO system unifies account information for all services,
applications and systems, rather it hides such a multiplicity of account information into a single account that the user
needs to login. Once the user login, the SSO system generates authentication information accepted by the various
applications and systems. The concept of SSO can be used within an Intranet, Extranet or Internet. This report
explores various methods of SSO and the advantages by adopting it. It also discusses on implementing various types
of SSO and the protocols that are being used.
© 2011 Published by Elsevier Ltd. Selection and/or peer-review under responsibility of C3IT
Keywords: Single Sign-On, OpenID Provider, Relying Party, Kerberos, SAML, OpenID, BrowserID.
1. Introduction
In present digital world, users have to access multiple systems for carrying out their day-to-day
business activities. As the number of systems increase, the number of credentials for each user increases
and thereby possibility of losing or forgetting them also increases. Single Sign-On can be used to solve
many problems related to multiple credentials for different applications. Single Sign-on access to the
main authentication centre enables users to get access to all other resources available. SSO helps to
improve user and developer productivity by avoiding the user to remember multiple passwords and also
reduce the amount of time the user spend on typing various passwords to login. SSO also simplifies the
administration by managing single credentials instead of multiple credentials. It makes easy to manage
the rights of a user arriving, changing function in or leaving the company, to quickly integrate added
applications, delegate access rights during holidays without increasing the helpdesk's workload.
2. Types of SSO
The various types of SSO shown in Fig: 1, fall under different categories, based on where they
are deployed (Intranet, Extranet, Internet); how they are deployed (architecture – Simple, Complex); the
credentials they use (token, certificate..) and the protocols they use (Kerberos, SAML,
OpenID..).Following picture shows the types of SSO and their classification:
Available online at www.sciencedirect.com
135
V. Radha and D. Hitha Reddy / Procedia Technology 4 ( 2012 ) 134 – 139
Fig 1: Classificat
i
2.1. Where th
e
2.1.1. Intrane
t
Ente
r
enterprise. E
S
p
assword to s
where auto
m
authenticatio
n
2.1.2. Extran
e
Mult
i
business
p
art
n
the users nee
d
2.1.3. Interne
t
Web
deployed on
w
2.2. How they
SSO architect
u
2.2.1. Simple
S
Sim
p
This architect
u
2.2.2. Compl
e
Com
p
for each user.
2.3. Types of
C
i
on of Single Sign
y are deploye
or Enterpris
prise single
S
SO is desig
n
ign into multi
atic login is
n
.
e
t or Multi-do
m
i
-domain SSO
n
ers’ applicati
o
not login aga
t
or Web SSO:
SSO is a br
w
eb servers.
are deployed:
u
res are divid
e
SO architect
le SSO make
re could be e
x SSO archite
p
lex SSO use
s
redentials U
-On
d
:
e
SSO (ESSO):
s
ign on (ESS
O
ed to minimi
p
le applicatio
n
not possible
m
ain SSO:
allows conne
o
ns. The user
c
n using differ
o
wse
r
-
b
ased
m
e
d
b
ased on th
e
u
re:
use of single
sily impleme
c
ture:
s
multiple auth
e
s
ed
) allows co
e the numbe
s. It automati
Each deskt
c
ting to multip
an login into
nt credentials
m
echanism,
p
r
o
ir deploymen
authentication
ted in homog
ntication aut
n
necting to
m
of times th
ally logs use
p/laptop is
le systems wi
ne enterprise
.
viding access
t
as Simple SS
O
authority, sin
g
neous LAN a
h
orities with si
n
ultiple syste
t a user mus
s in, and acts
iven a toke
t
hin the same
e
and access re
with single l
O
and Comple
x
le set of cred
d intranet en
n
gle or multip
l
s within the
type their I
as a passwor
that handl
nterprise and
s
ources of the
o
gin to applic
x
SSO as follo
ntials for eac
v
ironment.
l
e sets of cred
e
same
D
and
d
filler
e
s the
a
ll the
other,
ations
ws:
h
user.
e
ntials
136 V. Radha and D. Hitha Reddy / Procedia Technology 4 ( 2012 ) 134 – 139
Complex SSO can further be classified as two basic schemes, Complex SSO with a single set of
credentials and Complex SSO with multiple sets of credentials.
2.3.1. Complex SSO with a single set of credentials:
Complex SSO using single set of credentials can be accomplished in two ways i.e. Token-based
and Public Key-based as follows:
2.3.1.1. Token-based SSO system:
In this SSO system, a user submits the credentials to the token-based authentication authority, in
which the credentials have been checked with its credential database. If the user credentials match, then
the user is returned with a token. When the user wants to access an application server which is governed
by second authentication authority, the same token is delivered to get a ticket to access the application
server. Success of this process relies on the trust the authentication authorities have among themselves.
2.3.1.2. Token-based SSO in HTTP environment:
The Token-based SSO could be implemented by using cookies in HTTP environment. A cookie
is a set of information given to the web browser by the web server and is stored in the client machine.
Cookies used for authentication can be encrypted to keep them secret. The server could then retrieve the
cookie and provide customized service to the client. Kerberos system provides basis for constructing
secure SSO in network environment, however, it needs client side infrastructure and configuration. In
HTTP-enabled environment, cookies could be used to construct SSO system and no extra installation or
configuration is necessary. The biggest difference between Kerberos system and Cookies-enabled SSO
system is that the former uses Remote Procedure Calls to transport authentication tickets, while the latter
uses cookies to play the role of tokens.
2.3.1.3. PKI-based SSO system:
In PKI based SSO, the servers/resources and users authenticate each other by using their
respective key pairs. Users can authenticate the servers by challenging the servers to decrypt any
message they send which is encrypted by the public key of the server. Same way, servers can
authenticate the user by challenging him to decrypt the message they send which is encrypted by the
public key of the user. As the real owner of the private key only can decrypt, the mutual authentication
i.e. server authenticating the user and vice-versa happens. The certifying authorities of users and servers
can be different and if they are different there has to be trust among the certifying authorities.
2.3.2. Complex SSO with multiple sets of credentials:
2.3.2.1. Credential Synchronization:
The multiple sets of credentials needed to access multiple systems are masked by a single set of
credentials to give an illusion that users need to remember only the single set. The synchronization
software relieves the user from changing the credentials in all systems as and when the policy forces, by
automatically forwarding the change request to all concerned authentication servers. eg: Pass Go
2.3.2.2. Client-side credential caching:
It allows users to store sensitive credentials like log on information (ex: user IDs and passwords)
required for the websites or resources they access in a network. These credentials are stored in special
folder called vaults. With this stored information, user’s system can automatically log on securely to the
websites and the computers on their network automatically without requiring them to remember the
137
V. Radha and D. Hitha Reddy / Procedia Technology 4 ( 2012 ) 134 – 139
credentials all the time. Vaults can store all sorts of credentials like passwords, certificates, tokens etc.
(eg: Windows Credential Manager).
2.3.2.3. Server-side credential caching: The Server-Side Credential Caching mechanism is same as
Client-side Credential Caching architecture, with only difference being the credentials stored in a server
instead of the client. It uses a central server to take on the task of administering all the different
passwords and providing the needed information directly to the application asking for them. Eg: (CA
Etrust SSO)
2.4. Single sign-on Protocols:
In this section we will discuss different protocols that are used on simple and complex SSO architectures.
2.4.1. Kerberos authentication Protocol:
Kerberos is a classical implementation of Token-based distributed authentication protocol. The
whole process is divided into three parts among four entities. The four entities are 1) Client – the one
who want to access resources 2) Authentication Server (AS) – the one who can authenticate the clients
and resources 3) Ticket Granting Server (TGS) – the one who gives tickets to access resources and 4)
Application Server (S) – a resource to whom the access is requested. The three processes are 1)
Authentication Request and Response: in which the client using its credentials gets authenticated with
AS and gets a key to securely communicate with TGS 2) Ticket Granting Request and Response: in
which the client using the previously secured key from AS, requests TGS to get a ticket to access S and
3) Application Request and Response: in which the client uses the ticket it got from TGS to securely
communicate with S. The first process where the credentials are required is completed by client only
once and there after the 2nd and 3rd processes keep repeated as and when the client has to access other
resources.
2.4.2. Security Assertion Markup Language:
Security Assertion Markup Language (SAML) is an XML-based open standard for exchanging
authentication and authorization data between security domains, i.e., an identity provider and a service
provider. Using SAML, an online service provider contacts an online identity provider which
authenticates users who are trying to access secure content. SAML doesn’t specify how to authenticate a
user; rather it defines a way how to exchange the authentication and authorization data once the user is
authenticated. SAML is nothing more than a series of XML-based messages called Assertions that detail
whether users are authenticated (Authentication Assertion), what kind of rights, roles and access
(Attribute Assertion) they have and how they can use data and resources (Authorisation Assertion) based
on those rights and roles. It uses HTTP, SMTP, FTP and SOAP, among other protocols and technologies
to transmit these assertions.
2.4.3. OpenID:
Open ID is a decentralized authentication protocol. OpenID consists of three main entities: 1)
The OpenID Identifier: A String of text or an e-mail address that uniquely identifies the user; 2) The
OpenID Relying Party (RP): A Web application or service provider that wants proof that the end user
owns the said Identifier and 3) The OpenID Provider (OP): A central server that issues, stores and
manages the OpenID identifiers of users. Relying Parties rely on this provider for an assertion that the
end user owns the said Identifier. There are mainly four methods used in OpenID Protocol: 1.Discovery,
2.Authentication, 3.Association, 4. Verification.
Discovery:
138 V. Radha and D. Hitha Reddy / Procedia Technology 4 ( 2012 ) 134 – 139
End user initiates authentication by presenting a User-Supplied Identifier to the Relying Party
via their browser. RP performs discovery (Discovery) on it and establishes the OP Endpoint URL which
is used by user for authentication.
Authentication:
RP redirects the end user's browser to the OP with an OpenID Authentication request. OP
establishes whether the end user is authorized. OP redirects the end user's browser back to the RP with
either an assertion that authentication is approved or a message that authentication failed.
Association:
RP and OP establish an association with a shared secret established using Diffie-Hellman Key
Exchange. OP uses this association to sign subsequent messages and RP to verify those messages; this
removes the need for subsequent direct requests to verify the signature after each authentication
request/response.
Verification:
RP verifies the information received from OP including checking the Return URL, verifying the
discovered information, checking the nonce, and verifying the signature by using either the shared key
established during the association or by sending a direct request to the OP.
4.4. BrowserID:
BrowserID is a decentralized identity system through which users can prove the claim of their
email addresses allowing user’s login into any website on the Internet using single password. It avoids
site-specific usernames and passwords, an alternative for ad-hoc application level authentication. It
implements Verified Email Protocol built by Mozilla, which offers streamlined experience. BrowserID
consists of three main concepts: 1.Primary Authorities, 2.Relying Parties, 3. Secondary Authorities and
the User Agent i.e. user’s Browser.
xPrimary Identity Authorities (Primary): A Service which provides the user with an identity in
the form of an email address. It is an email provider like Yahoo! mail or gmail, builds BrowserID
support.
xRelying Parties (RPs): Sites that use BrowserID for authentication.
xThe Implementation Provider (IP): This is the user's web browser with native support for
BrowserID, or else browserid.org serves web resources that implement the client portion of the
system. It implements key management, required algorithms and serves as a Secondary Identity
Authority.
BrowserID can be implemented by the following 3 steps:
1. Certificate Provisioning: Certificate Provisioning is the process in which a Primary verifies the
user’s email addresses and issues a signed certificate that proves user’s ownership of that email
2. Assertion Generation: Assertion Generationis the process in which a user's browser produces
an assertion that proves that a user owns given emails address.
3. Assertion Verification: Assertion Verification is the process in which a Relying Party can
verify that an assertion of a user's ownership of a certain email is valid.
7. Conclusion
Single sign on undoubtedly makes it easier and safer by reducing to only one account per user
for all services, number of passwords, central management of roles to define resources access control. It
can be very beneficial to end-users, administrators and help desk. Single sign-on can gain much more
importance with the emerging Cloud computing technology providing ICT services and also it reduces
the chances of phishing attacks but as single sign on gives access with one login, it should be
implemented in a secure way. Single sign on has its strengths and weaknesses and one must carefully
estimate the use of the system and the resources available for its deployment and management before
choosing SSO solution or else it can create a huge vulnerability in an organizations security if it’s not
implemented properly.
139
V. Radha and D. Hitha Reddy / Procedia Technology 4 ( 2012 ) 134 – 139
References
1. Elisa Bertino, Kenji Takahashi. Identity Management: Concepts, Technologies and systems. 685 Canton
StreetNorwood,MA02062,ArtechHouse,2011;55-9,77-9,86-7,98-100,119. http://books.google.co.in/books?id=UrmD-
Gxt-8IC&printsec=frontcover#v=onepage&q&f=false.
2. Colin Robbins, Edward Hamilton. Successfully deploying Single Sign-On (SSO) within an outsourced Environment.
http://www.insight.co.uk/files/whitepapers/Single Sign on (White paper).pdf.
3. Jan De Clercq, Security Consultant HPCI Technology Leadership Group Hewlett-Packard. Single Sign-On
Architectures. http://www.esat.kuleuven.be/cosic/seminars/slides/SSO.pdf.
4. Web Single Sign-On System for WRL Company. Si Xiong, Department of Internetworking, Royal Institute of
Technology (KTH), Sweden; 2005; http://web.it.kth.se/~johanmon/theses/xiong.pdf.
5. Two SSO Architectures with a Single Set of Credentials. http://www.cs.auckland.ac.nz/courses/compsci72
5s2c/archive/termpapers/zlu.pdf.
6. Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0 OASIS Standard, OASIS;
2005. http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf.
7. OpenID Foundation website. http://openid.net/.
8. BrowserID by Mozilla. https://browserid.org/.
... Single sign-on (SSO) application under inter-cloud enables users to authenticate only once and get access to different web services located at other clouds without the need to be re-authenticated again. Different standard protocols were established in the SSO [52]. The two most popular are Security Assertion Markup Language (SAML 2.0) [53], and OpenID connect [54], each of them with its specifications and format [53] [54]. ...
... • Limited audibility.ingly limitless computational resources, processing power, and storage space that can effectively meet user demands[52] [58]-[61]. In the bio-informatics domain, a bioNimbus[60] [61] is a federated cloud platform in which different independent, heterogenous, private/public/hybrid clouds are collaborated to support other bio-informatics applications. ...
Book
Full-text available
The Fourteenth International Conference on Cloud Computing, GRIDs, and Virtualization (CLOUD COMPUTING 2023), held on June 26 - 30, 2023, continued a series of events targeted to prospect the applications supported by the new paradigm and validate the techniques and the mechanisms. A complementary target was to identify the open issues and the challenges to fix them, especially on security, privacy, and inter- and intra-clouds protocols. Cloud computing is a normal evolution of distributed computing combined with Service-oriented architecture, leveraging most of the GRID features and Virtualization merits. The technology foundations for cloud computing led to a new approach of reusing what was achieved in GRID computing with support from virtualization. The conference had the following tracks: * Cloud computing * Computing in virtualization-based environments * Platforms, infrastructures and applications * Challenging features * New Trends * Grid networks, services and applications Similar to the previous edition, this event attracted excellent contributions and active participation from all over the world. We were very pleased to receive top quality contributions. We take here the opportunity to warmly thank all the members of the CLOUD COMPUTING 2023 technical program committee, as well as the numerous reviewers. The creation of such a high quality conference program would not have been possible without their involvement. We also kindly thank all the authors that dedicated much of their time and effort to contribute to CLOUD COMPUTING 2023. We truly believe that, thanks to all these efforts, the final conference program consisted of top quality contributions. Also, this event could not have been a reality without the support of many individuals, organizations and sponsors. We also gratefully thank the members of the CLOUD COMPUTING 2023 organizing committee for their help in handling the logistics and for their work that made this professional meeting a success. We hope that CLOUD COMPUTING 2023 was a successful international forum for the exchange of ideas and results between academia and industry and to promote further progress in the area of cloud computing, GRIDs and virtualization. We also hope that Nce provided a pleasant environment during the conference and everyone saved some time to enjoy this beautiful city.
... The emergence of blockchains prompted experimentation to use the new technology for decentralised PKIs (DPKI). In turn, the term "decentralised identity " was increasingly used to denote blockchain-based identity solutions rather than digital identity technology using OIDC and OIDC started to evolve into being referred to as "federated identity" protocol [32]. Following this, in the debate on digital identity solution the use of blockchain became the delineating factor for distinguishing between "decentralised" Web3 technologies and "centralised" identities in Web2. ...
Preprint
Full-text available
Web3's decentralised infrastructure has upended the standardised approach to digital identity established by protocols like OpenID Connect. Web2 and Web3 currently operate in silos, with Web2 leveraging selective disclosure JSON web tokens (SD-JWTs) and Web3 dApps being reliant on on-chain data and sometimes clinging to centralised system data. This fragmentation hinders user experience and the interconnectedness of the digital world. This paper explores the integration of Web3 within the OpenID Connect framework, scrutinising established authentication protocols for their adaptability to decentralised identities. The research examines the interplay between OpenID Connect and decentralised identity concepts, the limitations of existing protocols like OpenID Connect for verifiable credential issuance, OpenID Connect framework for verifiable presentations, and self-issued OpenID provider. As a result, a novel privacy-preserving digital identity bridge is proposed, which aims to answer the research question of whether authentication protocols should inherently support Web3 functionalities and the mechanisms for their integration. Through a Decentralised Autonomous Organisation (DAO) use case, the findings indicate that a privacy-centric bridge can mitigate existing fragmentation by aggregating different identities to provide a better user experience. While the digital identity bridge demonstrates a possible approach to harmonise digital identity across platforms for their use in Web3, the bridging is unidirectional and limits root trust of credentials. The bridge's dependence on centralised systems may further fuel the debate on (de-)centralised identities.
... Ultimate control over the key pair that is used to establish secure connections with counterparties and in most cases binds the credential data to a subject, determines the degree of decentralisation of identity access management (IAM). There is a trend to re-centralise the key management of decentralised identity schemes by hosting key pairs hosted on a server, turning decentralised identity solutions into federated systems [34]. This is evident in the emergence of SSI Cloud Wallets [35], [36], [37]. ...
Preprint
Full-text available
The terms self-sovereign identity (SSI) and decentralised identity are often used interchangeably, which results in increasing ambiguity when solutions are being investigated and compared. This article aims to provide a clear distinction between the two concepts in relation to the revised Regulation as Regards establishing the European Digital Identity Framework (eIDAS 2.0) by providing a systematisation of knowledge of technological developments that led up to implementation of eIDAS 2.0. Applying an inductive exploratory approach, relevant literature was selected iteratively in waves over a nine months time frame and covers literature between 2005 and 2024. The review found that the decentralised identity sector emerged adjacent to the OpenID Connect (OIDC) paradigm of Open Authentication, whereas SSI denotes the sector's shift towards blockchain-based solutions. In this study, it is shown that the interchangeable use of SSI and decentralised identity coincides with novel protocols over OIDC. While the first part of this paper distinguishes OIDC from decentralised identity, the second part addresses the incompatibility between OIDC under eIDAS 2.0 and Web3. The paper closes by suggesting further research for establishing a digital identity bridge for connecting applications on public-permissionless ledgers with data originating from eIDAS 2.0 and being presented using OIDC.
... Ultimate control over the key pair that is used to establish secure connections with counterparties and in most cases binds the credential data to a subject, determines the degree of decentralisation of identity access management (IAM). There is a trend to re-centralise the key management of decentralised identity schemes by hosting key pairs hosted on a server, turning decentralised identity solutions into federated systems [34]. This is evident in the emergence of SSI Cloud Wallets [35], [36], [37]. ...
Conference Paper
The terms self-sovereign identity (SSI) and decen- tralised identity are often used interchangeably, which results in increasing ambiguity when solutions are being investigated and compared. This article aims to provide a clear distinction between the two concepts in relation to the revised Regulation as Regards establishing the European Digital Identity Framework (eIDAS 2.0) by providing a systematisation of knowledge of technological developments that led up to implementation of eIDAS 2.0. Applying an inductive exploratory approach, relevant literature was selected iteratively in waves over a nine months time frame and covers literature between 2005 and 2024. The review found that the decentralised identity sector emerged adjacent to the OpenID Connect (OIDC) paradigm of Open Authentication, whereas SSI denotes the sector’s shift towards blockchain-based solutions. In this study, it is shown that the interchangeable use of SSI and decentralised identity coincides with novel protocols over OIDC. While the first part of this paper distinguishes OIDC from decentralised identity, the second part addresses the incompatibility between OIDC under eIDAS 2.0 and Web3. The paper closes by suggesting further research for establishing a digital identity bridge for connecting applications on public- permissionless ledgers with data originating from eIDAS 2.0 and being presented using OIDC.
... SSO allows users to access multiple related but independent software systems with a single authentication action, enhancing user productivity and simplifying central user management. Radha et al. [17] examine various SSO methods, implementation strategies, and the associated protocols, highlighting the benefits of adopting SSO within different network environments. Wang et al. [18] present a study on popular web SSO systems, uncovering eight serious logic flaws in high-profile providers and highlighting the need for larger-scale studies to better understand and address the security issues in SSO implementations. ...
Conference Paper
Authentication, authorization, and access control are fundamental functionalities that are crucial for network infrastructures and software applications. These functionalities work together to create a fundamental security layer that allows administrative entities to control user actions. Implementing a security layer may be simple for basic applications, but as modern digital infrastructures become more complex, more advanced security systems are needed. Traditional perimeter-based security models, long relied upon for securing large networks, exhibit vulnerabilities and lack adaptability to modern architectures. As technology advances, there is a growing demand for new authentication and authorization systems to keep up with the changes. Zero Trust (ZT) emerges as a paradigm embodying such principles and concepts for constructing contemporary security systems. This paper introduces a ZT-based Single Sign-On (SSO) framework to demonstrate how ZT can be realized in multi-service environments using Attribute-Based Access Control (ABAC). A prototype is developed to show the feasibility and applicability of the proposed framework in a smart city context.
Article
Full-text available
Single Sign-On (SSO) methods are the primary solution to authenticate users across multiple web systems. These mechanisms streamline the authentication procedure by avoiding duplicate developments of authentication modules for each application. Besides, these mechanisms also provide convenience to the end-user by keeping the user authenticated when switching between different contexts. To ensure this cross-application authentication, SSO relies on an Identity Provider (IdP), which is commonly set up and managed by each institution that needs to enforce SSO internally. However, the solution is not so straightforward when several institutions need to cooperate in a unique ecosystem. This could be tackled by centralizing the authentication mechanisms in one of the involved entities, a solution raising responsibilities that may be difficult for peers to accept. Moreover, this solution is not appropriate for dynamic groups, where peers may join or leave frequently. In this paper, we propose an architecture that uses a trusted third-party service to authenticate multiple entities, ensuring the isolation of the user's attributes between this service and the institutional SSO systems. This architecture was validated in the EHDEN Portal, which includes web tools and services of this European health project, to establish a Federated Authentication schema.
Department of Internetworking
  • Web Single
  • Sign-On
  • Wrl System
  • Company
  • Si
  • Xiong
Web Single Sign-On System for WRL Company. Si Xiong, Department of Internetworking, Royal Institute of Technology (KTH), Sweden; 2005; http://web.it.kth.se/~johanmon/theses/xiong.pdf.
Identity Management: Concepts, Technologies and systems. 685 Canton StreetNorwood,MA02062,ArtechHouse
  • Elisa Bertino
  • Kenji Takahashi
Elisa Bertino, Kenji Takahashi. Identity Management: Concepts, Technologies and systems. 685 Canton StreetNorwood,MA02062,ArtechHouse,2011;55-9,77-9,86-7,98-100,119. http://books.google.co.in/books?id=UrmD-Gxt-8IC&printsec=frontcover#v=onepage&q&f=false.
Security Consultant HPCI Technology Leadership Group Hewlett-Packard. Single Sign-On Architectures
  • Jan De
Jan De Clercq, Security Consultant HPCI Technology Leadership Group Hewlett-Packard. Single Sign-On Architectures. http://www.esat.kuleuven.be/cosic/seminars/slides/SSO.pdf.
Assertion Markup Language (SAML) V2.0 OASIS Standard, OASIS http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf. 7. OpenID Foundation website
  • Protocols Assertions
  • For
  • Security
Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0 OASIS Standard, OASIS; 2005. http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf. 7. OpenID Foundation website. http://openid.net/. 8. BrowserID by Mozilla. https://browserid.org/.
  • Web Single Sign-On
  • Wrl System For
  • Si Company
  • Xiong
Web Single Sign-On System for WRL Company. Si Xiong, Department of Internetworking, Royal Institute of Technology (KTH), Sweden; 2005; http://web.it.kth.se/~johanmon/theses/xiong.pdf.
Successfully deploying Single Sign-On (SSO) within an outsourced Environment
  • Colin Robbins
  • Edward Hamilton
Colin Robbins, Edward Hamilton. Successfully deploying Single Sign-On (SSO) within an outsourced Environment. http://www.insight.co.uk/files/whitepapers/Single Sign on (White paper).pdf.