Commercial targets available for a software editor are private users and organizations. This term, organization, stand for all kinds of companies, nonprofit organizations, and the EDU market.
Targeting organizations for a software editor is a good idea most of the time. But this requires a specific bill of functionalities too often ignored by editors.
Our goal here is to explain our standard bill of functionalities for all kinds of software deployment for an organization. This article is made to be read by software editors. It can also be useful for IT teams to challenge their own requirements for software, or eventually serve as a model for standardized requirements.
In this article, we will talk about the requirements from the IT point of view. It should come side by side with the end-user requirements regarding what need to be done with the software, and also with some specific functionalities related to law compliance.
Matching this IT bill of functionalities does not make software good for business. However, not matching it, even partially, classify the product as bad software, with hidden cost and security issues.
Backups
Every single software, from the first product offer, must provide daily backup and restoration tools. Some software editors are now used to request users to rent the right to use backups tools. This kind of behavior must be prohibited.
If the service is deployed on customer systems, backup tools must work without any GUI or user logged (as well as the service itself).
If we’re talking about a cloud service, an automatic downloading service must be available (it can be an e-mail automatically sent or an API as described on the next point).
Tasks automation
As soon as a software hope to target organizations, it targets a potentially large group of users that will be managed by a small IT team. This implies availability of automation tools to make IT tasks easier.
This could be a REST API for web services or even UNIX/ PowerShell command line tools.
Regarding command line tools, it’s good to note that not everyone uses Windows for everything, and this one has a non-negligible license fee. If you’ve to support only one system, GNU/Linux is the cheapest one for the customer.
Directory Service Integration
Regardless of the organization size, directory service is the central point of all information systems. It contains all information about users and their roles. All software made for an organization must support directory service information as feeding sources to reduce configuration time during human resources management tasks.
This can be achieved by two different scenarios: LDAP or SAML.
Directory 1.0 : LDAP
Until now, all directory service are available via the LDAP protocol. It allows user authentication and access to all directory information.
A developer writing an LDAP implementation must keep in mind that LDAP is an open standard rely on object classes (like oriented object development). De facto, a software using LDAP as a source of information must always support a list of settings explaining how to interpret provided information.
Active Directory, Open Directory eDirectory, custom LDAP, each of them has their own vision of a user and a group. Supporting only Active Directory point of view makes you incompatible with SMB relying on Apple technologies or EDU market used to custom LDAP.
Even when using Active Directory, it’s important to understand that each organization has its own identity management chart. Some setup still uses the sAMAccountName limited to 20 chars even if they are deprecated since Windows 2000, some other force authentication via UserPrincipalName and do not disclose the old one. Supporting only one makes you unable to work with the other half of the market.
Regardless how great LDAP is, it has one major drawback: its behavior require users’ credentials to be sent to the software to be forwarded then to the LDAP. This put the software in a position where clear text credentials are available. This is a major security issue for an organization.
Directory 2.0 : SAML & SCIM
Definitively modern, SAML and SCIM are two systems allowing to replace LDAP to avoid all kinds of security issues.
When an authentication request is made on a service supporting SAML, the user is redirected to a login page provided by the organization’s directory service allowing a user’s authentication matching the organization security policies (credentials, geoloc, two factors, etc.). Once done, the system will send the user back to the requested service with the authentication result and the directory information useful for the service (first name, last name, e-mail, etc.). In this way, users credentials are never seen by the third part software.
However, SAML has one issue, it does not allow preloading of users’ info and never update the service. Records are synced only at login time.
To avoid this issue, a new standard is available, SCIM. Its goal is to standardize and automate the processes to create, update and delete a user profile, from the directory to the third part services.
Even if most services can work with just in time account creation, and until SCIM become widely supported, providing a custom sync tool or sample code to use with API can be useful. This will allow the organization to preload your third part service if needed.
Which method to choose?
Two methods are available, which one should we support? Question is expected.
It’s a fact, today LDAP is well known and SAML is not. Even if all directory relying on Active Directory offer free support for SAML via ADFS. Even if few Open Source portal offer SAML support for custom LDAP.
LDAP has security issues, and it’s complex. It’s not really common to see a correct LDAP support by a third part editor. Allowing credentials to be accessible by a third part is too risky nowadays. And it’s really uncommon to find organization allowing LDAP to be accessible from the Internet.
Regardless of the service provider, small or big, it will be hacked one day or another. It seems legit to avoid credentials to be taken as well a corporate info in such a scenario.
SAML is the simplest option for software editors: it allows to delegate authentication to the organization and with that, some of the security issues. It can also enable the service to take advantage of advanced authentication rules for free: tools like Duo Security, VMware Identity Manager, or even Open OTP can increase the global security level for the authentication service without any changes from the service provider point of view.
SAML is the option to pick for all new development.
Hosting
Service hosting is one of the points where we can find tow church: cloud or on premise.
On Premise
Historic choice for most organizations, it makes IT work more complex by increasing number of tasks needed for infra management. However, it offers some major security features:
- managed data location;
- full auditing capabilities;
- intrusion detection under control;
- Financial and structural independence of the organization regarding the service provider.
The last point can be unexpected, but it’s a major one : a non-negligible amount of startup will fail or will be bought in the first years of existence. Going on premise is a guaranty for organizations to avoid hard cut of the service offer if the service provider change its mind.
Cloud
Trendy solution allowing software editors to enforce recurring incomes by changing their work to be a service provider. If correctly built, this option can be an advantage for some organizations.
Nowadays, an organization can use all kinds of services needed for its work, without buying any infrastructure hardware. Directory service with double factor authentication, CRM/ERP, e-mail, contacts, calendar, document-sharing, fleet management (iPhone, iPad, Mac, etc.), phone over IP, backups… All those services mandatory and self-sustainable for most organizations can simply be rent from the software editor who hosts themselves the service. De facto, those services became automatically available from any Internet access.
However, this idyllic vision of the world can quickly become a nightmare when matched against some local laws.
To offer a service for a specific market linked to a geographic area, a software editor must create a local branch and must offer guarantees that data hosting will be only done in this specific area.
When a software editor makes business both in EU and USA, it must have dedicated company branches in each area in charge sales and technic aspects. Hosting must be done in trusted local providers and not global actors. As an example, even providing hosting services in Europe, anyone using Amazone Web Services will be denied on the first security audit.
Operating System
Server
For on premise deployment, it’s good to keep in mind that not allow organization use Windows servers. A service working only on such a server will be inaccessible for lot customers.
Offering UNIX hosting enforce a decent level of security and stability for the service and reduce in the same time the deployment cost. Hidden costs of software aren’t small when it requires licenses like Windows Server or Microsoft SQL Server.
Endpoints
Endpoints used by end users can be of any kind nowadays. iPad, Mac, Windows, Android… All systems are used and supporting only a subpart of it limits you to a really small part of the market.
More over, almost all organization nowadays must manage mobility scenarios. It’s required for all software to work from anywhere on a mobile device.
Providing your app via a web browser using common domain standards allow to any editor to provide its service to the whole market without any additional expense. And later, it will be able to use real usage statistics to identify which platform is widely used to provide native support.
Deployment management
A fleet of endpoints take time be managed. For all software deployed on the endpoints, it’s mandatory to have a automatic setup solution. It can be via autodiscover services, or more over via MDM or GPO profiles.
Regardless of the solution, IT teams must be able to preload software settings to reduce setup and management time for endpoints. This can include server’s URL, user ID or even software restrictions (for example, avoiding access to accounts other than the managed one when an app is multi user).
There is organizations of fewer than 25 users
Impossible to know who picked this number, but there is a real discrimination nowadays against small companies, limiting them to use solutions that will make them efficient.
It’s especially true for online solutions and infrastructure products.
This limit cannot be understood for on premise deployment. For a cloud-based, it will be fairer to offer a decent degressive price rate allowing small businesses to grow with your services.
