Using SData 2.0 in Sage CRM: Part 5 - A word on authentication

In this last post in this series on using SData 2.0 in Sage CRM, I just want to leave some comments on authenticating with SData 2.0. If you

In this last post in this series on using SData 2.0 in Sage CRM, I just want to leave some comments on authenticating with SData 2.0. If you don't have a clue how SData 2.0 works then I highly suggest you go through the rest of the articles in this series linked at the bottom of this post.

SData 2.0 provides multiple authentication methods.  The best method is based on the environment in which you are using SData 2.0.  This blog will cover the different authentication methods and when best to use each one.

Login Credentials

As you have seen in the previous posts, we have been using our Sage CRM login credentials to access SData 2.0. SData 2.0 uses Basic Auth which is supported by pretty much all major AJAX libraries. While seemingly straight-forward, there are some things to decide on when choosing this method of authentication.

Let the user login

If your application requires each Sage CRM user to log into the application, then you can simply use that user's credentials to authenticate your calls over SData 2.0.  

The good

Maintained accountability

One benefit with this technique is that the user's rights and permissions will be enforced in SData 2.0.  This will prevent the user from making unauthorized changes.  It also means that when records get updated, created or deleted by the user, the correct user ID will be present in the _UpdatedBy, _CreatedBy and _Deleted fields.  This is a great way to keep track of all changes that happen in the system and maintain accountability among users.

Easy to implement

This is probably the easiest method to implement as you do not need to create any additional users to use SData 2.0.  Each user can use their own credentials to use SData 2.0.  This also means that users can have a single set of credentials to log into a collection of applications that are related.

The bad

Exchanging credentials in the open

The one drawback to this technique is that the user's browser will be sending these credentials with each request to SData 2.0.  This means that a third-party could retrieve these credentials if they sniff the requests being sent.

As a prevention, I highly suggest that you use an HTTPS connection to connect to SData 2.0 so that the data sent back-and-forth between your application and the SData 2.0 server is encrypted.

I would also suggest that you consider creating a middle-ware that accepts the user's credentials the first time and then generates a token or a JSON web token and sends that back to the client to use in all future requests.  This would make it a lot more secure as subsequent requests won't contain the credentials.

Create a dedicated user

Another option is to create an additional user in Sage CRM that you can use exclusively for SData access.

The good

No need to cater for or manage user credentials

This is significantly easier as you do not have to manage user credentials for SData 2.0 requests for each user that logs into your application.  All requests will constantly use the same credentials.

Easy to assign permissions

If you need specific permissions for your application to work for SData 2.0 it is very easy to configure these permissions on a single user in Sage CRM instead of a whole group of users that will be accessing Sage CRM.

The bad

No accountability

The biggest drawback when using this technique is that you no longer have accountability for actions performed in Sage CRM.  All actions such as inserting, updating and deleting records will cause the _UpdatedBy, _CreatedBy and _Deleted fields to contain the User ID for the user you have created to access SData 2.0 instead of the user's actual User ID.

Session ID

Another way of authenticating with SData 2.0 is to use a SID if you already have one.  This is accessible in Sage CRM's front-end with the following Javascript function:

crm.CurrentUser.sid
// Outputs 'xxxxxxxxxxxxxxxx' (the current SID)

To use this we simply append the SID to the URL of the request so that our URL looks something like this:

http://{Server Name}/sdata/{Install Name}j/sagecrm2/-/Company?SID=99248868675910

Calling this will authenticate us without having to specify user credentials.

The good

Easy to implement in Sage CRM

This method makes it very easy and convenient to use SData 2.0 from within Sage CRM.  If you have a page that needs to update data in the database without refreshing, you can use SData 2.0 to make that update and then just grab the current user's SID to authenticate the request.  No need for the user to specify their credentials again.

No transferring user credentials

Another benefit with this technique is we don't need to transfer credentials themselves over a connection repeatedly, only the SID.  This means that if someone is able to retrieve our SID from requests sent to the server, their unauthorized access will only last as long as the user is logged in.

The bad

Only available where you can get an SID

This method is only available when you already have an existing SID.  There is no method in SData 2.0 to retrieve an SID so you need to have one already from when you've logged into Sage CRM.  Once you have an SID then you can use that to log into and use SData 2.0.

Closing

Deciding which authentication method to use is completely up to you and is determined by the environment in which your code will be running and who will be using the system in what manner.  Once these factors have been established, then you can determine the most effective way of authenticating with SData 2.0.

I really hope this series of articles really shed light on the power available in SData 2.0.  I highly encourage you to use SData 2.0 for your integrations as it provides you with an incredibly easy to use API that can perform all the necessary actions on your Sage CRM database.