> However, the creator of a job could add the subject as a property to the job
Can JobManager do that as it should have the creator information when the job is being created? Thanks, -Amit -----Original Message----- From: Lars Krapf [mailto:[email protected]] Sent: 14 May 2014 19:20 To: [email protected] Subject: Re: Events, Jobs and admin sessions 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 <[email protected]>: > >> 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 >> > > >
