In this article I want to think about security. This is both the security that governs the rights of access to the system and the access that is then granted to a user accpording to the policies implemented within Sage CRM.

One of the first things to note about the difference between the classic SOAP web services and the RESTful web services that use SData is that the SData APIs are sessionless.

To help us understand what I mean by that look at the image below.

I have used the sysadmin flag to list out the current open sessions on a instance of Sage CRM.

http://[servername]/[instancename]/eware.dll/sysadmin

This shows that Susan Maye has logged on twice, one of which was through the SOAP web services. The important thing to note is that a session has been created for her. The application server is now keeping a record of that SOAP werb services session within the system. In fact this session information would then be recorded within the Activity table in Sage CRM. The session ID is used by the SOAP web services to relate requests back to the distinct session.

BUT SData is an example of a communications protocol that is session less or strictly speaking it is stateless. This means that the Sage CRM server treats each SData request as an independent transaction that has no link to any previous request. Each request and its response are independent of any previous or subsequent request.

Sage CRM does not keep a record of 'session' for RESTful API calls.

This creates a couple of differences between the two types of web service.

1. Firstly, in order for a user's credentials to available as a 'logon' for the SOAP web services that user has to be enabled. But within the RESTful API all users are immediately available to access the system using SData.
2. Secondly the authentication mechanism is different. Within the SOAP webservices a logon method is first called, a session is created and maintained on the server and that session id has to be passed in subsequent SOAP messages. The RESTful API however uses the idea of passing the credentials within each request from the browser. The browser or client is responsible for maintaining the connection.

Authentication in the RESTful API can be done either by passing the credentials as a result of a challenge and response.

Or by including the credentials in the HTTP header as basic access authentication that we have seen in the earlier articles in this series.

But the basic access authentication can also be passed as headers in code e.g.

Any valid user credentials within Sage CRM that can be used to logon through the main interface can be used to with SData and the RESTful. But what they see or do is subject to rights defined by the security profile and field level security.

All requests must be authenticated and then access to the data is limited in the same way the user's access is controlled within the interface.

It is important to emphasise that access to data via the REST based interface is controlled by security profiles. That has the effect of limiting access to rows within entities and views. Field level security will also limit the columns that are returned within the generated XML.

The SData based RESTful web service provides a very easy way of allowing 3rd Party application access to 'Group-like' data while at the same time ensuring strict security.

In my next article I will start to explain some of the limitations of further developing the CRUD capabilities of the classic SOAP web services in contrast with the enhancement of the SData based RESTful API to include full CRUD and more.

The articles in the series are:

1. Sage CRM's RESTful API, An Introduction
2. Architecture and Web Services
3. Working with an instance of Sage CRM
4. Extending query access to custom entities and views in SData
5. Thinking about security
6. SOAP CRUD vs REST CRUD
7. Limitations of SData 1.1
8. Compatibility as a priority
9. What is JSON?
10. SData 2.0 CRUD