Schoolbox's security is not complex, but is secure.
- User arrives at Schoolbox and we check for a valid cookie. This is checked against the session key and expiry time. The user must provide a session key when they arrive if not we send them through the authentication process.
- If no valid session is found the user is sent to the login form to provide a username and password, in the case of SAML this is normally external to us.
- The user submits credentials and we then proceed to validate those credentials. Firstly we check the username and password against LDAP by searching for the users DN, then attempting to bind to that DN. If not successful we check the username and password against the schoolbox database. If these all fail the user is returned to the login screen with a Invalid Credentials error.
- If the credentials are successfully validated, we create a session cookie, assign it a unique key, store it in the server memory and tell the user the key. The user is then forwarded to the homepage.
With SAML disabled there really is only two ways to authenticate, either the user is found in LDAP or the user is found in Schoolbox.
Occasionally there can be issues with authenticating, these are usually related to;
- There could be a problem if the usernames are similar the system may not be able to determine the correct user. So for example You may have a student ssmith and a teacher ssmith. In AD they are in different contexts so it allows them to have the same username, but in Schoolbox you cannot have two people with the same username. It will then authenticate you with the first user of that name it finds. It may also find the other user in AD thus allowing the password authentication to succeed. All this is pretty rare though.
- We have heavy caching on the mobile system, to reduce data transfers. This includes information that is related to a session. So it is possible that if a user earlier logged in on a mobile device, it would have traces of that users session on the device, long after its use. Generally this is not an issue as a mobile is a personal device so caching sensitive session information is sort of expected. But other than that, mobile uses the same authentication routines as the rest of the system and the above points apply.
- Proxy issues - It is entirely possible that something outside of Schoolbox has played with the transactions. A proxy may just replies with content its cached for the student, even though it should be responding with fresh non-cached content for the staff member (i am going to investigate the headers we append to ensure we are telling the proxies the correct caching information ie do not cache, we might be lax on this due to the need to allow mobiles to cache as much as possible).
Alternatively a proxy or NAT firewall may get confused and return the wrong data. So for example, two users logging in at the same time, if the server responses with the session keys are swapped you could end up with another users session key.