SpecificUsersAuthorizationStrategy allows a user to save a configuration mentioning another user, but (unless the current user is an administrator) this can only work if the security realm is a AbstractPasswordBasedSecurityRealm. It will not work for SSO or container-based security.

I would suggest allowing an API token to be used instead of a password. This would work with any security realm. Using an API token also reduces the impact of a password field compromise during form submission. (Normally a password is only sent to /j_acegi_security_check which people would be very conscious of and which involves no Jenkins code; job submission forms are more likely to be captured in various exception messages, loggers, and so on.)

It may also make sense to have a separate strategy, or mode of SpecificUsersAuthorizationStrategy, which would always run as the last person to configure the job. This would be appropriate when a job is configured by several people on the same team, all with similar permissions. You can get this effect with the current UI but only if each configuring user remembers to enter their own username each time, which is awkward.