• Post Reply Bookmark Topic Watch Topic
  • New Topic

Why do you need EJB security if you can secure at the presentation / web tier?

 
Luke Murphy
Ranch Hand
Posts: 300
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
HI,
Most EJB centric applications would still have a Web / Presentation Tier which all requests will go through.
If you can secure your web / presentation tier using something like Servlet security, why would you need to secure any of your EJBs?
Does this make security in EJB layer redundant?

Thanks
 
Ram Narayan.M
Ranch Hand
Posts: 247
Chrome Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Restrictions can be applied on Bean methods so that the clients of EJB will have privileges to call methods to which they have access...
 
Jimmy Clark
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Security mechanisms used on Business tier serve a different role than those on Presentation tier. The same goes for security on the relational databases and the RDBMS itself (aka Integration tier.)
 
Luke Murphy
Ranch Hand
Posts: 300
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jimmy Clark wrote:Security mechanisms used on Business tier serve a different role than those on Presentation tier. The same goes for security on the relational databases and the RDBMS itself (aka Integration tier.)

Of course.

You could make things a little bit more fine grained the more options and security layers you have.

But is that really it?

 
Jimmy Clark
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Software security is a very large area and there are many, many different ways to implement security at various levels. Ideally, a security architecture and design is based upon requirements - the security requirements. These are non-technical requirements that should be identified and documented early on during the initial stages of architecture design.

There are indeed EJB implementations that do not have associated GUI components, so there should be security mechanisms available for EJB. Also, security at the EJB-level protects the components from unauthorized access from unauthorized client objects possibly from unauthorized web apps or other software components that may get access to the application server's JNDI namespace.

Again, everything in the security design should be derived from the requirements. Without the requirements you really don't have a foundation for making any intelligent security-based decisions. This type of "seat-of-the-pants" software engineering typically fails when applied at the enterprise level.
 
Luke Murphy
Ranch Hand
Posts: 300
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Also, security at the EJB-level protects the components from unauthorized access from unauthorized client objects possibly from unauthorized web apps or other software components that may get access to the application server's JNDI namespace.

Great point.


Again, everything in the security design should be derived from the requirements. Without the requirements you really don't have a foundation for making any intelligent security-based decisions. This type of "seat-of-the-pants" software engineering typically fails when applied at the enterprise level.

I see where you are coming from but I think sometimes things that should be in requirements are not.
In a case where security isn't mentioned, I think it's best to architect some sort of basic security and put this in the architecture.
It's fairly easy to put in a simple servlet security and simple EJB security and it's better to have it there.

Logging isn't always in requirements but it's also good to have basic logging there too.

Thanks for your comments. Thought provoking.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!