Funding your Single-Sign On Infrastructure

I had been involved with a few Web Single-Sign-On projects for the past few years, and I noticed that for most of these projects, funding had been a major concern, either for maintenance, upgrades, or enhancements. In this post, I will look into the existing charging model, as well as propose alternatives.

Infrastructure Cost

This is the most typical approach taken to fund the Single-Sign-On system maintenance. It is treated as an infrastructure cost, like network, email, directory services. A budget is requested and approved at the start of the financial year, and it must include all the necessary cost to keep the system running, including upgrades and enhancements.

Since the amount of money is fix, there is little room for improvement. Relegated to infrastructure utility, the system owner could not take a pro-active stance to enhance the system, for example to add in adaptive risk authentication, multiple-factor authentication, or token-based authentication.

User Base Charging to Business Units

This is actually a very popular approach taken by the product vendors, to charge by number of users. This could actually be taken up by the enterprise itself to charge each business units base on the number of user accounts in the system. An on-going revenue to the system could turn the system from a cost centre to a profit centre, giving them more flexibility into enhancing the system to better serve the customers.

This requires first a culture where business units charge each other internally. It also requires the Single-Sign-On system team to adopt a service provider mentality (which many might already be doing), adhering to strict Service Level Agreement (which again many might already be doing). An important mechanism is of course the ability to organise the accounts into the various business units, such that they can be billed accordingly, and accurately.

User Access Charging to Business Units

While user base charging is simple enough to do, this might not be an accurate representation of the actual usage. Business Unit A might have 100 user, and they generate only 10,000 authentication and authorisation access daily. Another Business Unit B might have 20 users, but they generate 20,000 authentication and authorisation, simply due to the difference in their daily usage pattern. It would make more sense to charge Business Unit B more than Business Unit A, due to the higher number of access.

In order to achieve this, the system must first be able to aggregate all access. This could take a significant amount of effort and storage space. But this would allow the Single-Sign-On system team to perform better capacity planning, as well as scale the system more accurately. They would know that another increase of 10 users in Business Unit B would require higher capacity as compared to the 10 users in Business Unit A.

User Access Charging to Applications

User access pattern are dictated much more by how an application is designed, than how a user might want to use it. A badly designed application might incur much more user authorisation request on the Single-Sign-On system than a well designed application with lesser steps. It might make more sense to charge the application owners themselves rather than the users.

This charging model does come with a drawback. If you charge the application owners, who will they transfer the cost to? It would then logically seems that they should charge the end users themselves. As such, for this to be implemented, the culture must be such that the applications themselves become service providers and charge the business units. In fact, with this model, it can be much clearer on which applications are really using up the system. The capacity planning is much more accurate in this scenario as compared to the earlier, as application usage is much more predictable than user usage.

What about authorisation access in this case? The Single-Sign-On system could continue to charge the business users by user base or authentication access, but their cost would be insignificant compared to the authorisation access. It might be simpler for the cost to be absorbed instead.

Summary

We looked at the current charging model that most enterprise adopt, which is Infrastructure Cost, and went on to propose other possible models. The other models convert the Single-Sign-On system from a cost centre to a profit centre, and transform the enterprise culture such that the team is treated as a service provider. Being a profit centre, the team can pursue more ways to improve and enhance the system, which could further improve the business capability of the enterprise.