Often the most important part of the news is what they didn't tell.
Tim Holloway wrote:I strongly recommend you forget about trying to invent a security system of your own for JSF. I've worked with J2EE since before JSPs were invented and seen probably dozens of webapps, many in critical sectors such as finance. And not ONE of the ones with user-designed security systems were even remotely secure. Most could be broken in under 5 minutes by unskilled people.
J2EE comes with a very strong security system that can block a lot of unauthorized activity before it can even reach (and therefore exploit) the application itself. Just about any basic J2EE book will give you a description of how web.xml is configured to employ it. And then proceed to use a user-defined "logon system" as a code example.![]()
When you use J2EE standard container-managed security, the login process is handled on an as-needed basis by the server itself. You can provide the login page images, but you can provide no login logic. You never actually get informed when a login occurs, in fact. You define security roles, and map URL patterns in web.xml to restrict what roles may access those patterns.
Sessions are where J2EE keeps security context. Since session objects never leave the server, they cannot be analyzed or tampered with by ill-meaning webapp clients. The session ID is just a hash key that has no specific meaning other than making it virtually impossible for an invader to break into someone else's session. You don't need to concern yourself with this mechanism, as the framework does it all transparently and automatically.
JSF integrates into the standard J2EE container security system almost seamlessly. The only JSF-specific quirk you need to address is that since JSF URLs don't always track the page resources like URLs do in most frameworks, and since container-managed security is based on the URL, not the resource, you have to use the "redirect" navigation property on rules that navigate to secured pages.
Often the most important part of the news is what they didn't tell.
Because container-managed security is designed to allow both app-specific logins and Single Signon users, the only definite way to route a user to a post-login "welcome" page is to monitor HttpServletRequests and detect the point where a given session's userid stops being bull. A ServletFilter can do that and reroute a request to the welcome page
Often the most important part of the news is what they didn't tell.
My favorite is a chocolate cupcake with white frosting and tiny ad sprinkles.
Smokeless wood heat with a rocket mass heater
https://woodheat.net
|