Jeremy Smith's blog

Entry Is Labelled

What's a "Level of Service?"

There's an IT concept called "Level of Service." A "Level of Service" is an abstract notion of how many and how much service a particular user receive's. For example, user 'joesmith' may have:

The abstract combination of those services define joesmith's "Level of Service." Another user may have an entirely different Level of Service. Another user may still yet have an entirely different Level of Service than the previous two... and so on and so forth.

Of course, assigning a user a service usually does not happen by hand. It is usually done automatically, and it is usually based on the "roles" a person has within an organization. At Case, we have roles such as staff@case.edu, student@case.edu, faculty@case.edu, alum@case.edu, affiliate@case.edu, etc. And, each system can key on those roles to decide whether or not to give that service to that user and, if so, at what level. That is called "authorization."

Authorization is different than authentication; though, many people confuse the two. Authentication is the process of asking someone who they are and challenging that someone to prove that they are who they claim to be. This is usually done by them by providing a username and password. If they give the correct credentials, the authentication phase was successful.

Authorization happens after authentication. After the person says who they are and proves they are who they claim to be, the system will then try and decide if the person has access. In the case of, say, an Apache .htaccess file, a line like 'require valid-user' means "let anyone with an account in." A line like 'require user jms18 emr dak' means that the only persons authorized for access are jms18, emr, or dak; all others will be turned away.

To ease some of the management of this, large organizations will usually institute role-based authorization schemes. If you are staff@case.edu, you get services x, y, and z; if you are faculty@case.edu, you get services p, q, and f; if you are student@case.edu, you get services a, b, and c; etc. If you have multiple roles (say staff@case.edu and student@case.edu), default each service to the "higher service level". So, if staff get 100MB email inboxes and 50MB network drives, and students get 50MB email inboxes and 100MB network drives — a person with both roles would end up getting the best of both worlds: 100MB inbox and 100MB network drive.

Extrapolate that out to a person with 10 different affiliations with the University... can get pretty complex.

Extrapolate that out to a federated authorization model (where a person from, say, UNC could log on to one or more of our network resources with their UNC credentials)... really complicated.

So, each system has their own way of deciding who has access to what and how much. The Software Center programmatically checks LDAP for a person's roles, decides whether or not to give access to that person, and then decides what pieces of software to give them. The email system stores most of it's authorization configurations in LDAP; as does the calendar service. VPN... PPP... Anti-Spam... Anti-Virus... etc. — all have their ways of deciding.

Each system does it's own access determination. (And, Middleware tries to keep it all as sane as possible and centralize as much of it as possible.)

Now, imagine that you want to send an email out to a user everytime that their "Level of Service" changes. How would one compute that?

One way to compute it would be to have a program that went into every single offered service and check what Level of Service a user has today and try and predict what Level of Service that user will have tomorrow (or the day after that, or a month down the road, or 6 months). That program would be a monstrosity. And, the maintenance of that program would be a nightmare. Anytime a new service is added, an existing service changed, or a service taken away; that program would need to be modified. What a Hell-ish, non-scalable way to do things.

Your next option is to introduce a layer of abstraction. You abstract out the services into general terms of "Email Quota," "POP Access," "Webmail," etc. You populate a database with these, we'll call them, meta-services, and you associate one or more of them with each user. Then, you can trawl the database and figure out what services are changing for a user.

The second option is dangerous, though. As a service is added, modified, or deleted; a manual process has to be done to go into that database and modify the records. If this is not done, the data will become inaccurate; and as the inaccuracy increases, the data will eventually become meaningless. And, remember, people are lazy. Database don't get updated. Databases become bad. Manual processes should be avoided at all costs. Whose going to remind that guy, 2 years down the road, who is modifying the Software Center code, to remember to go in and change the database record?

So, now what do you do?

Well, you know that most services base their "what-and-how-much" computation on a person's roles. So, what you could do is send a person an email telling them their roles are changing, and that that may affect their "Level of Service" with a pointer to the documentation on what roles get what services.

... But, that probably wouldn't work.

Comments

Post a comment