views:

34

answers:

1

I have a classic Java SOA application, with a web UI module, web services module, a service module (Java API), a domain module and a persistence module. In a sense, each of these modules has their own public API.

My understanding of Spring Security is that I can use web filters to handle the security of the web gui and web services, and method level security (via annotations) for the service module.

My question is this: should I bother to add method level security to the domain module and the persistence module or is that considered overkill?

+1  A: 

If you secure the external API's it's normally not needed to secure additional internal layers such as the domain model or DAO persistence layer.

But all depends on you're security requirements. Adding security roles to you're methods in the internal API's will make it more secure and can be considered a good defensive practice against security holes in you’re exposed API.

Kdeveloper
Sounds like its a good practice, but could be overkill. Given the computational overhead, I'm leaning towards not securing internal modules. My concern, of course, is that theoretically, one could write a Java client for those API's and run it from thier own machine. All one needs is the database credentials.
HDave
I agree, normally you don’t secure internal API’s. A database is such an internal API and it should not be exposed. So the database ports should never be publicly accessible and reside behind a firewall.
Kdeveloper