Hello Carsten Thanks for your reply.
No, I don't see an obvious solution either. It's just that while reviewing the loginAdmin() usages, I discovered that a lot of the cases are based on this problem, and I was hoping for a solution that is as generic as possible. For the jobs, I could imagine an extension of the JobManager API that allows passing the subject. The resource resolver factory could then take the event/job as a parameter and return a resolver with the privileges of the corresponding subject. For the events, the situation seems to be even more complicated because usualy the event is not created manually, and I'm not sure if it is possible to assign a specific subject to an event in many cases. The alternative is to use a service-user in the consumer who has access to the respective payload, which somehow looks wrong to me from a security perspective. Well.. Ideas very welcome :) Best greetings Lars On 13.05.2014 22:57, Carsten Ziegeler wrote: > Hi Lars, > > I see your point, I don't see right now how a general approach could look > like. However, the creator of a job could add the subject as a property to > the job and the consumer can use this value to create a resource resolver > based on that value. But I think this has to be done on a job by job base. > > Or do you see a general mechanism which always gets the subject of the > sender? > > Carsten > > > 2014-05-13 17:21 GMT+02:00 Lars Krapf <lkr...@adobe.com>: > >> Hello list >> >> When processing events and jobs, the corresponding subject triggering >> the event usually gets lost. This lead to event handlers / job consumers >> often operating with administrative sessions/resolvers to do their work, >> which in turn can lead to privilege escalations. >> >> A possible solution to this problem could be to add a serialization of >> the event-triggering subject (if available) as a property to the event >> by default, so the handlers could easily recreate the session by using >> JAAS doAsPrivileged(). >> >> Would that make sense? >> >> Best greetings >> Lars >> > > >
