New “Partial” Automatic Approval Option for SSO Enabled Sites

Sona is a research platform as well as a service, but not for any single scientific discipline. Rather, scientists from many different disciplines and fields use Sona to conduct studies on topics ranging from haptic perception and AI to business ethics and linguistic typology. This isn’t bragging (well, not intentionally), but rather an explanation for the variety of ways individual Sona sites can be—and are—configured. Some Sona sites are intended only for students enrolled in a particular course, others for any students in a certain college or university, and still others are used to manage community participant pools. A lot of the settings and possible configurations are, at least in part, designed to make it easier for administrators to…well, administrate. And although we often write here for a diverse audience (not just in terms of the aforementioned diversity of scientific fields), many posts are aimed at supporting those whose job it is to support individual Sona site. In other words, Sona administrators.

This is such a post. We’ve introduced a new option with the goal of making administrators’ work easier. This new feature adds yet another possible way administrators can handle creating participant accounts: Automatic Account Approval for SSO Users Only (all others require administrative approval).

What is this new setting and how does it help administrators? Explaining this is best done in two parts. We first want to cover key aspects of account creation options in general (something useful even for those without an SSO enabled Sona site), and then introduce the new feature in that context.

Even limited just to creating accounts, and in fact just to participant accounts, Sona administrators have a lot of options, some of them mutually exclusive and some potentially complementary. One useful method that most certainly falls into the complementary category is the import wizard. When participants are all coming sections of one or two courses with Sona credit requirements, using the import wizard often ends up saving a great many headaches. Uploading course rosters to the appropriate sections ensures that all students in these sections have a Sona account, that they’re in the course section they are supposed to be, and its easy enough to have course rosters formatted to upload using the import wizard (for tips and more, see Ensuring a Smooth User Import).

Often, though, participants don’t come from one or two courses. Some Sona sites are open to any students, and some are open to the community at large. Indeed, in certain situations the same Sona site may, at least temporarily, serve both student and community (non-student) participants. In most of these contexts, creating accounts solely by uploading rosters using the import wizard becomes impractical or impossible. That where the Participant Account Self-Creation setting comes in.

Participant Account Self-Creation, one of the more widely used settings for handling participant accounts, is a bit of a misnomer. Whether or not participants can request accounts themselves vs. actually create accounts themselves depends upon another setting: Automatic Account Approval. If this latter setting is turned on, then participants can create accounts. If it isn’t, then enabling Participant Account Self-Creation actually allows participants to request accounts that administrators must approve.

Once Participant Account Self-Creation is enabled, the next question is whether such self-created accounts should require approval before login, or should be approved automatically. Switching Automatic Account Approval to “Yes” has both disadvantages and advantages. On the plus side, turning Automatic Account Approval on saves administrators from having to approve every account request. Most regard this as a good thing (and, to be fair, so do we!). There are potential benefits to participants and researchers as well. Without the need for account approval, participants can create accounts and view eligible studies both more easily and more quickly, which can make it more likely that researchers will find their studies timeslots filling up sooner rather than later.

On the downside, Automatic Account Approval does open the door for potential issues that range from user error to fraud. Many mistakes can be caught by the system, such as attempts to create duplicate accounts under the assumption that the first failed, using nicknames that do not match course rosters, or even create accounts under email or names that contain typos without realizing it. Fraud, or deliberate attempts to create separate accounts or create accounts under another’s identity are rare but more serious. However, the Sona platform includes different protections here as well as tools administrators can use: Preventing Fraud with IP address Logs.

Often, particularly with Sona sites that require participants to have university email addresses, these risks are small enough, and the benefits for administrators large enough, to make Automatic Account Approval a popular choice. Given the rarity of fraud, most administrators have to balance the amount of time it takes to fix user errors against the time it takes to approve accounts (which we’ve made easier: Streamlining Uncredited Sign-Ups: The New “Mark all” Options). Still, there’s no denying that Automatic Account Approval involves a certain degree of compromise between ease and administrative control over the account creation process.

Compromises between ease and security are quite common (as are compromises in general, of course). Nonetheless, some Sona administrators have likely wished for a third option. They like not having to approve accounts, but wish there were some way to authenticate accounts that wouldn’t require any additional labor. They wish, as the expression goes, to “have their cake and eat it too”. Most of us faced with compromise wish for the same!

Alas, though the expression makes a lot more sense as “eat your cake and have it too”, said either way it still holds in this case. After all, either accounts require approval, or they don’t. There are no third options, no middle way given, non tertium datur, and so forth—well, sort of.

Universities increasingly offer students (as well as staff, faculty, etc.) a single account that they can use to access everything from email to online enrollment to online course support to scholarly databases (e.g., JSTOR, ScienceDirect, Sage, SpringerLink, EBSCO, etc.). Single Sign-On (SSO) not only handles access to these various services, sites, and software, but also does so securely. Of course, SSO is not exactly new. In fact, Sona has supported SSO integration for some time now.

SSO integration does not, in and of itself, provide Sona administrators with a third way when it comes to participant account creation. It does provide options, though. The first and more relevant one is whether or not SSO is optional. If your Sona site is configured so that SSO is required for all users, then certain concerns over enabling Automatic Account Approval may disappear! Because the authentication process is guaranteed by the university/college network, even when creating/requesting an account participants must first go authenticate via SSO, and then go to the Request Account page. The difference is that now their name and other information will already appear in textboxes that can’t be edited or changed. Participant authentication comes from the university network, eliminating any problems with duplicate accounts, lost passwords, and other problems that may arise when Automatic Account Approval is enabled.

Despite the benefits for SSO users outlined above, we must keep in mind that we have not said much about SSO enabled sites for which SSO is not required. For these sites, non-SSO users can have accounts requested/created in the normal fashion. Of course, one might well wonder why have this option at all, if it seems to introduce possible issues that would otherwise not exist.

There are multiple answers, but we’ll focus on the simplest. For some sites, not all participants are students and therefore not all participants are SSO users. This, however, is precisely where the new partial Automatic Account Approval comes into play. It’s the reason we’ve introduced a new log in option:

As you can see from the image above, “Automatic Account Approval” is no longer simply a Yes/No setting. If your site has SSO enabled but not required for all users (i.e., optional), then you can make the approval process automatic for all users with SSO accounts.

For SSO users, all the benefits are still there. The created accounts are filled out after SSO authentication through the university, which makes is easy for participants to create their accounts and ensures all the security SSO authentication provides. So if most participants can be expected to be SSO users, then the university network ensures authentication and alleviates potential security problems (from simple typos to fraudulent attempts to create duplicate accounts).

For participant pools with non-students, or non-SSO users more generally, this new option provides a middle ground or third way. SSO users need not wait on administrator approval, and administrators need not take the time to approve their accounts. Non-SSO users, however, can be treated more carefully by requiring account approval. This may not be necessary, but it allows administrators greater control over the account creation and authentication process even while most accounts are created automatically and securely.

If your site is or may soon be SSO enabled, this is an option definitely worth checking out. It’s even worth considering if you have Automatic Account Approval on, provided that your system is SSO enabled. Whether you end up choosing to use it or not, of course, is something (as always) we are more than happy to leave with you.

But cake is nice, and we had an opportunity here that would allow you to, in some sense at least, both have your cake and eat it too. So we took it.