Our SQL server is used for teaching, and we need to be able to automatically create databases for the students on demand and in real-time. We also need the students to be able to delete databases that they created. The students cannot be given administrator privilege, or any other level of access that would potentially allow them to break the server.
We had a hacky but working solution on our old server, based on an extended stored procedure: there was a "management database" whose job was to track and manipulate the student's databases, and an SQL Server Agent job that was constantly running. The extended stored procedure allowed the job to go to sleep, and to be woken up, at which point it created or deleted databases as indicated by entries in a table, and subject to various business rules, then went back to sleep again. (I can expand on this if necessary, but hopefully you get the idea.)
We have decommissioned the old server because it was running SQL Server 2008 R2, and will be building a new one for the upcoming trimester running SQL Server 2019. From the documentation I've found, extended stored procedures are deprecated but still supported, so in principle I could just reuse the existing solution. However, I would like to do something saner if possible.
What I think I need to ask is how I can best allow a non-privileged user to cause a stored procedure, which runs in a sufficiently privileged context to dynamically create and delete databases, to run, or failing that, to wake up from sleep.
However, I would be happy to receive suggestions of other possible solutions to my underlying problem of allowing a non-privileged user to create and delete databases on demand, subject to business rules. (For example, we require the databases to be prefixed with the student's username. We also need to configure the database security when it is created so that the student has access to it. And of course the student should only be able to delete their own databases, not other people's.)
If I remember correctly (and based on some quick research) triggers and the like won't work because they run in the context of the user that triggered them, e.g., see this post. But perhaps a signed stored procedure would work? I'm looking for the simplest, sanest options here, thinking forwards to whoever winds up looking after this server after me and looking for solutions that will be understandable and maintainable.
Solutions whose server-end can be implemented entirely in SQL are preferred, but this is not an absolute requirement.
Additional notes, in response to comments:
Students are authenticated via Windows logon, and access is granted based on membership in a Windows group.
On the old server, we did not give the students dbo access to their own databases, because we were not sure of the security implications. We did give them the db_ddladmin, db_datareader, and db_datawriter roles.