How many times do you reset a password each week? Anyone reading this post knows what a hassle it is to manage passwords for dozens of accounts. Teachers and students share the same pain, with dire consequences. If you’ve been a teacher, you know what it’s like to have those three students with their hands in the air, unable to log in, just as you’re finally ready to get kids started on the computers.
A recent survey by MDR found that 25% of digital learning time is wasted on setup, troubleshooting, and logging in. One teacher writes, “Every time I add a new technological object to my classroom, I increase the chances that my class does not happen that day.”
Why is this so hard?
Students and teachers deserve better, so why hasn’t the login problem been solved? Login management for learning software is particularly challenging in schools, as compared to enterprise or personal life. Because laptops and tablets are usually shared between students, they can’t store passwords in a web browser or password manager. Younger students don’t necessarily have email addresses, so password resets by email don’t work. One approach that has worked historically – having all students share one account – is outdated because learning software is increasingly personalized, requiring individual logins for students.
How are people approaching this?
So what does work? Syncing passwords is a common approach. Basically, a school creates a master list of student usernames and passwords. Every time the school uses a new learning tool, they set up the account with those credentials. But stop for a moment and think about all the problems that will ensue. Passwords can diverge because different systems can have different requirements for username and password formats. When new accounts are created, password distribution is a hassle: for example, a teacher cuts up a spreadsheet into 30 tiny strips and gives the right strip to each student (who immediately lose them). If passwords can be independently reset in different systems, then no one is sure which passwords are the latest; teachers can easily be left out of the loop.
In the past, many learning applications were hosted inside the district network, making it easier to use a central login server (i.e. LDAP or Active Directory). As applications have moved to the cloud, this method stops working, unless districts punch holes in their firewall. Because of the security risk, few are willing to do this.
Surely there’s a better way
More promising are single sign-on (SSO) solutions. These let students log in once to a primary system, and then gain one-click access to additional apps. Several vendors, and learning management systems, offer single sign-on portals. An example is Google Apps. Google Apps for Education is widespread, and students are able to use their Google accounts to sign into other apps.
Active Directory is also widely used in districts, and its companion product, Active Directory Federation Services (ADFS), theoretically supports single sign-on to cloud applications. But few applications support ADFS logins, and setting up the SAML-based technology requires a highly technical IT staff. Despite some challenges, single sign-on portals are gradually becoming more popular.
80% of teachers would adopt more digital learning software if it took less time to log in. Clearly, it’s time for better login management in learning software. At Clever, we have some exciting updates to share in this area. Stay tuned!