Is there a way to make it so users must authenticate before they can submit a job or at least before launching deadline? Or is the password simply used for checking the render queue from the web/apps?
No, there isn’t at this time. The password is simply for the web service feature.
Cheers,
- Ryan
Are there any plans to implement this feature into future releases?
There aren’t any current plans, but we are always flexible. Perhaps you could explain why you need this feature, and we can then determine if there is space on our short term road map for it.
Thanks!
- Ryan
We’re setting up a render farm for the Herberger Institute here at Arizona State and there are 2 main concerns over access:
The first is that with a couple thousand students from our Institute having access to the system, there is a chance for shenanigans to take place. Students logging in as other students and deleting jobs, or putting them on hold so that their jobs move up in the queue, modifying settings, etc. I don’t really see this happening a lot, but it is a concern from some of the faculty members. Turning on Enhanced User Security solves those concerns for the most part, but doesn’t get us around issue number 2…
Our Institute encompasses the schools of Music, Art, Design and Theatre and Film (the latter 3 being the primary users of our render farm) and these students pay special fees for technology which were used in the setup of the servers and will pay for future additions. The directors of these schools have expressed concerns that students from other schools may find out about our set up and attempt to use it themselves, basically getting access to our services for free and potentially slowing things down for our students. The directors would like a way to ensure that only our enrolled students have accounts within Deadline so they can use our servers. I understand that would involve us managing the accounts of potentially thousands of users, but that is what the powers that be would prefer.
It sounds like you’ve got Active Directory running, since you’re able to implement some acceptable Enhanced User Security, which is based on the login identity of the client system. We put AD permissions on our Repository so that only members of permitted groups would be able to write. It may be time-consuming to set up initially, unless there are already AD groups with the appropriate affiliated members, but it would provide that level of control. With any luck, someone else is already having to manage the membership in those groups so the eligibility changes automatically.