Service users, and an awkward question for per-seat pricing
A version of this post appears on the Web Frolic blog.
I'm a bit on the fence about one of the features I built. It could turn into a bad outcome for some downstream applications that charge by the number of seats instead of by usage.
TL;DR: there has to be a good reason to reinvent the wheel. When your goal is to build a better version of something, you start by evaluating the trade-offs and limitations of the existing systems.
The shared-account problem
One constant pain point, amplified even more now that agents are in the picture, is the need for shared accounts or service accounts. You need them for API integrations between systems, break-glass scenarios and more. Unfortunately, most places don't have a clean way to do it, so resourceful people reuse and share the credentials for these accounts.
Service users
So I built the concept of service users:
- They don't have any credentials.
- They can be assigned to regular users.
- Regular users can impersonate them when needed.
Nothing wrong so far.
Where it gets interesting
This isn't out yet, but one of the core features of my identity provider is that customers and employees are managed in the same place. Bridging customer identity (CIAM) and enterprise identity was one of my motivations.
When you have employees, you also have SSO applications for them, and many of those applications charge by seat or number of users. Now imagine an SSO application assigned to a service user, with employees impersonating that service user whenever they need the application.
One service user, many employees, one seat.
Of course this doesn't apply to applications where the individual user's context matters, such as HR systems. But for a certain class of applications, it could save a company a lot of money under per-seat pricing.
One caveat: many SaaS license agreements don't allow several people to share a single seat. Before using service users this way, check each vendor's terms. Some offer shared or service-account licenses for exactly this case.
PS: seat limits
There's one more feature: you can configure a fixed number of seats for a given SSO application. When assignments reach that limit, the system deprovisions the most inactive user to make room for a new one.