Evaluation of Real-Time Communication in IoT Services by WebRTC
Mohan_Dissertation (1)
1. Loosely Coupled SAML based Single
Sign-on implementiation to
authenticate and manage identities in
a multi-tenant SaaS application
deployed on Public cloud
Mohan Kumar Satyanarayana
Submitted as part of the requirements for the degree
of MSc in Cloud Computing
at the School of Computing,
National College of Ireland
Dublin, Ireland.
December 2014
Supervisor Mr. VIKAS SAHNI
2. Abstract
Evolution of Cloud computing, which is one of the key technologies in the field of
information technology, is rapidly changing the vision of software development and
infrastructure in terms of compute and storage. Charles Percy Snow, quotes about
technology by stating that it is a queer thing which brings to you gifts with one
hand and stabs in the back with another. Similarly, in Cloud Computing there are
few obstacles which are multi-tenancy, confidentiality of data and its privacy. Many
research activities are still in progress in the field of multi-tenancy and data security.
In this dissertation, we address one of the key concerns, namely multi-tenancy by
addressing the issue of multi tenant authentication in SaaS applications. In the
process of providing authentication to multi-tenant SaaS application, we consider in
implementing a Single sign-on solution by making use of SAML based XML markup
language besides username/password authentication.
SAML is one of the popular authentication frameworks besides OAuth and OpenID
which help in achieving single sign-on solutions. Single sign-on solution to multi-tenant
SaaS applications help in reducing the costs of maintaining user data and as well helps
in reducing the number of username and passwords that the users have to manage.
SAML helps in providing the platform where the SaaS application would handshake
with the identity provider by transferring assertions and help in authenticating the
user. In general, authentication is performed by using native username and password
which are stored in local application data store. Instead, with the usage of identity
providers that are part of the identity federation, authentication has taken a di↵erent
stage where username and passwords need not be stored in the SaaS data store.
Using Single sign-on and SAML, users can make use of the same credential registered
at identity provider of the identity federation with its respective service providers
(SaaS applications) and need not register at service providers. This helps in reducing
multi-tenancy issue as multiple tenants can access the resource by authenticating their
single sign-on credential.
ii
3. The main goal of this dissertation is to address the problem of multi-tenancy in
SaaS applications and how can SAML help in achieving single sign-on to reduce the
risk of multi-tenancy. In the view of dissertation, the SAML implementation that is
provided would be a loosely coupled implementation which can help in reducing the
maintenance cost and is independent of the existing SaaS functionality. This work also
presents the features of using SAML for implementing single sign-on. Furthermore, we
check if SAML as single sign-on solution would reduce the risk of multi-tenancy and
provide a comparative study on using SAML for authentication against conventional
username password authentication.
Keywords: Cloud computing, SaaS applications, Multi-tenancy, Single Sign-on,
SSO, SAML, OAuth, OpenId, Loosely Coupled, Authentication, Authorization,
Service Provider, Identity Provider, Certificate, Public key, Private Key
iii
4. Declaration
I declare that this dissertation for MSc in cloud computing is my own research work
and has not been submitted anywhere else for any award or degree. All the sources
that are used as part of the dissertation are acknowledged.
Signed ......................................
(MOHAN KUMAR SATYANARAYANA)
Date ......................................
v
9. Chapter 1
Introduction
Cloud computing has become a key term in the fields of information technology and
computing. Mell, P. and Grance, T. (2011) of the National Institute of Standards and
Technology (NIST) define cloud computing as a pool of computing resources which
are configurable as per need and shared in a distributed network, and are accessible on
demand with minimal e↵ort. On the other hand, Cloud Security Alliance (2011) defines
cloud computing as a technology that is capable of increasing dexterity and availability
of computing resources, and by using computing resources proficiently, investment
costs can be reduced. Based on the definitions provided by Mell, P. and Grance, T.
(2011) and Cloud Security Alliance (2011), cloud can be compared to a model of
distributed computing resources in a shared network where capital expenditure and
operational expenditure are optimized by using the resources e ciently based on need.
For a clear understanding of Cloud computing, Mell, P. and Grance, T. (2011)
mention that a cloud environment has three models of services which are Software
as a Service (SaaS), Platform as a Service (PaaS) and Infrastructure as a Ser-
vice (IaaS), and four models of deployment which are private cloud, community
cloud, public cloud and hybrid cloud. Apart from the above mentioned models,
the cloud environment has got five key characteristics which are:- service which is
available on demand, network access which is broader, pooling of resources, swift
elasticity and metered service of resources. Badger, L., Grance, T., Patt-Corner,
R. and Voas, J. (2012) of NIST have mentioned that cloud resources are on a pay-
per-use basis as consumers are charged based on their usage of the respective resources.
As the cloud environment is distributed over a network and a provider shares
1
10. the resources to several consumers, it is prone to certain limitations and vulnerabili-
ties. Some of these as mentioned by Badger, L., Grance, T., Patt-Corner, R. and Voas,
J. (2012) are the availability of resources, preserving data, compensation on failure to
perform, data security/confidentiality and legal care of consumer data. In order to
ensure a smooth process in relation to these issues, both the provider and consumer
should enter into a service level agreement (SLA) as suggested by Badger, L., Grance,
T., Patt-Corner, R. and Voas, J. (2012) which details more on the availability of
resources and recovery time in the event of any disaster.
Though there are many advantages like availability, scalability, broad network
access and pay-per-use on subscribed resources using cloud computing, Cloud Security
Alliance (2011) and Jansen et al. (2011) highlight a few limitations like data privacy,
identity and access management in cloud computing which are related to cloud security.
It is the responsibility of the cloud consumer to make sure that necessary precautions
are in place to ensure that their data is secure and their respective applications are
e cient in terms of authentication as mentioned by Cloud Security Alliance (2011)
and Jansen et al. (2011). In terms of identity and access management, Cloud Security
Alliance (2011) stress on the multi-tenant issue which is one of the important issues
to address. Multi-tenancy issues vary with service models as highlighted by Cloud
Security Alliance (2011).
Cloud Security Alliance (2011) compares the multi-tenancy issue in IaaS as same
hardware resources being shared across cloud consumers and multi-tenancy issue in
SaaS as the application being accessed by several cloud users. Based on the above
views, it is understood that multi-tenancy is one of the key concerns that every cloud
consumer should be mindful of ensuring that identity and access management is
properly enhanced. Because of these issues, some of the organizations are concerned
about identity management though they are interested in adapting to cloud computing.
In the next chapter, we shall be critically analysing the process of identity management
and to see if single sign-on can help in reducing the multi-tenancy issues in a SaaS
environment. Moreover, we shall also analyse the various single sign-on frameworks
that are available and the pros and cons of using them.
2
11. Chapter 2
Background
This dissertation focuses on the importance of reducing the risk of multi-tenancy in
Software As A Service (SaaS) environment by providing web SSO implementation
using Security Assertion Markup Language (SAML) authentication which is loosely
coupled and ensures that identity management is safe and secure. In order to examine
this issue, the review has been divided into four sections. The first section deals
with the importance of identity management, the second section presents the features
of SaaS applications by detailing on multi-tenancy and importance of Single Sign-
On(SSO), the third section provides an analysis of various frameworks that support
SSO methodology and the last section details on the importance of using SAML
authentication for implementing a SSO. These sections also explore the measures
and standards that should be considered in order to ensure that user credentials
are validated and authenticated successfully without compromising on the security
standards.
The importance of identity management focuses on the various features involved
in managing identities and as well on the issues of multi-tenancy. The importance
of SSO model describes on the advantages on choosing this model to provide better
authentication standard in SaaS applications. Apart from providing standard, this
section also details how SSO helps to mitigate multi-tenancy issues. The third section
details the various standards that are available for implementing SSO and analyses on
the di↵erences using respective frameworks. The final section on SAML details on its
architecture and explains the process of authentication which is performed on users
without compromising on the security.
3
12. 2.1 Identity Management
Spencer (2012) clearly explains about identity management by dividing it into five
categories which are authorisation, authentication, federation, managing user accounts
and auditing/logging of user actions. Similarly, Faraji et al. (2014) categorise identity
and access management into three requirements which are authentication, management
of access and reporting. Authentication is defined by Spencer (2012) as identification
of an individual which is verified by sharing the secret credentials, whereas Faraji
et al. (2014) defines authentication as the privilege that is provided to a cloud user
in accessing a cloud resource. Spencer (2012) defines authorisation as the privilege of
access provided to an individual. Instead of dividing into categories, Almulla & Yeun
(2010) define Identity and Access Management (IAM) as a set of methods that help
in managing user policies and rules, user privileges and also provide an additional
level of security in accessing the organization resources when required by a user. The
analysis of these three journal articles suggests that IAM is a process which involves
authentication and authorization that provides additional level of security in providing
access to the cloud resources.
Ghazizadeh et al. (2012) identify that identity and trust are few of the main
security concerns that is worrying most of organizations apart from the low cost ad-
vantage of cloud computing. Having defined about authentication earlier, Faraji et al.
(2014) also mention that authentication is one of the growing concerns in federating
identity. In this regard, Faraji et al. (2014) even mention about the usage of federated
identities and third party providers to ensure that IAM is e ciently managed in cloud
environments. Therefore, this brings out the importance of identity in cloud environ-
ment in regards to security and the need to find a better solution to safeguard identities.
Almulla & Yeun (2010) state the prominence of identity federation by mentioning
the challenges such as identity duplication and various customers of an organization
like suppliers/partners. On the other hand, Zhang et al. (2013) mention about the
importance of authentication and authorisation in cloud security by highlighting that
it enhances cloud interoperability and build a cloud federation. In terms of federation,
Spencer (2012) mentions that it is a process which propagates authentication beyond
the boundaries of an organization. Sameera state identity federation as a trust between
organizations and enabling users to use the same credentials to access the services of
an application. Almulla & Yeun (2010) also mentions the ease in maintaining user
accounts beyond the boundaries of an organization. Based on the above observations,
it is clear that federated identity is the solution that can help and manage identities
4
13. e↵ectively and e ciently and helps in enhancing cloud interoperability.
Faraji et al. (2014) highlight five of the security concerns in using cloud computing
as access based on privileges, disposal of information, segregation of information,
exact location of the stored information and monitoring of data. Celesti et al.
(2010) stresses on the problem faced by cloud services in terms of authentication by
mentioning a scenario where cloud services manage their own security mechanisms
to authenticate users. Faraji et al. (2014) also mention about the importance of
separating authentication logic from the user credential information in order for the
cloud service to support any authentication mechanism. Based on these concerns, it
can be identified that authentication should be loosely coupled with the cloud service
and should be configurable.
2.2 Features of SaaS applications in cloud environment
2.2.1 SaaS applications
Li et al. (2012) terms SaaS model as one-to-many model by relating a single service
instance to multiple tenant models. SaaS architecture was described by Kang et al.
(2011) where they mention about Microsoft SaaS maturity model which comprises of
four levels. Kang et al. (2011) mention that level 1 represents the deployment model
which comprises of the server instances and the tenant subscriptions. As mentioned by
Kang et al. (2011), Level 2 is about configurability that helps in providing additional
aspects to certain tenants and level 3 is related to multi-tenancy where multiple tenants
would be accessing the same instance of the SaaS service. Kang et al. (2011) indicate
that every tenant would assume that a dedicated server is assigned to them for their
access. The fourth level is about scalability, where additional servers can be added
or removed using load balancer technique to increase the performance of the SaaS
application as mentioned by Kang et al. (2011). This brings to a clear understanding
that a good SaaS architecture should be designed considering the deployment model,
configurability, multi-tenancy and scalability.
Li et al. (2012) categorise the characteristics of a balanced SaaS applications to
be configuration, customization and multi-tenancy. Liu et al. (2009) explain about
SaaS by referring to multi-tenant architecture and single-instance model where
multiple tenants would be accessing the SaaS application which is deployed on a
single instance. Tsai & Sun (2013) mention that multiple tenants can access the SaaS
5
14. application at same time. Tsai & Sun (2013) indicates that SaaS applications should
be independent of domain and provide a generic solution to the needs of enterprises.
In terms of expenses, Liu et al. (2009) indicate that the costs incurred on a
SaaS application are very less when compared to conventional applications as on-
premise infrastructures are not required. Bezemer & Zaidman (2010) also indicate
that multi-tenancy will reduce the overall expenditure of the organization and are
encouraging the organizations in migrating single tenant applications to multi-tenant
applications. Tsai & Sun (2013) also agree with Liu et al. (2009) and Bezemer
& Zaidman (2010) and mention that SaaS application help in reducing costs and
increasing profits. Li et al. (2012) also agree with Liu et al. (2009) and Tsai &
Sun (2013) and indicate that SaaS applications reduce the costs incurred on an
organization by utilising the features of customization and configuration. This gives a
clear indication that SaaS applications would help in reducing the expenditure of an
organization and increases the profits.
Based on the above critical evaluation, it is clear that identities play a major
role in authentication and it is to be ensured that identities are part of federation
which helps in cloud interoperability. Cloud identity federation also helps in managing
identities e ciently and e↵ectively. Having discussed about identity management,
the next section of this paper addresses on the impact of multi-tenancy in SaaS
applications.
2.2.2 Multi-tenancy in SaaS
Cloud Security Alliance (2011) defines multi-tenancy as access to an application or its
resources by several consumers at the same time. Having defined about multi-tenancy,
Cloud Security Alliance (2011) also mentions that these consumers need not belong to
the same organization/industry but di↵erent organizations/industries as well. Bezemer
& Zaidman (2010) refers multi-tenancy as two fold model where they refer one fold
as easier deployment from SP perspective and other fold as hardware utilisation rate
can be increased. Cloud Security Alliance (2011) also mention that the concept of
multi-tenancy varies with service models and highlights that it is very important to
address the multitenant issues irrespective of the service model. By analysing the
above views, it is fair to conclude that multi-tenancy is an important concern that
needs to be addressed so as to e↵ectively access application and its resources.
Li et al. (2012) mention that every tenant would assume that they are the sole
6
15. owner of the application. This view is supported by Tsai & Sun (2013) and state that
each tenant might assume that it is their own application with in a multi-tenant SaaS
application. Based on the above views of authors, it is clear that a SaaS application
is e↵ective if it is configurable, customizable and independent of domain irrespective
of the tenant. Bezemer & Zaidman (2010) highlight that handling authentication is
critical and can be improved by including an authentication where user can be part of
many logical organizations.
Bezemer & Zaidman (2010) indicate one of the advantages of multi-tenant SaaS
application as deployment of software updates for the application is cheaper as the
instances are smaller in size. Other advantage indicated by Bezemer & Zaidman (2010)
is that multi-tenant SaaS applications are easy to maintain in spite of code complexity
provided the implementation of multi-tenancy is e cient. An e cient multi-tenant
application code should be loosely coupled with single-tenant code to ensure that the
code complexity is less and easy to maintain as indicated by Bezemer & Zaidman
(2010). Bezemer & Zaidman (2010) indicate that multi-tenant code should be more of
a cross-cutting concern with in a single-tenant application code. Based on the above
review, it is obvious that the way authentication is handled by using IDP plays a
major role in an e↵ective SaaS application. Based on the above observations, it is
clear that multi-tenant code should not be dependent and be loosely coupled with the
existing SaaS application which helps in easy configuration of the application.
In terms of SaaS applications, it is clear that the operational expenses and cap-
ital expenses of organization is reduced. It is also clear that a SaaS application
should have control over configuration and customization to be e↵ective. In terms
of multi-tenancy, necessary care should be taken so that the code that is related to
multi-tenancy should not be an impact or dependent on the single-tenant code. So far
this section has focussed on multi-tenancy in SaaS applications, the next section will
discuss on the importance of SSO to manage identities in SaaS applications.
2.2.3 Importance of Single Sign-on
Cloud Security Alliance (2011) defines SSO as a methodology which helps in commu-
nicating identity to the service provider. Tsai & Sun (2013) state that a typical web
user would have around 25 web accounts which are protected with passwords and use
around 8 password enabled applications per day. Quoting the above problem, Tsai &
Sun (2013) mentions about Web SSO as the solution which helps in using one user
account that is capable enough to sign onto various other websites. Ghazizadeh et al.
7
16. (2012) also highlight the problem of maintaining username and passwords with the
increasing number of SaaS applications and the need of a SSO solution to address this
issue. The above observations indicate that SSO comes to the rescue for the growing
issue of username/password maintenance wherein a single account can be used for
authentication across various SaaS applications.
Almulla & Yeun (2010) mention the advantage of SSO by highlighting that
users need not register in various organizations and remember the same to validate
their identity. Instead, the users can be authenticated with the trusted credentials.
Celesti et al. (2010) provide a solution by mentioning that cloud services should be
able to authenticate its identity based on other cloud services and should not be
dependent on the implemented security mechanism. Celesti et al. (2010) define this
solution as SSO where users can get authenticated once and accesses various services
of the application. Pereira et al. (2014) encourage the systems that implement IAM
to ensure that they form a federation between organisations and provide SSO feature.
Pereira et al. (2014) highlight the advantage of SSO by mentioning that it would
help cloud users in not having to authenticate each and every time to access di↵erent
applications. Tsai & Sun (2013) also agree to the above views and highlight that web
SSO help in reducing the number of registrations that web users have to manage and
also reduces the number of passwords that the users have to remember. Based on
the above views of authors, it is clear that by using SSO, user can get authenticated
once and can access the services of the respective SaaS application. The above views
also brings to notice that users need not register in various SaaS application to create
identities and instead can use the identity that is part of the federation to avail access
to the SaaS application which is part of the federation.
Ghazizadeh et al. (2012) divide the users of a SSO application into three enti-
ties namely Identity providers (IDP), Service providers (SP) and web users. The
role of IDP as stated by Ghazizadeh et al. (2012) is to authenticate user identity by
collecting their credentials and the role of service provider is to trust the authenticated
credential and allow the user to access the application. However, Tsai & Sun (2013)
refers web SSO to IDP/Relying Party (RP) model where IDP is referred to as a
service or application that maintains user identities and authenticates the users. RP is
referred to as the service that depends on identities that are authenticated and takes
decisions in allowing the users to access the application based on the authentication
status. Therefore, in a SSO, the key actors are IDP, service provider and the web user.
IDP refers to the one that maintains identities, service provider or relying party refers
to the one that makes of the identities in IDP and the web user is the one who would
8
17. access SaaS application by providing authentication details which is associated with
the cloud federation.
In the context of this literature review, after analysing the views of the authors
mentioned above, it can be concluded that SSO helps in maintaining authentication
e ciently and in an organized way. This section has also explained about the
various actors that are involved in a SSO model. Having discussed the importance of
SSO model, the next section addresses on the usage of SAML in achieving SSO solution.
2.3 Analysis of frameworks that support SSO methodol-
ogy
Tsai & Sun (2013) mention about SAML, OpenID, Open standard to Authorization
(OAuth) and InfoCard as the open standard SSO mechanisms that help in building
a SSO solution for applications. Similarly, Cloud Security Alliance (2011) suggest
that the applications that are planned for cloud deployment to be treated as SaaS
application should be designed to support the open federation standards such as
SAML, OpenID and OAuth. In support with Tsai & Sun (2013) and Cloud Security
Alliance (2011), Ghazizadeh et al. (2012) also mention that OpenID, OAuth and SAML
are the popular frameworks that are currently used in establishing authentication and
in providing an identity federation. Even, Murukutla & Shet (2012) also identify that
SAML, OAuth and OpenID are the standard frameworks that help in providing a SSO
system.
Murukutla & Shet (2012) also mention that SAML and OpenID are standards
that help in authenticating identities, whereas OAuth helps in authorisation. Though
Tsai & Sun (2013) mention that InfoCard is one of the frameworks that is used for
SSO solutions, PingIdentity (2014) which is an organization that provides solutions
to identity and access management identify that usage of information cards is non-
existent. Ferdous & Poet (2012) have also mentioned that this project of CardSpace
undertaken by Microsoft is discontinued due to increasing standards of identity
federation space. The above critical analysis of authors views bring a clear picture
that SAML, OpenID and OAuth are the frameworks that are popular and assist in
building SSO applications using identity federation.
Onelogin (2014), an organization known for its identity management solutions
9
18. define OAuth as a framework that helps in authorising API calls between applications.
Onelogin (2014) define OpenID as a framework that helps in providing SSO solution
to the users or consumers. Onelogin (2014) define SAML as a framework that helps
in providing SSO for users who belong to enterprises of various domains. In terms
of usage of respective frameworks, Sherif (2013) also agrees with Onelogin (2014)
and identifies that OpenID is primarily used as SSO for users, SAML as SSO for
users those belong to enterprises or organizations and OAuth as authorising API calls
between the web applications. The views of Onelogin (2014) and Sherif (2013), bring
in one of the important analysis to understand the purpose of individual frameworks
and the use cases where respective frameworks can be applied to provide SSO solution.
Reimer et al. (2013) mention that OAuth 1.0 was introduced in 2007 and OAuth
2.0 was introduced in 2012. PingIdentity (2014) also identifies the changing trends
in identity frameworks and mention that OAuth 2.0 has transformed a lot when
compared to OAuth 1.0. PingIdentity (2014) talks about OAuth as a framework that
helps in providing access to the necessary resources through secured API calls which
are RESTful. Whereas Sherif (2013) of SoftwareSecured organization discuss about
OAuth as yet another framework for validating identities but identify that OAuth
is used primarily for authorisation and not essentially authentication. PingIdentity
(2014) mention that OAuth has strong support for mobile applications that are native
which is not identified in SAML.
The roles that are involved in OAuth process are the end user, OAuth provider
and OAuth consumer as mentioned by Sherif (2013). Sherif (2013) define end user as
the entity that is need of accessing a resource, OAuth provider as a resource server
which hosts the resource and provides tokens in return after validation and OAuth
consumer as the application that uses the tokens to provide access to the end user.
PingIdentity (2014) also mention about roles involved with di↵erent names but are
defined similarly. PingIdentity (2014) mention about Client, Resource server and
Authorization server as the roles involved in OAuth process. Client is the one who
requires access to a resource, Resource server is the application which handles requests
and authenticates the identity and Authorization server is the one which adds a token
to the request upon validation. PingIdentity (2014) did not mention about any security
concerns but Sherif (2013) identifies token fixation as one of the security impacts where
attacker can fix the token and get authorised to access the resource. Ferdous & Poet
(2012) highlight that OAuth 2.0 has completely transformed and went through many
changes when compared to OAuth 1.0. In terms of OAuth 2.0, Sherif (2013) mentions
that some of the important features like encryption, signature, binding channels are
10
19. ignored and completely depends on the security that is underlying like Secure Sockets
Layer (SSL) and Transport Layer Security (TLS). The above observation brings to
notice that though OAuth 2.0 has completely transformed as a better framework,
there are a few security hitches which were kept open and ignored.
Sherif (2013) talks about OpenID as a standard framework where user is au-
thenticated by the help of IDP that are OpenID enabled whereas PingIdentity (2014)
mentions about OpenID 2.0 as a simple protocol which is dependent on the IDP. To
use OpenID as the solution for managing identities, the system should also be enabled
with openId as mentioned by Ferdous & Poet (2012). Sherif (2013) mentions a few
OpenID IDPs which are Yahoo, Google, Microsoft, PayPal, Facebook, PingIdentity
and so on. Sherif (2013) also highlight that if the user wants to login into an applica-
tion which is OpenID enabled, and then they have the option to choose their openId
provider to get authenticated. Sherif (2013) talks about three di↵erent roles that are in-
volved in the authentication process as the user, relying party and the OpenID provider.
Sherif (2013) define user as the actor who wants to access the application by
providing authentication details, relying party is the application that requires valida-
tion of credentials to provide access and OpenID provider is the IDP which validates
user credentials on behalf of the relying party. Some of the security concerns which
are identified by Sherif (2013) are phishing attacks and authentication impersonation.
Instead of security concerns, PingIdentity (2014) talks about the limitation that is
part of OpenID framework. Much importance is given for SSO by OpenID 2.0 than
the attributes that are to be shared upon validation as mentioned by PingIdentity
(2014). This was seen as a limitation by PingIdentity (2014) as the user attributes are
not available to the application. Having said that, PingIdentity (2014) mention that
OpenID Connect 1.0 which is built upon API authorization features of OAuth 2.0 and
semantics of SAML 2.0 for fetching attributes looks to be promising identity solution.
Therefore, it is clear that to use OpenID, it is required to choose an IDP which is
OpenID enabled and also highlights about OpenID Connect as the promising solution
which works on both OAuth and SAML.
In terms of SAML, PingIdentity (2014) mentions that it has been constant and
is consistent in terms of identity standards. Sherif (2013) mentions about SAML
as a framework which was created by OASIS. Sherif (2013) defines SAML as an
open standard product which is based on XML and helps in both authentication
and authorisation. PingIdentity (2014) also mentions that SAML is a product of
OASIS and is XML based identity management framework. PingIdentity (2014) also
11
20. mentions that strong focus is given for security in SAML framework. Having said
that, PingIdentity (2014) also highlight that SAML has become a de facto standard
for many enterprises like higher education, SaaS providers and eGov in building
federations. In terms of roles, Sherif (2013) identifies the end user, service provider
and IDP as the primary roles involved in the process of SAML authentication. Sherif
(2013) defines end user as the user who wants to validate identity, service provider
as the one who wants to validate the user credentials by using IDP and IDP as the
one which validates the user credentials and asserts valid response. XML signature
wrapping is identified by Sherif (2013) as the only concern involved in using SAML
to impersonate user which dates back to 2011. Based on the above observations, it
is understood that SAML helps in both authorization and authentication. Moreover,
SAML is used as the SSO solution mainly for enterprises.
Sherif (2013) also provides a better comparison on the protocols that are used
in OAuth, OpenID and SAML. In terms of protocols, OpenID supports Hyper Text
Transfer Protocol (HTTP) and eXtensible Resource Descriptor Sequence (XRDS)
which is based on XML as mentioned by Sherif (2013). Sherif (2013) indicate that
OAuth supports HTTP and JavaScript Object Notation (JSON) which is light weight
whereas SAML supports eXtensible mark-up language (XML), HTTP, and Simple
Object Access protocol (SOAP).
Bauer, J (2014) presents a comparative study on the popular single sign-on frameworks
which are OAuth, SAML and OpenID. Based on the venn diagram 2.1 provided by
Bauer, J (2014), it is clear that all these three frameworks provider single sign-on
feature with attribute exchange. However, some of the notable di↵erences provided
by Bauer, J (2014) are that SAML is mostly helpful to corporates or organizations to
provide single sign-on and OAuth is helpful for networking applications like facebook
and twitter to share their resources upon authorization. In terms of support, Bauer, J
(2014) mention that OAuth and OpenID have strong open source development support
whereas SAML has strong web access product support. Gluu (2014), an organization
which deals with identity and access management provide a better comparison between
OAuth, OpenID, SAML and OpenID connect in the figure 2.2. Gluu (2014) identifies
that in terms of functionality both SAML and OpenID are similar. In contrast with
OAuth, Gluu (2014) mentions that OAuth does not have support for session initiation
whereas SAML and OpenID can initiate user’s login session. In terms of fetching
user attributes, Gluu (2014) mentions that user’s consent is requested before fetching
attributes in OAuth whereas user’s consent is not required in SAML and OpenID.
High secured identity tokens are used in SAML implementation and OpenId and
12
21. Figure 2.1: Comparison between OpenID, SAML and OAuth by Bauer, J (2014)
OAuth does not use identity tokens as mentioned by Gluu (2014). Based on these
comparative study by Gluu (2014) and Bauer, J (2014), it is understood that SAML
supports single sign-on mostly for enterprises or organizations and uses highly secured
identity tokens for exchanging information.
In terms of initiating a request for identification, PingIdentity (2014) mentions
that SAML supports both service provider and identity provider initiation whereas
OAuth and OpenID are initiated through service provider. In terms of identifiers
that are communicated, PingIdentity (2014) mentions that OAuth does not send
any attributes back to the application; however it is possible to retrieve necessary
attributes upon authentication using the token. On the other hand, OpenID provides
only one attribute which is the unique user identifier provided by the IDP. PingIdentity
13
22. Figure 2.2: Comparision between OpenID, SAML, OAuth and OpenID Connect by
Gluu (2014)
(2014) mentions that SAML is capable of sending more than one attribute to the ser-
vice provider upon authentication which helps in identifying the user in the application.
The above section has provided a detail comparison on using various frame-
works like OpenID, OAuth and SAML for providing SSO solution. The above analysis
also helps in understanding that SAML is used for enterprises, OAuth is used to
authorize API calls and OpenID is used for users who are OpenID enabled and have
an account. In terms of protocols, it is understood that SAML uses XML, HTTP
and SOAP, whereas OAuth uses HTTP for exchanging information. In the scope of
this dissertation, this analysis on various frameworks leaves with no choice than to
use SAML as the SSO implementation is for enterprises. This section has compared
OpenID, OAuth and SAML frameworks and identified that SAML suits the best in
the scope of this dissertation. The next section details more on the SAML language.
14
23. 2.4 SAML authentication language
Kaixing & Xiaolin (2009) term SAML as one of the popular and interoperable security
solutions that help in resolving the issue of SSO in a heterogeneous environment.
Organization for the Advancement of Structured Information Standards (OASIS)
designed open standard XML based SAML in order to provide a solution that can
help in communicating secured information between organizations as mentioned by
Kaixing & Xiaolin (2009). Celesti et al. (2010) also encourages the use of SAML in
achieving SSO due to its security standards that helps in creating a federated identity
and trust between cloud services. Faraji et al. (2014) also stress on the importance of
following standard authentication techniques like SAML to implement a service that
is capable of performing in cross-domain as well. Based on the above observations, it
is clear that underlying security standards of SAML helps in building an e cient SSO
model.
In terms of SAML versions, Tsai & Sun (2013) highlight that SAML 2.0 is
considered the best choice for building federated identities which is robust and
interoperable. As user does not have control over data that is stored in cloud, Cloud
Security Alliance (2011) recommends the use of SAML for authentication as it helps
in enhancing security in terms of interoperable control over standard systems. Cloud
Security Alliance (2011) suggest that developing an identity access management (IAM)
system which is compatible with SAML assertions and will help in porting SaaS based
applications to cloud which helps in resolving most of the portability issues in terms
of security integration. The observations of Tsai & Sun (2013) and Cloud Security
Alliance (2011) help in understanding that features of interoperability and portability
are shipped along when SAML is used for building an identity management system.
Celesti et al. (2010) discuss on using the identity provider and service provider
model which help in building federated applications. Celesti et al. (2010) explain that
SAML is a standard that is XML based and is capable of exchanging assertions for
authentication and authorization between the identity provider and service provider.
Tsai & Sun (2013) also explain about SAML as an SSO implementation that exchanges
identity information between IDP and RP/SP. Celesti et al. (2010) define IDP as
an application that is a producer of assertions based on user credentials and service
provider as an application that consumes the assertions sent by IDP. Celesti et al.
(2010) refers service provider also as relying party and IDP as asserting party. Tsai
& Sun (2013) brings out the advantage of SAML by mentioning about SAML web
browser SSO profile which helps in transporting assertions and responses between
15
24. identity provider and service provider/relying party with ease using web browser and
HTTP protocol. Therefore, it is clear that the communication model between identity
provider and service provider is through assertions when SAML is used.
In the Figure. 2.3, Almulla & Yeun (2010) clearly explain the request flow
Figure 2.3: SAML Flow by Almulla & Yeun (2010)
that happens in SAML system. Almulla & Yeun (2010) also have clearly mentioned
the steps that are involved. Kaixing & Xiaolin (2009) mention about SAML request
as the one which requests for authentication assertion and SAML response as the one
that communicates answers to the assertions. However, the flow of SAML request
and response is also clearly explained by Yong-sheng & Jing (2010) by considering the
sessions as mentioned in the following steps
16
25. 1. User accesses the service provider application and selects an IDP to login
2. Service provider will route the user to IDP login page
3. If the session is not created then user will be requested to provide credentials and
authenticate his identity
4. If session is already present, then the same authentication is used by retrieving
the session object of the user
5. Once the authentication is validated, the user is redirected back to service provider
6. Based on the response from identity provider, service provider will allow the user
to authenticate the user
7. Identity provider also communicates a set of attributes related to the user
This view of Yong-sheng & Jing (2010) gives a clear picture of the request flow and
response flow between identity provider and service provider in a SAML system.
Moreover, it also explains about how authentication is handled and session objects are
created.
Yong-sheng & Jing (2010) compares SAML with a use case which comprises of
bindings, assertions and protocols. Reimer et al. (2013) mention that SAML 2.0
supports various protocol bindings like HTTP and SOAP. Harding et al. (2008)
stress on the importance of e cient standards that should be considered in order to
establish trust that is safer and secure. Harding et al. (2008) identity few points that
organizations should consider before establishing trust and building a federation which
are trust, provisioning of metadata, SAML profile and binding, signing messages and
exchanging identifiers and attributes. Harding et al. (2008) also identify that entity ID
of SAML is helpful in identifying identity provider and service provider as it is unique
to every provider. Based on the above views, it is clear that assertions, bindings and
protocols are integral part of the SAML process flow and moreover it is important to
establish trust in building an identity federation. This analysis helps to understand
that the reference key for identification of identity provider and service provider is
done through entity ID which should be unique.
Kaixing & Xiaolin (2009) indicate that assertion is a key component in SAML
and is of three types which are authentication, authorization and attribution. Au-
thentication is defined by Kaixing & Xiaolin (2009) as an entity that is trusted either
way with the help of x.509 public key. Harding et al. (2008) also mention about the
importance of x.509 certificate which helps in identifying the caller and building a
17
26. trust through their metadata document. Having mentioned about metadata, they
also highlight that signing metadata helps in improving the security mechanism by
including cryptographic keys. Kaixing & Xiaolin (2009) define authorization as a
decision whether the user can be granted access. Kaixing & Xiaolin (2009) talk
about attribution as the user attributes that are communicated to the caller upon
authorization. The above critical analysis highlight the importance of X.509 certificate
which is also termed as public key and signing the metadata document in building a
trust relationship between identity provider and service provider. The above analysis
also mention about the various types of assertions that are available in a SAML system.
Shang et al. (2008) also agree with the view of Kaixing & Xiaolin (2009) and
mention that assertion is the crux of SAML and is divided into three variants which
are authorization, attribute assertion and authentication. Shang et al. (2008) detail
on authorization as the privilege of granting access to a resource, authentication as
trust that is used to allow an user to authenticate and attribute as the parameters
that are related to the authenticated user. Based on the above observations of Shang
et al. (2008) and Kaixing & Xiaolin (2009), it is clear that assertions plays a key
role in the process of SAML validation and are available in three variants which are
authorization, attribute and authentication.
Kim et al. (2008) detail about the importance of policy decision point (PDP)
and policy enforcement point (PEP) in the process of assertion using SAML. Kim
et al. (2008) explain about the role of PDP as the decision which is made to evaluate
the request before confirming on the result. PEP is defined as the point where the
requests are sent to PDP for confirmation and based on the result PEP confirms if
the request is approved or rejected. The above view of Kim et al. (2008) helps in
understanding about the roles of PDP and PEP and how the assertions are handled
in the process flow of SAML.
Reimer et al. (2013) highlight five important advantages of choosing SAML 2.0
which are 1. Platform independent - SAML is not specific to any platform and is
independent of the application logic, 2. Directories that are loosely coupled which
means that SAML does not store any user information or synchronise data in user
directories, 3. Better user experience - Users need not have the burden of managing
di↵erent identities for di↵erent applications, 4. Drop in administration expenses - As
authentication is moved to third party IDP, there is no need to administer data or
manage authentication and 5. Transfer of risk to IDP - Identity management is better
handled by IDP using SAML and service provider can just pass the control to IDP for
18
27. users to authenticate. On the other hand, Yong-sheng & Jing (2010) mention about
authentication of cross domains, authentication based on attributes, SSO, preventing
playback attacks and interoperability as few of the advantages that SAML brings
in providing an authentication framework. The views of Yong-sheng & Jing (2010)
and Reimer et al. (2013) helps in understanding that some of the key advantages
that ships along with SAML are platform independence, cross domain authentication,
authentication based on attributes, loosely coupled user directories, interoperability
and better user experience.
This section helps in understanding the importance of SAML in providing bet-
ter security standards and identity management for users in specific to enterprises or
organizations. SAML also provides SSO model where user credentials are validated
based on assertions which are of three variants, Authentication, Authorization and
Attribute. Platform independent, cross domain authentication, interoperability and
loosely coupled directories are few advantages of using SAML as SSO model. Moreover,
SAML is XML based which is compatible with most of the frameworks and works over
HTTP and SOAP protocols which are widely used. By using certificates, SAML builds
a secured trust between the parties of identity federation with the help of public key
(X.509 cert). These features encourage in using SAML as the identity management
framework for validating identities and providing a SSO model for the enterprise world.
2.5 Hypothesis and Contribution
The hypothesis of the thesis topic ’Loosely Coupled SAML based Single Sign-on imple-
mentiation to authenticate and manage identities in a multi-tenant SaaS application
deployed on Public cloud is to implement a single sign-on solution which is loosely
coupled, developed using SAML and to address the problem of multi-tenancy in SaaS
environment. SAML is one such frameworks that suits in building single sign-on
solution for enterprises or organizations.As the thesis is related to building single
sign-on solution for educational institutions, it is an obvious choice to choose SAML.
Moreover, in a cloud environment, it is always essential to ensure that data is secure.
SAML adheres to strong security measures by using public keys for trust and private
keys for encrypting the attributes. The data exchange happens in the form of XML.
To be more detailed, SAML supports both HTTP and SOAP protocols. Apart
from SAML, there are few other single sign-on frameworks like OAuth and OpenID.
But OAuth is mainly suited to authorize API calls and get access to resources whereas
19
28. SAML helps in both authentication and authorization. To work with OpenId, the
system should be OpenId enabled and the users should have an OpenId account
with any of the OpenId providers. Moreover, OpenId is mainly suited for users or
customers. This leaves with no choice rather than to choose SAML as the thesis is
related to providing single sign-on solution to educational institutions which belong to
enterprises. SAML helps in providing single sign-on solutions to enterprises irrespective
of the domain. SAML also helps in responding with more than one user attribute to
identify the user after successful authentication. By using SAML as the single sign-on
standard, the multi tenancy issues that occur in SaaS based applications can be
avoided and also helps in tightening the security measures during authentication. In
this process, the main objective would be to provide a loosely coupled implementation
which helps in creating an independent single sign-on authentication functionality
which is easily configrable and is not dependent on the existing SaaS functionality.
Along with loosely coupled implementation, the thesis would also compare communi-
cation cost and storage cost involved when SAML based single sign-on authentication
and user directory or database authentication is used. Communication cost evaluation
is done based on two factors. One is the time taken to render the sign-in page to
the user when SAML based authentication and user directory based authentication is
used. Apart from the time taken to render the sign-in page, other factor is to find out
the time taken to validate the users and send a response. Storage cost is evaluated
based on the amount of storage that is required to store the user details when SAML
based single sign-on or user directory authentication is used.
Based on the above analysis, the contribution of the thesis is to find out if a
loosely coupled SAML based single sign-on can be implemented which helps in
reducing the multi-tenant issues in a SaaS application without comprimising on the
security standards. In the process of evaluation, the requirement that is considered
is to provide a single sign-on solution to a SaaS application where the tenants of the
application are educational institutions. To provide a loosely coupled implementation
and to compare and contrast on communication cost and storage cost between SAML
based single sign-on and user directory based authentication, an experiment would be
carried out on the following points.
• Create a public cloud instance in a cloud provider (Amazon web services or Azure
or Openstack)
• Create an SaaS application using JAVA language and Spring framework
• Create SAML based configuration that is required for single sign-on
20
29. • As the tenants are educational institutions, build a trust with Edugate which
manages the network of all the educational institutions.
• Configure the SaaS application as a service provider with the Edugare Resource
Registry
• Create trust through Edugate, with the identity federations of the educational
institutions that are considered as tenants within in the SaaS application.
• The necessary configurations are added in the SaaS application which include
importing identity federation public certificate, creating key pair for the ser-
vice provider, configure the metadata XML of the IDP and register the Service
provider metadata XML with the Edugate Resource Registry.
• After the implementation of loosely coupled single sign-on solution, the applica-
tion is deployed in a public cloud instance
• The users are validated based on the tenant configuration through the single
sign-on model or the existing user directory authentication.
• If the user belongs to tenant that is single sign-on based, then the user is redirected
to the sign-in page of the respective tenant’s identity federation login page.
• If the user belongs to a tenant that is not single sign-on based, then the user is
redirected to a sign-in page which is native to the SaaS application.
• Authentication is performed based on the tenant configuration.
• Once the users are authenticated, they would be able to access the features of the
application.
• Statistical analysis is provided to analyse on the communication cost and storage
cost based on the authentication applied.
• Entire configuration of the SAML based sign-on is provided within a single con-
figuration file that will be loosely coupled and is independent of the existing SaaS
functionality.
2.6 Summary
The literature suggests that SAML is one of the most appropriate single sign-on
solutions that could be used in an environment like SaaS where the application is
accessed by multiple tenants. Though Cloud computing has gained popularity, there
21
30. continues to be concerns related to multi tenancy and the solution would be to provide
a single sign-on solution. This dissertation primarily focusses on providing a loosely
coupled single sign-on solution to SaaS based applications to reduce the issues of
multi-tenancy. This dissertation has critically analysed various single sign-on solutions
that mainly help in reducing the multi tenancy issues. Based on the analysis, it is
concluded that though there are various single sign-on solutions, it all depends on
the requirement and the purpose. Single sign-on solutions like OAuth, OpenId and
SAML does not fit to all kinds of requirements. In the scope of this dissertaion, as the
requirement is related to tenants that belong to enterprises, SAML has been considered.
Based on the above analysis, it is evident that SAML helps in providing single
sign-on solution to enterprises or organizations and has support to various protocols.
Along with the above features, SAML is highly secured in terms of transmitting data
and follows XML as mode of communication. The novelty of this dissertation would
be to implement a loosely coupled SAML based single sign-on solution.
We can conclude that a loosely coupled SAML implementation can be implemented to
reduce multi-tenant issues and manage identities in a SaaS based application deployed
in a public cloud.
22
31. Chapter 3
Specification
The scope of this industry dissertation is to implement single sign-on using SAML
for a SaaS application environment and to prevent multi-tenancy issues. The im-
plementation should be also able to manage identities of various customers. Apart
from the implementation, the implementation provided will be loosely coupled within
the application to avoid dependencies which helps in better maintenance of SaaS
applications. The novelty behind this research is to implement loosely coupled SAML
implementation in a SaaS application in creating a SSO model and overcoming the
issues of multi-tenancy in SaaS environment deployed on public cloud.
In general, most of the enterprise applications use authentication to validate the
user credentials. Some of the authentication schemes which are used are database
validation and in the recent trends, identity management frameworks like SAML,
OAUTH and OPenID are being used. Organizations and enterprises in the current
industry mostly prefer to use SAML because of its support to the enterprise world in
terms of identity management. But organizations prefer to use their own framework
for implementing SAML. In spite of their preference, necessary care should be taken
care to ensure that security is not compromised, in specific to applications that are
deployed in cloud environment. Based on the research, it is clear that SAML would
be an obvious choice for enterprises to provide a SSO model and manage identities.
Moreover, the SAML implementation provided should be loosely coupled within the
application and be able to manage identities.
Public cloud is an environment where storage could be shared by multi-tenants
and are prone to security issues. There is a huge risk of compromising on the data
privacy. As data is one of the important assets of an application, it is very important
23
32. to ensure that the data is properly managed by restricting access to the data. Access
is restricted by means of employing right authentication mechanism based on the
environment. As the use case is related to authentication in organizations/enterprises,
SAML comes to the rescue, as it can address the issue of authentication by providing a
SSO model and better security standards. Most of the traditional web applications that
are deployed in non-cloud environment use database or user directory authentication
system. It does not create any risk to the application as the storage is application
specific and the data storage is not shared by other application generally. But if the
applications are migrated to a cloud environment as SaaS especially public cloud, then
one of the major concerns that need to be addressed is multi-tenancy. Based on the
above mentioned details, this research would carry out the implementation of SAML
which is loosely coupled and build a SSO model for SaaS applications in a public cloud
environment.
To carry out the above mentioned dissertation, a SaaS application in the field
of education domain is considered. Some of the features that are available in
this SaaS application are login management, user account management and better
search mechanism in accessing journals/publications. Due to security reasons,
every user of the SaaS application needs to be authenticated before accessing
the application. Authentication mechanisms that are involved in the case study are
identity federated SSO model using SAML and database/user directory authentication.
Using the above mentioned case study, this research would implement a loosely
coupled SAML implementation which provides a SSO model to all the tenants of SaaS
application. This research also analyses the performances of SAML implementation
over traditional user directory/database implementation in a public cloud.
24
33. Chapter 4
Design
This section details on the implementation strategy that is employed in creating a
SaaS based web application for the case study. As the industry dissertation is more
oriented on traditional SaaS web applications in specific education domain, some of the
patterns and frameworks that are chosen in designing the application, libraries used
are mentioned in the following sections
4.1 Role of HEAnet and Edugate in the implementation
HEAnetHEAnet (2014) is Ireland’s national education and research network which
connects Irish universities, research organizations, higher education institutes and tech-
nology institutes. HEAnetHEAnet (2014) provides e-infrastructure services to all the
educational and research organizations across Ireland. EdugateEdugate (2014a) is a
federation service operated by HEAnetHEAnet (2014) and is a gateway for exchanging
information about users and resources of various Irish higher education institutions and
research organizations. EdugateEdugate (2014a) works by building a trust between
service provider and identity provider. EdugateEdugate (2014a) is built using open
standard SAML which is recommended by Cloud Security Alliance as the preferred
single sign-on mechanism in the view of cloud security. Using SAML, EdugateEdugate
(2014a) creates a federated access and provides single sign-on without any risks.
The single sign-on feature that is to be implemented is for a SaaS application that
validates users of every tenant with various educational institutions across Ireland.
Based on the requirement, it is an obvious choice to choose SAML as it supports single
sign-on for organizations and enterprises. Moreover, as the requirement is in specific to
educational institutions, the resource registry of EdugateEdugate (2014b) federation is
25
34. also accessed to register the SaaS application as service provider.
4.2 Application architecture
Figure 4.1: Architecture diagram
The main components that are involved in the architecture (Fig. 4.1) are Login
module, controller layer, service layer, data base layer, view component, service classes
and database. The reason behind choosing separate layers for login module, controller,
service and database is to make sure that components are loosely coupled. This would
help in easier maintenance of code and modularising the functionalities. Login module
is independent of tenants and necessary respective authentication module is loaded
based on the tenant. Controller layer is dependent on service layer and service layer is
dependent on DAO layer. The dependency objects are created by using dependency
injection design pattern which uses inversion of control to instantiate the dependent
object. Controller layer would take care of receiving request and sending response
objects. View layer would be the component that takes care of the user interface and
is responsible for rendering the content with the help of data in the model object.
The design of this application is made by choosing MVC architecture pattern. Service
layer is where all the services can be located. In the scope of the research, all the
authentication implementation modules are loosely coupled with login module and are
accessible in this layer. Database layer communicates with the database. Database
layer is the component that handles all the Create, Read, Update and Delete (CRUD)
operations related to database.
26
35. Figure 4.2: Authentication Module diagram
The authentication module (Fig. 4.2) provides a deeper view in which respective au-
thentication modules is loaded. When a request is sent from the user for logging into
the application, authentication module will check for the tenant from which the request
is being sent. The authentication module will check for the tenants configuration and
loads the respective authentication implementation for the user to validate their cre-
dentials. This could be either SAML implementation or user directory validation based
on the tenants configuration.
Figure 4.3: SAML authentication sequence diagram
The figures (Fig. 4.3) and (Fig. 4.4) detail more on the flow of control within the
application when SAML and user directory / database authentication are applied.
27
36. Figure 4.4: User directory / Database sequence diagram
When a login request is sent from the user, it is received by the login controller of
the SaaS application that is deployed on an application server in public cloud. Login
controller redirects the respective sign in page to the user by validating if the user
belongs to SAML customer or not. If the user is not a SAML customer then the sign in
page of the application is rendered to the user and the user provides login credentials
for validation which are stored in business object and sent to service layer. Service
layer process the request and forwards to the DAO layer. DAO layer will validate the
user credentials stored in the business object against the user directory or database.
DAO layer stores the validation result in a business object and forwards the response
back to controller via service layer. Controller layer then updates the view of the
request by updating the response object.
If the user is a SAML user as validated by login controller, then the user is
redirected to the respective identity provider sign in page and not to the application
specific sign in page. The entire control is transferred to the identity provider. User
will use the identity provider specific login credentials. Once the user is validated, the
identity provider sends a SAML response back to the user. On successful validation,
SAML response comes along with user specific attributes which are used to identify
the user from the SaaS application. SaaS application stores the attributes in the
business objects for tracking the user activities within the application. On unsuccessful
validation, the user is not allowed to access the SaaS application. Using SAML, the
overhead of storing the user credentials in database and transferring the request calls
through service layer and DAO layer can be avoided. Moreover, when di↵erent tenants
are accessing the SaaS application, the respective users will be routed to the tenant
28
37. specific identity provider application for authenticating the users.
Figure (Fig. 4.5) details more on the components that are involved in the de-
Figure 4.5: Component diagram
sign of the application. Application will be developed using Java programming
language and Spring application framework. The application is then compiled using a
build tool and web archive file (WAR) is created. The created war file is then moved
onto a public cloud environment for deployment. Application server and database
server should be made available in public cloud for the application as mentioned in the
(Fig. 4.5). Once the WAR file is moved onto the cloud, it should be deployed on the
application server. Once the application server is started, the application is ready for
use.
29
38. Figure 4.6: MVC architecture
4.3 Design decisions
4.3.1 MVC Architecture
Model View - Controller (MVC) is one of the architecture patterns. MVC is
divided into three di↵erent components namely Model, View and Controller. View
is a component which is related to the user interface and can also be stated as the
representational form of the data that is rendered to the user. Model is a component
that contains the logical data structure related to the application. Model does not
contain any details related to the user interface and contains only data and business
rules that are related to functionality. Controller is the component that communicates
between the model and the view. Controller sends requests to the model and model
updates its state. Controller can also send requests to its related view component and
the view renders the content as output.
The reasons behind choosing MVC as the architecture of the case study are as
follows
1. MVC is widely used in most of the web applications as the base architecture
2. MVC helps in separation of concerns where every component is designated with
a distinct role and there is a clear separation between the presentation layer and
the business layer
30
39. 3. Helps in maintenance and parallel development of code
4.3.2 Programming language and Application framework
Java is platform independent language which means that program can be compiled
once and can be run on any machine. Java is an object oriented language which helps
in providing features like inheritance, abstraction and encapsulation. Java is also
compatible in distributed environment due to the inherent features available in terms
of networking capability. Java also supports multithreaded environment. Java is rich
in support for several libraries and packages.
For the research, Java suits the best due to the above mentioned features. Apart from
the above mentioned features, Java has rich library support in terms of processing
XML which comes as response from the IDP and moreover it is platform independent.
Spring application framework is one of the popular web application frameworks
that are used for developing web applications. Spring is a light weight container.
Spring provides some distinct features like dependency injection, singleton and aspect
oriented programming. Dependency injection is a concept where the dependent object
is directly injected to the program by the container. This enables loose coupling of
objects. Singleton is a design pattern where only one instance of a class is created
and helps in providing restricted control on the object instantiation. Aspect oriented
programming (AOP) is a paradigm that helps in separating cross cutting concerns.
Separate modules created based on functionality are called as concerns. AOP helps in
adding these concerns at runtime to the existing application framework.
In the aspect of research, spring framework is chosen because of the above men-
tioned features like dependency injection and singleton and AOP. Loosely coupled
feature of Spring framework helps in injecting SAML authentication module with ease.
The injected SAML module will be independent and will not have any dependency on
the existing code. In addition to these features, Spring framework has rich support to
web application as it supports some of the design patterns like MVC, Front controller
and View Helper. Front controller design pattern helps in routing the requests to the
respective application controllers. View helper design pattern helps in mapping the
view objects to the presentation layer.
31
40. 4.3.3 Public cloud
Public cloud is a computing model where the resources such as applications, storage,
network and compute are made available to public users over internet. Cloud en-
vironment generally works on pay-as-you-go basis where resources that are required
for an application are available instantly. Some of the benefits of public cloud are
scalability, availability, broad network access, resource pooling and measured service.
Multi-tenancy is one of the main concerns in terms of security. Multi-tenancy creates
a risk in data privacy as the same resource could be shared by multiple users. Unlike
private cloud, public cloud is more prone to issues related to security because of its
access over internet to any user. Reason for choosing SAML implemented SSO model
in SaaS application is to accomodate multiple tenants and manage their users authen-
tication with ease. In the scope of research, a public cloud environment would be setup
by using any of the cloud service providers like Amazon or Azure.
4.3.4 Tools used
KeyTool.exe: KeyTool is an executable that helps in generating public keys and pri-
vate keys along with managing certificates. This executable comes along with Java
installation and can be located at bin folder of the installation directory. To communi-
cate with the identity provider and create trust, public certificate and private key can
be generated using this tool which helps in building a secure boundary and increases
security of the system.
Apache Maven: Maven is a product of Apache and build automation tool. This
library is written in Java and is executed using a command line tool. The main purpose
of this tool is to build applications written in Java. Using Maven tool, it is easier to
create web archive file of the entire application. Maven tool takes inputs of all the
source files that are to be compiled and then creates a war file that can be moved to an
application server for deployment. The entire project is represented in Project Object
Model(POM) file which follows XML semantics.
Eclipse IDE: Eclipse IDE is an integrated development environment for developing
Java based applications. It has rich plugin support that can aid the applications.
Eclipse is a open source software. Servers also can be integrated within the IDE itself.
Debug tool in eclipse: Debug tool can be enabled in Eclipse. It can be used to
monitor runtime values and the flow of code can be debugged. This is used to monitor
the SAML request and response values that are communicated within the flow of SAML
32
41. authentication. This also helps in tracking the attributes that are attached to the SAML
response upon successful authentication.
33
42. Chapter 5
Implementation
The loosely coupled implementation of single sign-on using SAML which is an open
standard and Edugate as federation service is successful in a SaaS application where
multiple tenants access the same application.
5.1 Configurations involved in the process of implemen-
tation
The main components that are involved in the implementation process are
1. Create a Java Key Store(JKS) file
(a) Import certificate of the Identity Provider
(b) Public/Private key pair generation for SaaS application
2. Loosely coupled behaviour
3. Import metadata of the Identity Provider
4. Create Service Provider metadata XML
5. Register Service Provider metadata with the Identity federation
6. Mapping attributes that may be required
34
43. 5.1.1 Create a Java Key Store(JKS) file
JKS file can be generated using keytool executable. This can be found in bin directory
of JAVA installation. For eg., it can be found at C:/Program Files/Java/jre7/bin.
5.1.1.1 Import certificate of the Identity Provider
The certificate should contain the public key of the identity provider. Once the public
key is communicated by the identity provider, it is necessary to create a .cer file using
the public key of the identity provider. Identity provider can send either .cer file
directly or their metadata XML which contains public key embedded in the XML.
Once the public key is identified, a new file is created and the key is pasted. It is very
important that the key is pasted between the lines —–BEGIN CERTIFICATE—–
and —–END CERTIFICATE—–. The lines BEGIN CERTIFICATE and END
CERTIFICATE are a standard and help in identifying that the content that is enclosed
between the lines belongs to a public key. Once the file is created with the public key,
it is necessary to save the file with .cer as extension.
Command: keytool -importcert -alias userDefinedAlias -keystore JKSFileLocation
-file FileLocationOfCert
When the above command is executed, user will be prompted to create a new
Key Store password. If the .jks file is a new file, then user will be asked to re-enter the
password. If the file is an existing one, then its associated password should be entered
to update the file with a new certificate. The certificate details are displayed on the
screen and the user will be asked to confirm if the certificate can be imported. To
confirm the same, ’y’ has to be keyed in.
The above steps will help in importing the public key of the identity provider
into the JKS file.
5.1.1.2 Public/Private key pair generation for SaaS application
Key pair is a combination of both public key and private key. This can also be
generated using KeyTool.exe. This key pair is required to identify the identity of
service provider. Once the key pair is generated for the service provider, public key
has to be shared with the identity provider. Identity provider would then import the
35
44. public key as certificate in their system. This enables in building a trust between
identity provider and service provider.
In the scope of this thesis, the public key of the service provider has to be im-
ported in Edugate resource registry as it manages the identity federations of all the
educational institutions.
Command: keytool -genkeypair -alias privateKeyAlias -keypass SecurePasscode
-keystore JKSFileLocation
When the above command is executed, user will be prompted to enter key store
password of the .jks file. The password that has to be keyed in here is the one that is
used when creating the .jks file. If the file is a new one, user will be asked to re-enter
the password. If the file is an existing one, then its password should be entered to
update the file. User will also be prompted to enter values for the following fields First
Name / Last Name / Org.Unit / Org / City / State /2 letter Country code which
helps in mapping the user/organization details of the key pair. Once all the details are
provided, then the user will be asked to confirm if the details mentioned are correct.
Type ’y’ to confirm.
Once the JKS is loaded with the public certificate of identity provider and key
pair of the service provider, it is necessary to verify the contents of the created JKS
file. This helps in confirming that both the keypair and identity provider certificate
are added in the JKS file.
Command: keytool -list -v -keystore JKSFileLocation
5.1.2 Loosely coupled behaviour
Spring framework has rich support for loosely coupled objects using dependency injec-
tion. Dependency injection is a technique where the dependent objects are injected
and instantiated at runtime by the Spring container. This setup is controlled by using
setter injection or constructor injection. In terms of configuration, there are two
di↵erent ways of implementing dependency injection which are XML based and anno-
tation based. These dependent objects which are loosely coupled help in removing the
dependency whenever the dependency is not required with minimal management e↵ort.
As part of the implementation, setter injection is chosen to create the objects
36
45. that are necessary. Moreover, the entire configuration related to the SAML implemen-
tation is enclosed in a single XML and is configured in web.xml. If the implemenation
has to be modified or changed, then the cost that is involved for maintenance is very
minimal as the SAML component is loosely coupled with the existing application.
5.1.3 Import metadata of the Identity Provider
For single sign-on to be enabled, tenant should be part of a identity federation and
their respective metadata XML should be configured within our application. Once
the metadata XML is shared and configured, then the users of the tenant can use the
same federation credentials to sign-in to the SaaS application.
The multi-tenant SaaS application has to be registered within Edugate as a ser-
vice provider and access to the required federations have to be requested from within
Edugate resource registry. Once the access is granted, the metadata xml has to be
imported and the public key is added to the key store file to create trust between the
service provider and identity provider. The identity federations vary based on the
tenant and every tenant would have a metadata XML.
For example, if the tenant is an educational institution named A and has an
identity federation, then the respective metadata XML of institution A has to be
imported within the application and has to be registered with Edugate. Moreover, the
public key of the identity provider A has to be added in key store to create trust with
the service provider and to enable single sign-on.
5.1.4 Create Service Provider Metadata XML
The JKS file which is created based on the above steps has to be configured within
the SaaS application. Associated passcodes also should be configured within the
application. It is necessary to verify that JKS file comprises of the identity provider
certificate and generated key pair. The corresponding IDPs metadata URL also has to
be configured in the SaaS application. Every service provider is uniquely identified by
the IDP using entityId.
EntityID generally should be mapped to the service providers URN. EntityID
also should be mapped within the configuration file. Once the configuration file is
setup with all the necessary configuration, server has to be started. A service class
is mapped to the url pattern /saml/metadata and would be responsible to generate
37
46. 5.2 Summary
In this chapter, we have discussed about the details related to implementation of a
loosely coupled SAML single sign-on. The key technologies that are involved as part
of the implementation are Java programming language, Spring framework and SAML
open standard. The key components that are involved in the process of implementation
are creation of Service Provider key pair, importing public cert of IDP, registering SP
metadata XML with Edugate and importing IDP metadata XML. The loosely coupled
behaviour is provided by the use of Spring framework and the entire implementation
of SAML single sign-on is independent of the existing SaaS functionality. This helps in
easy maintenance and resuability which are core principles of software engineering.
39
47. Chapter 6
Evaluation
The aim of this thesis is to implement a loosely coupled SSO solution using SAML in a
public cloud and address the issue of multi-tenancy. The research method that is applied
for evaluation of this thesis is experimental research. In the view of experimental
research, the evaluation parameters that are considered to find the e cient algorithm
are communication cost and storage cost. In terms of experiment design, paired design
is used for evaluation. Sample that is considered in the case of paired design are costs of
communication and storage when SAML authentication and database authentication
are used.
6.1 Loosely Coupled implementation
The entire configuration that is related to the SAML single sign-on implementation is
implemented in one XML file. This XML configuration is independent of the existing
application configuration. The basic components that are essential to implement SAML
single sign-on are as follows
1. Metadata XML of service provider and identity provider
2. Keystore which includes public key of identity provider and key pair of service
provider
3. Passwords related to the keystore and the keypair
4. Unique entityId which is required for identifying the service provider
5. Discovery URL if required
40
48. 6. Success and Failure redirection handlers
All the above are configured in the same XML file. This XML file is configured in the
web.xml as one of the configuration files that is to be loaded when the spring container
is loaded. If SAML implementation is not required, then dereferencing the XML file
in web.xml would not load single sign-on feature. On the other hand, if some other
standard of single sign-on has to be implemented then the new configuration file can
be referenced in web.xml.
This enables a loosely coupled SAML configuration which helps in reducing the mainte-
nance cost and e↵orts. Moreover, another advantage of this loosely coupled implemen-
tation is that it will reduce the risk of modifying the existing functionality to implement
single sign-on.
6.2 Evaluation based on Storage cost and Communication
cost
6.2.1 Storage cost
In a traditional web application, user details are stored in a database. Authentication
of users is validated against the details that are stored in database. The details that are
stored in the database occupy certain amount of storage space. But if the authentication
is handled using single sign-on then we can completely avoid the need of a user table
to store user details as the validation is done by identity provider on our behalf. Single
sign-on implementation does not require any dedicated storage space to store user
credentials.
Authentication used Storage cost
Database authentication 28MB for 210527 records
SAML SSO 0 MB
Table 6.1: Table to evaluate Storage costs
During the implementation, it is found that the storage space that is occupied to store
user credentials is around 17MB for around 210527 records in users table. If the indexes
of the table are also considered, then the storage space goes upto 28MB. But for single
sign-on implementation using SAML, it is found that the application does not require
any table to store user details for validating user credentials.
In a cloud environment, the users are also charged based on the amount of storage that
is used. Based on this analysis, it is clear that the storage costs can be optimized by
41
49. Figure 6.1: Storage Cost evaluation chart
Figure 6.2: Storage used by Database for storing user credentials
using single sign-on implementations.
6.2.2 Communication cost
The implemented SaaS application is authenticated using SAML based single sign-on
and database authentication as well based on tenant. Some tenants of the SaaS
application use single sign-on model, whereas some use database authentication for
validating its user credentials. For example, if the tenant belongs to a educational
institution ABCD and is a member of Edugate federation then SAML based authen-
tication is provided for its users. If the tenant belongs to an organization that is not
a member of Edugate and is not a identity provider, then database authentication is
provided for its users.
Two factors that are evaluated in terms of communication costs are
42
50. 1. Rendering sign-in page
2. Response time for validating users
6.2.2.1 Rendering sign-in page
Rendering sign-in page varies in terms of the authentication used per tenant. If the
authentication used is based on SAML single sign-on, then the sign-in page that is
rendered on the browser belongs to the identity provider which is a third party. SaaS
application would not have a local copy of the sign-in page. Whereas if the authenti-
cation is based on database, then the sign-in page that is rendered belongs to the SaaS
application.
To evaluate the same, I considered rendering times of 5 di↵erent requests which are
used to load the sign-in page.
Request DB authentication(in secs) SAML authentication(in secs)
Request 1 1.45 1.08
Request 2 1.15 0.67
Request 3 1.19 0.84
Request 4 1.24 0.66
Request 5 1.18 0.76
Avg. Time 1.242 0.802
Table 6.2: Table to evaluate loading time of sign-in page
Figure 6.3: Rendering sign-in page
Based on the above figures, it is found that SAML based single sign-on model is 54.61%
faster than database authentication model.
43
51. 6.2.2.2 Response time for validating users
In terms of validation, in a SAML based single sign-on, the request is sent to the
identity provider who validates the user credentials and sends back response to the
user. External calls are made to the identity provider and the response is sent in the
form of XML. Based on the response, the user is allowed to access the SaaS application.
In a database authentication model, users are validated against the SaaS application’s
user database and validated. No external calls are made.
To evaluate the same, I considered 5 di↵erent requests wherein user enters the creden-
tials in both the authentication types and the response time is calculated.
Request DB authentication(in secs) SAML authentication(in secs)
Request 1 11.54 5.77
Request 2 11.38 5.79
Request 3 9.19 5.74
Request 4 9.06 5.36
Request 5 9.25 6.24
Avg. Time 10.084 5.78
Table 6.3: Table to evaluate response times after validation
Figure 6.4: Response time after validation
Based on the above figures, it is found that SAML based single sign-on model is
74.46% faster than database authentication model.
44
52. 6.3 Summary
Based on the evaluation, it is clear that a loosely coupled single sign-on solution can
be implemented using SAML open standard which helps in reducing the multi-tenant
issues in SaaS environment. Based on the above experimental research, it is clear that
SAML authentication provides the better communication cost in both rendering signin
page and validating user credentials when compared to DB authentication. Moreover,
even in terms of storage cost, SAML authentication is better than DB authentication.
In principle, SAML also has rich support to providing single sign-on solution to en-
terprises and organizations. Moreover, due to the strong security standards involved
in SAML communication, the implementation which is loosely coupled would reduce
the multi-tenant issues in SaaS environment and also creates a secure authentication
environment.
45
53. Chapter 7
Conclusions
The company’s requirements have been met and the implementation is successful. The
implementation is to provide a single sign-on solution for a SaaS based application
which would manage identities of its customers. Now, using the implementation
based on SAML, every customer can be able to login into the SaaS based application
using their credentials registered at identity provider. This implementation also
avoids customers from registering within the SaaS application to gain access. Instead,
using their credentials registered at identity provider, they can login and access the
application.
Single sign-on is a solution which helps in reducing the number of registrations
that user has to create per application and also helps is reusing their existing creden-
tials registered with an identity provider. OAuth, SAML, OpenID are few standards
which help in building a single sign-on solution. These standards cannot be applied
to all sorts of requirements and has to be applied based on need. By referring a few
articles, it has been identified that OAuth helps in authorizing API calls between web
applications and primarily used for authorizing the user to access a resource. OpenID
is used to authenticate users but the system has to be OpenID enabled and user needs
to have an OpenID enabled account registered with an OpenID provider. Whereas
SAML is primarily for both authorization and authentication. Morevoer, SAML is
used to provide single sign-on solution to enterprises or organizations. This made us
choose SAML as the thesis is related to providing single sign-on solution to educational
institutions.
More than providing a single sign-on solution to avoid the problem of multi tenancy
in SaaS applications, the thesis identified the need to develop a loosely coupled
46
54. SAML implementation. This helps in developing a single sign-on component which is
independent of the existing SaaS application functionality. The entire implementation
is consolidated in a single XML file and is configured in the web.xml file. Using Spring
framework, the configuration file is recognized at runtime and the necessary single
sign-on implementation is added to the existing SaaS application. The implementation
can be treated as a plugin which can be added or removed or modified based on the
need and necessity. The main advantage of the loosely coupled implementation is
to upgrade the existing SAML standard by adding more security measures without
much of maintenance cost. Moreover, if there is any upcoming standard that is more
powerful and suits the best to the requirement, then it can be easily plugged into
the existing SaaS functionality as the current SAML implementation is loosely coupled.
The implementation is done based on the design and the results were working
as expected. The implemented single sign-on solution is also evaluated against
the conventional user directory authentication and the results were positive. The
turnaround time of SAML single sign-on solution was very e cient as well when
compared with user directory authentication. Even in terms of storage cost, the
amount that is spent on storage is reduced a lot as there would not be any need to
store the user authentication details. As the implementation that is provided is loosely
coupled, it helped a lot in configuring the tenants of the SaaS application very easily.
The implementation also ensured that the existing user directory implementation is not
modified and is intact. Moreover, it has provided an alternative way to authenticate
other tenants using single sign-on solution provided they have valid credentials with
the identity provider. Just by minimum configuration in the database configuration, a
tenant can be considered as a single sign-on tenant or a user directory based tenant.
Therefore, it is definitely possible to create a loosely coupled single sign-on so-
lution using SAML open standard that helps in authenticating and managing identities
of a SaaS application. Moreover, it also helps in reducing the multi-tenant issues of
SaaS application.
7.1 Future work
In the current implementation, there have been a few modules like creating key pair,
importing public certificate of identity provider, generating metadata XML of service
provider and importing the metadata XML of the identity provider. Once the modules
are generated, then the same has to be configured in the configuration file. As part of
the future work, it would be better if a tool is developed to perform all these operations
47
55. and generate the configuration file. This would help in reusability and moreover helps
in maintaining the configuration file e↵ectively and e ciently as the entire process is
system driven.
Another future work that has been identified is in terms of the single sign-on
standard that is used. Currently, the solution is implemented based on SAML which
is an open standard and suits the requirement which is related to providing single
sign-on solution to enterprises or organizations. Though there are many popular
frameworks like OAuth and OpenID, based on the requirement and the features of
SAML supporting the requirement, we were left with no choice rather than to choose
SAML. However, there is one new open standard named OpenID Connect which is
gaining popularity in the single sign-on community. The key features of OpenID
Connect are that it helps in creating a design flow which is simple enough and moreover
supports both authentication and authorization. It is built upon OAuth 2.0 framework
and supports mobile applications as well. OpenID Connect also adheres to all the
security standards, also works based on JSON/REST protocol which is simpler and is
easier to implement. Very few organizations like Google, Microsoft and salesforce.com
have started using OpenID Connect. This could be one such future work that can be
added to provide better single sign-on solution.
In terms of evaluation, in the current dissertation, turnaround time of response
during rendering of sign in page, response after authentication and storage costs
are considered. However, as part of future work even network latency can also be
considered as one of the evaluation parameters. Evaluation can also be done by
considering low speed network as well to provide better comparison results.
48
