There is more than one person named Stephen Ray. There are even more people who have Stephen and Ray as part of their name. It’s not the most common name; I’m sure there are a lot more John Smiths, Maria Silvas, etc.. Large call centers often have to contend with name clashes when designating login names for various services, especially when you consider a few years of normal employee turnover. The problem compounds when you are using multi-tenant call center software.
An individual tenant can be left to determine the best way to handle name collisions. Not allowing duplicate login names is an easy way to enforce this. If an administrator tries to create a new user with an existing login name, the system should report an error and force the admin to change the name they are attempting to use. This is pretty straightforward. However, with multiple tenants, this approach, unmodified, won’t work. If a tenant does not have someone with the username jsmith, but they are unable to create one due to it’s previous use, they now know a login name that’s valid for the system.
One approach that works to resolve this problem is to combine the username with another factor and present both as login credentials. The password initially seems an obvious choice as it is already required, but allowing another tenant to do username/password checks on other tenants would be a nightmare. The next obvious step is to have the agent identify the tenant they are logging into. Again, we want to avoid leaking information about tenants to other tenants. An approach that can do this without requiring the agent to provide additional information on the login screen is to use a unique hostname per tenant. This is the method Q-Suite uses.
Hostnames are a good choice for the identification factor as they are usually simple enough to configure for users that require a multi-tenant solution in the first place. For a cloud-based call center, external DNS (Domain Name System) is usually used to provide distinct hostnames to the agent web server. As an example, a multi-tenant site hosted at example.com might use indosoft.example.com for their Indosoft tenant, and megacorp.example.com for the Megacorp tenant. If multiple hosts are required per tenant, the Q-Suite does allow the specification of wildcards, so *.megacorp.example.com might be designated as belonging to the Megacorp tenant, with agents using web1.megacorp.example.com for the first web server, web2.megacorp.example.com for the second web server, and so on. For multi-tenant sites with internal infrastructure, local DNS may be sufficient. It is even possible that a client may update the hosts file on the agent machines in order to resolve the host to the correct IP address.
When using the hostname, the web server itself passes the hostname used as well as the page requested. The hostname used doesn’t matter to the web server itself as long as the request reaches it. Obviously that’s a bit of an oversimplification, but unless your call center software web server is also being used to serve websites for different hosts, the simplification matches the reality. It’s then a simple matter for the software to match a host to a tenant, then check to see if that tenant has a username/password combination that matches the one supplied. This approach allows multiple tenants to accidentally use the same usernames without exposing information unnecessarily or requiring extra effort on the part of the agent.