Here is the setup…
An agent called “calendar” with the “Run on behalf of” field set to CN=Bart Employee/O=wfstestnotes has been created in a database called “Contact Test”. This agent creates a calendar entry in the mail database for Joe Supervisor. Bart Employee has editor rights to Joe Supervisors mail database.
The agent was signed with an Notes ID called “Notes Admin”, and this ID is listed in the “Sign agents to run on behalf of someone else” field in the server document. This Notes Admin id does not have any access rights to Joe Supervisor’s mail file.
When a web user who has not signed in calls the calendar agent from a browser via an http request like “http://testserver.testdomain.com/ContactTest.nsf/calendar?OpenAgent” this scenario works so beautifully it makes me want to cry. A calendar entry is created in Joe Supervisor’s mail database, it is created by Bart Employee, the agent sends confirmation back to the browser, and birds outside my window begin to sing.
Here is the problem…
Using this exact same scenario, if the web user is authenticated, for example Betty Director has just authenticated to view her mail via iNotes, and then she submits the same http request “http://testserver.testdomain.com/ContactTest.nsf/calendar?OpenAgent”, the server returns the Server Login prompt with “You are not authorized to perform this operation”. Obviously, this is not the functionality I am looking for. I get a call from Betty Director, she is upset, the birds stop singing and fly away.
I am hoping a brilliant mind in our Notes community can school me on the cause of this and suggest a way to have the birds singing outside my window again.
Subject: Run on behalf Agent, Not Authorized Problem
OnBehalf and ‘run as web user’ are mutually exlusive. If you have ‘run as web user’ set, the OnBehalf field cannot be used (we cannot assure the security if we allowed it).
There is chart in Agent FAQ on where OnBehalf can be used.
Subject: RE: Run on behalf Agent, Not Authorized Problem
Julie,
The “Run as web user” checkbox is not checked. Sorry, I should have mentioned that in the description.
Any suggestions on why an unauthenticated user can run it but an authenticated user gets bonked for not being authorized?
Subject: RE: Run on behalf Agent, Not Authorized Problem
Ah, okay. This happens in the http server before it gets to the agent code. This is controlled with the ACL settings on the database. You probably have it set to “no access”?
Subject: RE: Run on behalf Agent, Not Authorized Problem
I discovered the problem…
The ID listed in the “Run on behalf of” property of the agent needs to be listed in the ACL of the application where the agent where the agent is stored (or at least that is how it appears to me at the moment).
When the default access of the database where the agent was stored was “Editor” a web user, authenticated or not, could kick off the agent and have it create a calendar entry in the the target Joe Supervisor mail file.
When I changed the default access of the application from Editor to No Access, the agent would fail even for properly authenticated users. For example if Betty Director was listed in the ACL for the application where the Run on behalf of agent was stored as “Editor”, and Betty authenticated and then tried to kick off the agent, she was not authorized.
However, if an entry for Bart Employee was added to the ACL of the application where the Run on behalf of agent was stored as Editor, and an authenticated Betty Director kicked off the agent, it worked perfectly.
So, this may be elementary, but the person listed in the “Run on behalf of” field for the agent, must have access to the application where the agent is stored. Too many problems occur when I rush…
Thank you for all your help!