Tim Holloway wrote:Actually, SSL-encrypted and "secured' are two different things. To be secure you almost certainly need a secure transport channel, but you also need security constraints to protect sensitive resources. For that you need 2 things: Authentication and Authorization.
In the J2EE container security standard, authentication is done by the webapp server, not by the web application. The server detects secured URL requests (matches a security pattern in web.xml), checks to see if the request submitter has been authenticated, and if not, diverts the URL request and initiates login using a loginform or dialog. Only after the user has successfully logged in will the original request be allowed to continue.
Note that since the container manages the login process, there is no login code in the web application. Instead, authentication is handled by plug-in modules called Realms. The Realms also check role requests to see if a user is allowed to act in the requested role.
Since Tomcat Realms are plug-replaceable without the need for application modification, you can easily switch from SSO authentication to one of the other Realms such as JDBC or JNDI (Active Directory).
While I do recommend the standard container authorization for most webapps, ReST apps can be a bit of a problem, since they're not really intended to work with a human operator, so the usual login screen is not a good fit. In such cases, there are other options, but I'll leave explaining them to someone else.
tangara goh wrote:I'd like to clarify the part about using container managed log in via REALM, cos there are so many types as I read from Tomcat server official page. Can I know if I choose the most BASIC one will the protection be sufficient ?
Cos the password in the database would be exposed anyway .... what are the security measures one can do to prevent this kind of exposure ?