Hi Lez, thanks for the comments. I will take a crack at implementing both approaches.
Few more comments are below.. On Mon, Jun 22, 2009 at 6:34 AM, Les Hazlewood <[email protected]>wrote: > Hi Manoj, > > > > Some of the proposed methods in the above threads are >> > >> > subject.assumeIdentity( Object principal ); >> > subject.runAs( Object principal ); >> > subject.switchUser( Object principal ); >> > >> > Doing a runAs and switching identity based on only the principal is in >> my >> > view a security hole. >> > Any developer could introduce a malignant line code with a call to runAs >> > using the prinicipal of another >> > user and hijack the other users privilege. >> > > >> The purpose of an application security framework is not necessarily to > protect the application from the developer. >> It exists primarily to > protect the application from the application's end-user; the developer > writes the application > >> security checks after all! If you can't trust the developer, then they > shouldn't be writing security-sensitive code in >>the first place. > > >>That is, Shiro has no control over whether a developer writes this: > > >>if ( currentSubject.isPermitted("account:transferMoney") ) { > transferMoney(); > >>} > > >>or this: > > >>transferMoney(); > > >>It is the developer's responsibility to use the security framework as > necessary for the application's requirements. > Many security breaches are caused by people that are supposed to be > trusted. So using an unauthenticated principal as a parameter does cause me > some concern. Using a principal seems fine only if the caller is an > "Administrator" or > a "superuser". But letting any using any user assume the identity of any other user opens an opportunity for foul play. >> deleted
