Where is the ‘Run Trigger Service As User’ property set?

I am getting access denied when a trigger calls the service, the pub./sub doucmentation says to set the Run Trigger Service As User property, but doesnt say where this proerty lives. Any ideas?

Heres an extract:

You can instruct the Integration Server to invoke a service using the credentials of one of the predefined user accounts (Administrator, Central, Default, Developer, Replicator). You can also specify a user account that you or another server administrator defined. When the Integration Server receives a document that satisfies a trigger condition, the Integration Server uses the credentials for the specified user account to invoke the service specified in the trigger condition. Make sure that the user account you select includes the credentials required by the execute ACLs assigned to the services associated with triggers. For more information about setting the Run Trigger Service As User property, see the
webMethods Integration Server Administrator’s Guide. [Of course, this property is not mentioned in the Admin guide]

wouldn’t this be same as “Execute ACL” on the service you actually invoke in the trigger setup?

No ‘Execute ACL’ is the ACL required to execute the service. What I am trying to find out is which user will actually try to execute the service.

I have found a global setting named ‘Run Trigger Service As User’, found at AdminConsole > Settings > Resources > Store Settings, which is set to Administrator by default. This seems to indicate that every trigger in the IS will always be run as the same user, and you cannot config a user per trigger. Does this sound right? It doesnt sound right to me.

I think that is the case. What is your objective? To run a particular triggered service under a more limited user id?

Perhaps the triggered service could execute WmPublic/pub.scheduler:addOneTimeTask, which could pass the document to the service. It also has a parameter of runAsUser.

So document A would trigger service B, which would call pub.scheduler:addOneTimeTask which would call service C (your original service), passing the document, the desired user ID and a date/time of current + 1 second, since addOneTimeTask requires a future date/time.

the objective is to allow only specified users access to a service. It so happens that the service is reached via the Broker so that Guaranteed Delivery is enforced.

If what youre saying is true, that all triggers are run as the same user throughout the entire IS, thats a big security hole. That means that any user that can publish a document type is then automatically able to publish ANY document type known to the Broker. This shouldnt be the case, every service has its own ACL, and this single user for all triggers breaks that entire security/ACL architecture!

Perhaps theres away to specify on the Document Type which ACL is allowed to publish it?

IvanG,
you’re right

The documentation clearly states that you specify the user account per IS instance…

Isnt publishing document type different than how the subscribe service runs? You can always use ACLs to limit which users publishes the document. I am assuming that the documents are published within IS instance.