8 key points to securing your Saas applications
Are you creating a security system for a SaaS application? This
article is here to help! It lists the important questions to ask from the
beginning of your project to avoid security breaches or functional limitations
that will hold you back later.
Ideally, the security of your SaaS application should
combine both strength and flexibility:
System strength will guarantee application security
Controlling user access within the limits of their subscription
Assuring data confidentiality between the users sharing the
Eliminating security breaches at protecting you from exterior
System flexibility will contribute to the development
of your business by:
Facilitating the evolution of your business model and the
creation of your offer
Responding to client needs related to user management (see below)
Supporting scalability: optimizing performance and simplifying
administration of large numbers of users and secured components
This article lists the technical and functional
specifications allowing you to attain both goals. It will help you
conceptualize the security of your SaaS application, taking into account
important constraints from the beginning of your project. You will thus be able
to cover short terms needs, while at the same time anticipation any future
evolutions necessary to the development of your business.
Administration: centralize or delegate?
you may be managing users and access rights yourself.
the volume of users increases, you – and your clients – may wish to delegate
certain administration rights so that your clients are managing their users and
this is the case, you will need:
administration interface accessible to non-technical users. You can then
delegate user administration to local business managers
administration interface should offer all required access control
functions via the Internet (account management, assignment of groups and
access rights, visibility and control of security data…)
you develop a multi-tenant Saas application (a single instance of the
application used by multiple clients), you should restrain client
administration rights to their own user accounts: you don’t want them to be able
to modify another client’s accounts! More generally, you can restrict delegated
access rights in three ways:
user account administration to a client, or a subset of the clients’
the types of administration operations.
administration to certain application.
all these possible scenarios, you need to plan a flexible access control system,
allowing you to delegate several levels of administration rights, according to
your clients’ internal organization and needs.
Deployment in the Cloud
- Adapt the system to the chosen platform. In the case of
Windows AZURE, you must take into account the specifications of the
operating system and SQL Azure.
- Adapt the scalability and sizing of your server resources
according to the needs of your SaaS application
Pay-per-use Billing and Payment
If your business model is based on a pay-per-use SaaS model,
or includes temporary use rights, you will access control system must support:
accounts with a limited time span
API enabling collaboration with a billing system to automatically update
the expiry date of each account
user interface that allows the sales team or helpdesk to modify this
information – for example, the treatment of unique cases or errors, taken
immediately into effect for the user
Single Sign-On (SSO): a must for software suites
If your product catalogue is composed of a suite of
applications, your access control system should probably include Single Sign-On
to simplify the user experience:
- The user will be able to access multiple applications,
passing freely from one to another
- If the applications make calls to Secured Web Services,
the user will also be authenticated for each web service used
- The user will log in to the first site and will then be
able to access other sites without having to re-enter their credentials
A typical SSO system for SaaS applications includes the
1 – User session management:
When the user passes from one site to another, the SSO
- Identify the user
- Recreate their session for each site visited
- Load the security data (attributes, roles, permissions…)
To accomplish this, mechanisms to manage security tokens
should be included (to create, transfer and secure the tokens). These
mechanisms must be optimized, to avoid overloading the server (you cannot
“simply” authenticate a user and then reload their security for each page
visited: the response times become too long when the number of visits
2 – Provide a Single Sign-On front-end:
A front-end authentication portal should:
- Allow a user to authenticate before accessing a website
- Memorize all or a part of a user’s credentials to avoid
requiring users to re-enter them on each visit (for example, the username
- Automatically redirect users that navigate between sites
federated by the same SSO: the user will immediately arrive at the second
site and their security profile is automatically applied
3 – Facilitate the integration of applications into the
- Ideally, the integration of SSO should not require any
changes in the application
- The integration process should be the same no matter the
type of application and the development technology used
- It is likely that SSO will be used by developers other
than those that created it. You should plan for corresponding
documentation and assistance
4 – Support for complex configurations:
According to your needs, the Single Sign-On system may need
to support the following situations:
- Not all sites are on the same network (LAN or WAN)
- Not all user accounts are stored in the same network as
- Not all sites are under the same web domain
- Not all sites are developed in the same technology
What if your users could reuse existing accounts?
default, you will create a new account for each user that needs to access the
problem with this is that a user will already have multiple accounts to
clients may wish to reuse their existing user accounts (for example, their
Windows accounts). Your access control system should therefore permit giving
these accounts access rights to your applications.
Anticipate changes in your business model:
An access control system is often tied to the business model
(pay-per-use or perpetual license) and to the software delivery model (Saas or
Depending on your company’s strategy and the evolution of
the market, your initial go-to-market strategy may be filled out by other
models (for example, to serve new client categories or increase your line of
Your security system should allow for this type of
Here are several of the most pertinent models your company
may want to look at:
Case 1: Default SaaS model.
The application is hosted by the vendor
with the security system. Users access it via the Internet.
Customers pay to use your application on a
time-limited, recurring basis.
Business model: pay-per-use
Software delivery model: SaaS
2: For security or technical reasons, customers may request that you install
the application in their environment. Users access it via LAN or Internet.
The vendor still manages the Access Control: customers pay to use the
application on a time-limited, recurring basis.
Business model: pay-per-use
Software delivery model: on-premise
Case 3: Clients
wish to reuse their user accounts (for example, their Windows accounts).
The access control system should therefore be able to give
existing accounts access to your SaaS applications.
Business model: pay-per-use
Software delivery model: SaaS
Case 4: Classic software delivery model. The
client owns a copy of the application. They manage access control
The software vendor can add this model to their catalogue
(in addition to a SaaS model) to increase their product offering.
The access control system should be easily deployed to
clients (simple and sound administration tools, completed documentation…).
For all that, this type of deployment does not prohibit a
pay-per-use model. For that, you will need a system that manages license keys
on a time-limited basis.
Business model: pay-per-use or perpetual license
Software delivery model: on-premise
Reliability and Performance:
The administration interface must be conceived to manage
large numbers of users and access rights (to guide the administrator performing
operations and searches, optimize the response time of the security
When the SaaS application is in to production, the user
authentication process and the calculation of their access rights must be optimized
to avoid long wait times. For example, a system that needs to access the
security repository each time a user opens a new page has a greater chance of
performance issues when the number of users and page views increases.
Protection against Security breaches:
Since a SaaS application is accessible via the internet and
manages client data, it is necessary to create a system that will not be
vulnerable to the following types of the most common attacks:
Unauthorized access to security data:
- Security data should not be readable by direct SQL access.
You should require a connection via the SaaS application or via the
administration interface to read and modify this data.
- Sensitive data like passwords should be
Denial-of-service: the access control system should
include protection against attempts to make it unavailable to customers by
saturating it with numerous logon requests.
Unauthorized administration operations: a user could
discover how to access the administration interface or the APIs that manage
access control. You need to include protection that blocks giving supplementary
access rights to user accounts.
Interception of confidential information:
- Between the client browser and the web server (Support for
SSL/HTTPS protocols, encryption of communications between the browser and
the web server…).
- Between the .NET components inside the SaaS application.
Password cracking: the access control system should
allow you to define a sophisticated Password Policy to protect against password
cracking (guessing a password via trial and error).
Packet sniffing: the access control system should
include protection against the capture of data packets to find passwords or
security tokens in transit over the network. A hacker could steal these tokens
to make calls to the system as though they were a user.
The access control system probably contains search fields –
for example, to find a user account. You need to pre-arm this system against
SQL injections, which consist of inserting parts of SQL orders in the search,
with the goal of consulting confidential information, or illegally changing the
Make or buy?
Timeframe is key: we’ve seen in this article that
security and access control for SaaS applications involve complex functionalities.
If you are working on an internal project, they require a significant time
commitment and skilled developers.
If you are working in a limited timeframe or the required
expertise is not available, a ready-to-use access control solution may be the
Risk management: a ready-to-use solution will
limit short-term risks (cost and time overruns, bugs and security breaches),
but you will be exposed to other risks for which you will need to cover:
Evolution: consult the history and past versions of the
solution: does it follow the technical evolutions of the market; are new
versions published regularly, and most importantly, recently (risk of
and support quality: choose a stable and well-deployed solution, for which
you can consult the reviews of other users
what will happen if the solution provider disappears? Is the solution
delivered with its source code? Does the provider propose an escrow
agreement (a copy of the source code is deposited with a third party who
will send it to all clients if there is an interruption in service by the
not combine all these advantages? If providers are attentive to their
users’ needs when choosing how to continually evolve their application with the
market, you will benefit from the advantages of a standard solution (more
stable and complete at a lower cost) while being able to influence future
development to better cover your specific needs. Ask to see the product roadmap
and verify if the provider knows how to take into account user suggestions.