Edsby access management
One of the key underlying concepts in Edsby is that all user access to Edsby is authenticated. In other words, data in Edsby is only shown to specific users, and that data is only shown once the user has proven in some way that they are who they claim to be.
The underlying data for performing these operations is the “account”. An Edsby account is the data structure which Edsby uses to manage and save data on who the user of the account is, what data the account should have access to, whether the user is still active on the system, how authentication should be performed, etc.
The account is the key data structure in Edsby. Without an account, no access to Edsby is permitted.
Given the fact that Edsby operates in a very hierarchical environment, it is not surprising that different accounts in Edsby will be given vastly different powers. For example, the principal of a school requires much different powers in Edsby than a parent; a teacher requires different powers than a student; etc.
Edsby accomplishes this by assigning each account to a role. A role is a collection of permissions and privileges that will be given to each account. A summary of Edsby’s many roles and how they’re applied is available here.
Each account in Edsby also contains a set of links. A “link” is a specific relationship between an account and an object or another account in Edsby. These links also have link types which determine what the specific relationship is between the two entities.
Let’s see how this works in real life for our example users, and for this example we’ll assume that they are part of the fictional High Prairie School District (HPSD).
The District Link
First, all of these users are clearly linked to the district, so they have links to the District. This is done using the most basic link type, Member. This will already start giving the users data, because when they log in, they will see a link to the district page, they will see district news, and their calendar will display items from the district calendar.
The linking of each account to the district is done automatically by Edsby at the time the account is created.
Second, let’s suppose that our example users are associated with a school, for example the fictional Tecumseh High.
In this case, each of our users would also have a link to the school. Again, this link would be done as a member link, the most basic link type. When they log in, they will see a link to the school page, they will see school news, and their calendar will display items from the school calendar.
Because users may have any number of links, if a user is associated with multiple schools everything “just works”. For example, if Linda Miller also teachers at Maple Middle School, she would have a link to Maple Middle School, she would see two schools listed, and her news and calendar would include items from both schools.
Links and Roles
The link system and the roles system work together hand-in-hand to deliver the expected behavior. So, while William, Linda, Joey and Sara all have links to Tecumseh High, their role will determine what rights and privileges each of the users have within the school.
William, the Principal, has a Senior Administrator role. This gives him much more power than Joey (Student role) or Sara (Parent role).
Of course, in most schools, there is a very common type of link, and that is a link to a class. Not surprisingly, in Edsby there is a “Class” object, and all people in that class will have a link to the class. So, in our example case, both Joey and Linda will have a link to the “Grade 9 Math Section B” class.
As with the school, Edsby uses the role of the user to decide what rights and privileges the user has in the class. So, obviously, Joey (with the Student role) will have less power than Linda (with the Teacher role).
Edsby also includes the ability to override the roles-based permissions, by using an explicit link type. For example, consider the situation where Linda wishes to enroll in a class offered by the Professional Development team at HPSD. Linda has the Teacher role, but for the purpose of that class Linda would be a student.
There is another very important set of links in any school, and that is the set of links between students and parents. So, in the case of Joey, he will have a link to Sara, and that link will be of type “Mother”. Sara will have a corresponding link to Joey, and that will be of type “Son”.
If Sara had three children, she would have three parental links. If Joey had two parents and a step-father with access rights, he would have three parental links.
Edsby supports one other very important role: the Contact role. Accounts with only the role of Contact are the only accounts which are not allowed to log in. They are purely informational.
One important concept in Edsby is the idea of “indirect” links. These are like “friends of friends” on Facebook, and they are very important.
For example, suppose the Linda wants to send a message out about an important reminder. She wants to send it not just the students in her class, but also the parents of the children in her class. Edsby can do this using the links and roles.
It can get more complex. Suppose that Linda has broken her wrist and will be off of school for a week. Mr. Ham wants to send a message to all of the students in all of the classes that Linda is a teacher of. In fact, it might be even more involved: all of the parents of all of the students in all of the classes that Linda is a teacher of.
All of these are performed easily in Edsby because of its understanding of links and roles.
Passwords and Authentication
In order for any user to access the information in Edsby, that user must authenticate by successfully entering their UserID and password.
Edsby has two distinct methods of checking to see if the entered password is the correct one: it can employ either internal or external authentication. And in certain situations, Edsby is also able to do mixed authentication.
In the case of internal authentication, Edsby maintains a secure, internal database of passwords (actually a salted hash of the passwords). When a user enters their User ID and password, Edsby checks that against the internal database, and if they match the user is able to log in.
Edsby also provides a complete suite of password management tools, including the ability for the user to reset their password via email.
In many cases, the preferred authentication method is to use some identity management system already installed at the district, so that users will simply enter the user ID and password which they use to access other district resources. In this case, when a user enters their user ID and password, Edsby passes those credentials of to the external identity management platform for validation, and upon receipt of a positive confirmation the user is allowed to log in.
Note that when external authentication has been enabled, the password management tools are disabled, because Edsby has no way of changing or managing a user’s password in the external identity management platform. Instead, the user will be automatically redirected to the password management page on that platform.
For a more detailed discussion of the specific platforms and protocols available in Edsby for external authentication, click here.
Role-Based Mixed Authentication
In many cases, the authentication methods used by Edsby will vary based on the role of the user. For example, staff users may be authenticated against one Active Directory domain, and student users would be authenticated against another AD domain.
Another particularly common configuration is for certain roles to use external authentication, while other roles are set to internal authentication. This is particularly common for parental accounts, which are often not provisioned in any of the district identity management systems. Edsby has complete support for this arrangement, including the ability to provision the password management tools for parents only.