8 key points to securing your Saas applications
Abstract:
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.
Introduction:
Ideally, the security of your SaaS application should combine both strength and
flexibility:
System strength will guarantee application security by:
- Controlling user access within the limits of their subscription
- Assuring data confidentiality between the users sharing the application
- Eliminating security breaches at protecting you from exterior attacks
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?
Initially, you may be managing users and access rights yourself.
As 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
accounts themselves.
If this is the case, you will need:
- An administration interface accessible to non-technical users. You can
then delegate user administration to local business managers
- This 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...)
If 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:
- Limit user account administration to a client, or a subset of the
clients' users.
- Limit the types of administration operations.
- Limit administration to certain application.
With 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:
- User accounts with a limited time span
- An API enabling collaboration with a billing system to automatically
update the expiry date of each account
- A 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 (Single Sign-On)
A typical SSO system for SaaS applications includes the following
functionalities:
- User session management:
When the user passes from one site to another, the SSO system should
-
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 increases).
- 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 and password)
-
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
- Facilitate the integration of applications into the SSO system:
-
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
- 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 the SSO
-
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?
By default, you will create a new account for each user that needs to access the
SaaS application.
The problem with this is that a user will already have multiple accounts to
remember.
Certain 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 on premise)
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 products).
Your security system should allow for this type of evolution.
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
Case 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 themselves.
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 repository...).
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 encrypted.
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.
SQL injection:
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 security data.
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 best solution.
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 obsolescence)?
- Product and support quality: choose a stable and well-deployed solution, for
which you can consult the reviews of other users
- Longevity: 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 provider)?
Why 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.
Alok PandeyPosted Dec 5, 2011, 11:09 PM
Very useful article. Thanks for sharing.
Akash AhlawatPosted Dec 5, 2011, 10:52 PM
I am looking for this information from a long time. Thanks for providing.
Arjun PanwarPosted Dec 5, 2011, 10:51 PM
Good work by Mr. VG, Thanks .
Prashant ChaudharyPosted Dec 5, 2011, 10:51 PM
Hope to see some more articles like this
Dinesh BeniwalPosted Dec 3, 2011, 10:27 PM
Thanks for sharing, Welcome to the Mindcracker Community.