Java Reference
In-Depth Information
Not leveraging Java EE security is a dangerous game.
Assuming your application requires security (almost all do);
you are betting that your developers can better build a
security infrastructure than the one you bought from the Java
EE vendor. This is not a good bet. Securing a distributed
application is extraordinarily difficult. For example, you need
to control access to EJBs using a network-safe encrypted
token. Most home-grown security infrastructures are not
secure -- with significant weaknesses that leave production
systems terribly vulnerable.
In particular, while products like Access Manager provide
excellent security features, they alone cannot secure an entire
Java EE application. They must work hand in hand with the
Java EE application server to secure all aspects of the system.
Another common reason given for not using Java EE security
is that the role-based model does not provide sufficiently
granular access control to meet complex business rules.
Though this is often true, this is no reason to avoid Java EE
security. Instead, leverage the Java EE authentication model
and Java EE roles in conjunction with your specific extended
rules. If a complex business rule is needed to make a security
decision, write the code to do it, basing the decision upon the
readily
available
and
trustable
Java
EE
authentication
information (the user's ID and roles).
Iterative and Incremental Development
Iterative development enables you to gradually master all the
moving pieces of Java EE. Build small, vertical slices through
your application rather than doing everything at once.
