So I have database with an agent that signs other agents and script libraries. I do this by browsing the NotesNotesDocumentCollection for the appropriate NotesNotesDocument, then doing a doc.sign then saving it.
The agent that does this is signed by a generic ID. Call it signer/mydomain.
When it runs, it indeed sets the last modified by ID correctly and the code even looks for the $OnBehalfOf field and successfully changes that too if it exists in the document.
Now my servers are complaining because they think the agent was signed by the server and not by my generic ID.
07/11/2022 4:00:51 PM - Failure SomeOtherServer/Domain - Agent Manager: Error validating execution rights for agent 'OSMonitor' in database 'administration/OSMonitor.nsf'. Agent signer 'MySigningServerNotTheID/Domain', effective user 'MySigningServerNotTheID/Domain'. Examine 'Programmability Restrictions' field in the Server Record. (0x1AA1)
Now yes, I could poke the server name in the appropriate security field in the server's address book entry, but I'd like to know why this is happening. I've looked at the XML code of the updated agent and only see that server name in the following entry.
@Chris James To sign a note (design element, document), the private key of the entity is needed, which is stored only in its id file, thus its public key can be used to validate the signature.
As far as I know, the signer of the agent can't be used to sign a note, if it is not the current user (with an id file).
I used this trick in a customized maildatabase to send mail as the owner of the mail file. The signer is indeed the server, and the OnBehalfOf specifies which hat the agent should wear. The server signing the agent should be allowed to do this, by adding the server to "Sign agents to run on behalf of someone else". I suspect your server does not have that right, as the effective user is not listed as "signer/mydomain"
Also, it certainly is possible to do this in code, since Ytria SignEZ exists. It may just be very difficult...
But even the SignEZ needs access to the id file. Then it uses some C API calls to open it, to create some kind of security context with it and then sign the notes.
The way I got my functionality working is using a couple of server signed agents, signed by a server ID with enough rights.
One agent is for setting up the worker agent with the correct OnBehalfOf. The worker agent is then called to send the message. This call was made from a modified CoreEmailClasses library in the mail template.
So you are talking about an agent to sent mail with a sender of your choice instead of the signer of the agent?
In comparison, this is easy. Even sending encrypted Notes internal emails might work this way, since for encryption you only need the public key of the recipients, which can be found in the person documents in the Domino Directory.
But for electronic signatures you would need the private key of the signing entity, which is stored exclusively in the entity's id file.