Introducing TAS

We teased that a few new upgrades would be coming soon in the last post, and now I’d like to
take a bit of a deeper dive on the first one that’s ready to roll, the Tigersolv Authentication
Service, or TAS for short.

TAS is incredibly important for the changes coming through to the CRM products this year,
because it allows a user to log in once, and have that login be valid for all our software in both
desktop apps and web based apps alike. The CRM’s are going to become a blend of both as
module upgrades become available, so it would be incredibly annoying for a user to have to
keep logging into each section, but TAS lets users move through them all seamlessly. This is
also a nice thing for the Administrator of the system, as they have a single Admin console in
which they can control a user’s access across every single product in use.

TAS uses the latest OAuth standards to deliver the same security standards as bluechip tech
companies and make use of the widespread compatibility gained by using that standard, but like
everything we do at Tigersolv, we go further than that.

In addition to the tried and tested authentication of OAuth, we’ve added a layer that manages
Authorisation for specific permissions for each user, allowing for permission management. There
are some examples of this in other Auth servers but generally they have a limit on the number of
permissions they can manage. TAS can handle thousands of permissions, allowing for the kind
of granular control over singular buttons, fields, and features that makes our CRM systems so
controllable and compliance assuring.

We’ve also built in Tri-state permissions, which can save a lot of time when it comes to
managing user access, because you can create permission groups that map to particular teams
or roles with your business, and allow users to acquire these roles, and therefore the
permissions, but when you have people who cross business areas or have partial access into
other areas, you typically have to create an entirely new ‘role’ that then only gets applied to that
one special user. Instead of a two state permissions system where a user may “have” or
“doesn’t have” a permission, Tri-state allows you to instead add explicit “deny” permissions to a
user, that will override permissions they would get by joining a group. It means you can ensure
that certain people who have a regulatory requirement to be separated in function from another
are definitely separated even if they accidentally acquire system access through secondary
permission groups they’re added to, while also allowing you to create those special roles with
partial access to areas that aren’t in their main job, but controlling what they can’t do when you
don’t want them to have the full rights of a dedicated member of the team.

Finally, all of this is stand-alone and you’re able to use it for third party or self-build systems too!
Any software that is built to with OAuth could use TAS as it’s Auth Server, and any developer
will find it’s concepts and API familiar and intuitive, but they can also make use of the enhanced

TAS is a brilliant addition to your technology platform and a foundation stone for the many
upgrades and products coming in 2023. The support team will be in touch to schedule rollouts
over the next month or two, and if you’ve got your own internal programming teams who’d like to
know more or get a walkthrough of the API, just get in touch and we’ll put something in the diary.