While building a SaaS application, it’s extremely important to support other gateways to access the application features. In today’s world the number of devices that can access your SaaS application is only growing by the hour. Therefore, you need to have a proper design strategy in place to have a sustainable solution for inter/intra access of your SaaS solution.

Two of the most common gateways that are typically supported by SaaS Applications are,

1. Mobile applications offered by the SaaS provider
2. Services encompassing the features that can be integrated with external applications

REST services are the most preferred way of exposing these services to the above mentioned gateways. While technologies today make it quite easier to develop and provide these services, there are still lots of questions around its security. To get to the roots of the problem we are trying to solve let us understand what we mean by “Security of REST API”. Security of REST API is,

· Prevention and detection of unauthorized action

· Confidentiality and integrity of data

A series of steps are required to be performed by the REST API to ensure the above,

Client Authentication: Understand and authentication the client which is performing the action.

Tenant Identification: Understand the identity of the user who is performing the action.

User Identification: Understand the identity of the user who is performing the action/ Understand the identity of the user on behalf of which the action is done. This can be a direct identity used by the SaaS provider or it can be an alias identity for the tenant.

User Authentication: Authenticate the identity of the user. User authentication itself can be done against the store of the SaaS provider or can be a federated/openID authentication.

Action Authorization: Authorize if the identified user can perform the requested calls.

Tenant Boundary Verification: Authorize if the identified tenant can access the data of the requested tenant.

Data Access Authorization: Authorize if the identified user can access the requested data.

Data Access Permission: Get the permission from the user to access the data within another client.

The clients for the SaaS REST API can be broadly categorized as,

• External Customer Applications: These are individual on-premise or native mobile applications possessed by Customers of the SaaS solution. These apps need to integrate with the SaaS application via REST services.
• Internal SaaS provider Applications: This is either the native mobile application provided by the SaaS provider or the SaaS application rich user interfaces Javascripts directly accessing the business service data.

The requirements in terms of the security varies between the above two categories.

Requirements for External Tenant Application Integration 

1. Security model needs to authenticate and identify the client making the call.
2. Security model needs to identify the tenant from the client.
3. The client can opt for “Full Tenant Access” and may demand access to all the data within the tenant in which case user authentication can be skipped and just the user identification is enough. The client can opt to send the direct identity of the SaaS provider or an alias identity (identity that is used by the client) which is then resolved at the SaaS provider’s end.
4. The client can also opt to make the REST service responsible to authenticate the end users in which case the security should also authenticate the end user (Usually they are taken to an interface where they are demanded for authentication information). The authentication can be a proprietary authentication or can be via federation or open id authentication.
5. Security model needs to ensure that the data that is requested is within the access levels of the identified tenant.
6. If the client has not opted for Full Access then the action and the data has to be authorized for the identified tenant. Explicit permission can also be demanded from the user to access their data within the client application.

Solution:

While there are many ways to implement the above mentioned requirements, it is better to have a solution that is non- proprietary. Since there will be a number of customer applications requiring integration and it is easier for the customer applications also to adopt to a standard mechanism.

Some of the implementations used by SaaS leaders are,

a.        Google – OAuth.

b.       Amazon Services – HMAC (keyed-hash message authentication code).

Among the two, OAuth is being widely adopted for external integration as a standard for REST API security by many applications. Hence, it is minimally required to support OAuth for the external Tenant application integration.

Requirement for Internal Application Integration

1. The security needs to authenticate and identify the client making the call and verify that is an internal client.
2. In this scenario the REST APIs can trust the client to access data of any user across tenants and hence user identification alone is enough.

Solution:

As you can see the security requirements from the internal applications is more at a client authentication level and hence a light weight mechanism is sufficient. In these cases, Standards like OAuth can increase the overhead especially if the authentication server and the resource owner are the same. Therefore for internal REST API security a proprietary solution can be adopted.

Light weight session token is a widely used design pattern that many native applications use. In this case the resource owner authenticates the client along with the user authentication/ identification details (can also contain hardware details) and generates a session token which is stored with a time out. This is then passed on with every request in a header from the client. SSL is used as a transport security. Resource owner then verifies the session token, its expiry and the same token is used to identify the user as well.

For the internal JS client, cookie based identification is the mostly adopted way for user identification. For data security in both the cases TLS can be used.

In case of any queries please feel free to contact me at [email protected]

Visit http://techcello.com for more details on SaaS Architecture and Multi-Tenant Framework.