Disclaimer: this article, and all opinions therein, are my own, and do not, in any way represent the opinions of my employer, or any entities I perform any work for or represent.
Recently, I have been involved in the implementation of a new product at my work, which has caused a lot of frustration, and ultimately led for me to write this article. What I will be talking about is not usually a problem with most software manufacturers, however, in my experience in the education realm for 13 years, I have come to the following conclusion:
Software manufacturers in the education space put 90% of their resources developing an education application, which, often times works well, and reserve the remaining 10% to build a backend infrastructure integration to that application. This typically puts IT administrators in a tough position trying to explain to non-technical users, why such a product is a bad fit for the organization
These days, most companies use some sort of directory. Microsoft Active Directory in particular is quite a widespread, so I will speak in relation to it, that does not, however preclude these notions to apply to other directory products as well.
If we look at any half decent commercial business, there are security measures and policies in place, as well as a specific way the infrastructure is built, to facilitate authentication, and reporting. Unfortunately, educational entities, particularly in the public sector of K-12, these types of implementations are not performed for one of 2 reasons: 1) the entity is too small to justify a complex implementation, 2) the leadership or IT team are either not knowledgeable enough, or do not care enough for such implementation until some disaster strikes.
Let’s look at an example of why, for instance, building an Active Directory infrastructure based on Role Based Access Control (RBAC) is beneficial, and is not thought of until after the fact. Imagine this:
Your boss walks in, and states that they would like to know all users who have access to a specific folder on your servers, or reversing that, they want to know what folders does the user have access to. Even more elaborate, they would want to know what applications the users has access to, or whether there are any resource they are explicitly denied to that user.
Any IT admin looking at these questions will likely cringe, and shake their head if they did not have a reporting system that allows for this. In order to allow this to happen, there is a recommended method by Microsoft, as a matter of fact, described in great detail in the Windows Administrator Resource Kit: Productivity Solutions for IT Professionals. This is not really a new notion, nor is anyone reinventing the wheel when speaking about a directory based on RBAC. The problem with it, is 1) It is fairly complicated to implement, at least in comparison to a flat directory. 2) It requires a strong understanding how RBAC works, to implement, and thus a skilled IT Admin. That said, the whole solution is based on security groups, and separating resources from roles.
To do this efficiently, it is best practice to create a set of groups, that involve a lot of nesting that incorporate both the resources, and the role groups to meet in the middle. As I mentioned, this is not anything new, and is very well supported, even encouraged by Microsoft. Here comes my first plea to software publishers:
Developing a product that has great content is a great step, and a very important one. Neglecting your backend to not support nested groups is a big mistake. The assumption is that most school districts may not even be using nested groups, so this may not even be a problem; however, this is indirectly punishing those who decide to implement a more robust system with best practices according to Microsoft. Quite honestly, this will result in 2 things: 1) The IT admins will not be happy with you as you would be forcing them to change their infrastructure to accommodate your software, and 2) it will put your company’s IT and development team in a bad light, and in the category of incompetence.
Similar to the above, authentication is another big piece to this puzzle. In general, most organizations have one domain, and that is usually sufficient. However, having multiple domains in a parent/child relationship is also a possibility, even a supported one. Yet, there are plenty of education software publishers who create shortcuts for authentications, and blame it on the client for not having an infrastructure that fits perfectly in their narrow minded design. Those publishers/vendors count on the fact that the non-technical management are the ultimate decision makers, and therefore makes the content of their product the primary selling point. This is misleading, and puts all IT admins in a bad position trying to explain to management why a product that can’t authenticate to a child domain, is a problem with the product, and not with the infrastructure design.
So, my plea to all education software publishers: when you design your wonderful educational software, and try to sell it on a big scale to integrate with an infrastructure, please do spend the time and resources to design as solid a backend as you do the content of the application. This would be a win-win for all parties.