NetSuite Easy Alternative to Single Sign-On Authentication

This article is relevant if you want to use NetSuite to provide authentication to your custom application but you want to avoid using single sign-on (SSO) technology

Background

For a current client engagement, we are building a NetSuite recurring billing engine to support our client’s custom subscription service (the “client” application). The client has recently embraced NetSuite for accounting, eCommerce and soon full CRM. They want to have a number of their specialized revenue generating applications work in an integrated fashion to enhance the user experience and streamline business operations. Currently, each application maintains its own username and password and account information.

My client’s system environment is the common pattern we see in proprietary-built business applications. Each application is responsible for maintaining account and credential information.  As companies grow, the opportunity to centralize information becomes more meaningful to lower the cost of customer support operations while increasing the ability to serve the customer with less effort.

One goal of our custom NetSuite recurring billing solution is to move the proprietary accounts to NetSuite customer accounts and leverage NetSuite’s credential capacities. NetSuite supports single sign-on (SSO) but it is generally cumbersome to setup. During a recent design session, one of our consultants and I invented an interesting innovation.

Leverage NetSuite Restlets to offer Authentication Service

Since the client is already providing their own login service for the application, our goal is to make no change to the subscription user experience while removing the credential from their local database and move it to NetSuite.  To achieve this goal, we provide two new custom NetSuite Restlets:

Customer Update Restlet API

First, we provided a convenient Restlet to read, create and update customers from the client application. The Restlet will add a customer to NetSuite, set the password, add the user to the NetSuite Customer Center, and activate the login by turning on the “Give Access” switch.

The client’s application is responsible for maintaining the customer information in this API. Information that was previously stored in the application, such as billing and credit card payment information,  including credential data, now can move to NetSuite where it belongs. Once the customer information is centralized in NetSuite, all other proprietary applications, including NetSuite’s eCommerce and Customer Server Center offerings, can leverage this data to produce a cohesive relationship between users and our client’s service offerings.

It is important to note that when you update NetSuite’s password with cleartext information, it is encrypted and can not be read. This is what we expect because NetSuite provides good security.  In a true Single Sign-On environment, the external application (from NetSuite’s perspective) will will never have a chance to learn the password.  Hence, this technique may not meet that security policy requirement.  Yet, our client is already managing user credentials and now plans to not store it in their databases; so this innovation is an enhancement to existing policies and a desired outcome.

Authentication Restlet API

The second authentication application is very simple. The key here is that we will leverage NetSuite’s built-in requirement for Restlets to require NetSuite user authentication.

When the user comes to the client application, they are presented with a username and password screen; common to almost all secured applications. In our client’s case, the username is an email address. That is perfect for how our API works. The user presents the email address and the password on a secured SSL page hosted by the client web application.

The client web application catches the information and then generates a REST call to our Authentication Restlet API. We craft the NetSuite Restlet HTTP Headers to include the credential information as prescribed when calling NetSuite’s standard Restlets. Here is an example:

Here, “nlauth_signature” is the user password. And “nlauth_role” is the built-in NetSuite Customer Center.

Our NetSuite Authentication Restlet is very simple. We simply return the string: “Authorized”. If the credential provided by the customer is valid, our simple code executes. However, if the credential is invalid, NetSuite (not our code) returns back an error code indicating an Invalid Credential.

Here is the Restlet Code:

//------------------------------------------------------------------
//Function:	Auth_Restlet
//Description:  Authorize a NetSuite user with built-in NetSuite authentication
//------------------------------------------------------------------
function Auth_Restlet(datain){
	return "Authenticated";
}

Here is the what the result looks like from the client web application.    If you get the string “Authenticated”, then it is good,  Or you may get an error message indicating bad credential information.

NetSuite Platform Innovations

One of the great things about the NetSuite system is our ability to innovate on the platform. The application allows us to solve problems that are typically off limits in traditional ERP / CRM systems of yesteryear. Contact us if you want to get more out of your NetSuite application.

Marty Zigman

Holding all three official certifications, Marty is regarded as the top NetSuite expert and leads a team of senior professionals at Prolecto Resources, Inc. He is a former Deloitte & Touche CPA and has held CTO roles. For over 30 years, Marty has produced leadership in ERP, CRM and eCommerce business systems. Contact Marty to set up a conversation.

More Posts - Website - Twitter - Facebook - LinkedIn - YouTube