A couple of weeks ago we had some internal discussions about wether or not we 
should annotate interfaces with security directives. What came out of our 
discussions was that security annotations (related to authorization) would be 
added only on methods of classes, not interfaces. That way we can have abstract 
classes that implements common logic with common access rules. The main 
motivations were:

1. interfaces defines the behaviour of an object and does not dictate any 
implementation details.

2. some implementation (ie. mocks) does not have security requirements at all 
and other may have different requirements in security.

3. from a single Java interface we generate many things: remote stubs for 
RMI-type communications, WSDL for SOAP web service, Hessian proxies for binary 
web services, java scripts to integrate web stuff with rpc/json... so in those 
orthogonal aspects (and in reference to point #2) the Shiro security aspect is 
never involved.

I'm aware that this approach is debatable, but this is the guideline that we 
decided to follow. Until now, we did not came across a use case were we needed 
to deviate from this.

Hope this helps.

Regards,
   J-C




On 21-Feb-2010, at 10:45, aloleary wrote:

> 
> Hello,
>   I am refactoring some code and have come across an interesting issue. On
> refactoring has pointed to a nice solution using a generic interface...
> 
> So lets say I had something really dumbed down like:
> 
> @RequiresRoles(A)
> public Client updateClient(Client)
> 
> @RequiresRoles(B)
> public Staff updateStaff(Staff)
> 
> but now I have
> 
> @ ??
> public T update(T)
> 
> The saving in my codebase is quite substantial - lots of duplicated code
> removed - smaller footprint, less coverage etc...
> 
> However ... I am wondering how it is now possible to add security to this
> new method or do I need to leave the interfaces explicit to get value from
> annotations etc..
> 
> I don't mind loosing annotaions for hardwiring code like isPermitted etc as
> its now just in one method...
> 
> I obviously cant change the @RequiresPermissions(..[something related to
> T]..) ;-) or currentUser.hasRole(..[something related to T]..)
> 
> Just wondering if anyone has come across this type of pattern and how it
> might be solved elegantly ?
> 
> Thanks
> -A-
> 
> -- 
> View this message in context: 
> http://n2.nabble.com/Security-on-Generic-interfaces-tp4607155p4607155.html
> Sent from the Shiro User mailing list archive at Nabble.com.

Reply via email to