[Facelet & JSF Security] What do you think of this?

[Abdullah Dokuyucu]

Hello everybody...

Below is my 'EXAMPLE.xhtml' page template. What do you think of my design? Does it make sense to use JSF conditional statements to implement security? So far it's working fine for me...

<?xml version='1.0' encoding='UTF-8' ?>
<!DOCTYPE composition PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<ui:composition xmlns:ui="http://java.sun.com/jsf/facelets"
                xmlns:h="http://java.sun.com/jsf/html"
                xmlns:c="http://java.sun.com/jsp/jstl/core"
                xmlns:f="http://java.sun.com/jsf/core"
                template="#{Settings.template}">

    <ui:define name="title">Example Title</ui:define><!-- Change the title -->
    <ui:define name="content">
        <c:choose>
            <c:when test="#{LoginManager.loginStatus}">
                <c:if test="#{LoginManager.admin}">
                    <!-- Page starts -->
                    <h:outputLabel value="Example of a Restricted Access Page" /><br />
                    <!-- Page ends -->
                </c:if>
                <c:if test="#{!LoginManager.admin}"><ui:include src="/error/104.xhtml" /></c:if><!-- Include correct error page -->
            </c:when>
            <c:otherwise><ui:include src="/error/101.xhtml" /></c:otherwise>
        </c:choose>
    </ui:define>
</ui:composition>   

[Tim Holloway]

I think what makes sense is to use the J2EE standard container-managed security facilities, which among other things don't require that you code explocit login checks on all your secured resources.

But that just my silly little predjudice based on the fact that of all the many J2EE apps I've see over the years - and that's quite a number - I can't recall a single one that had a Do It Yourself security system that could spend more than about 15 minutes under a halfway competent assault.

[Abdullah Dokuyucu]

Thanks Tim; I tried to implement it but wasn't very successful. I found this to be more straightforward but I will at some point try it again, perhaps after finish coding the application.

I was partially discouraged due to my (mis)understanding that I should place restricted resources under a folder and define it as so. Also wasn't so sure if I did the configuration properly on the server (Glassfish v3). Too much documentation lying around but hard to find good tutorials

[leo donahue]

Ekrem Dkyc wrote:Thanks Tim; I tried to implement it but wasn't very successful. I found this to be more straightforward but I will at some point try it again, perhaps after finish coding the application.
Too much documentation lying around but hard to find good tutorials

Ekrem,

I don't understand your comment. You are going to finish an application that requires security, but you are going to implement the security part last? Call me old-fashioned, but that is crazy. By any chance are you employed by my bank? (note to self: store money in can in backyard).

The "documentation laying around" is the tutorial. Did you read Chapter 30 of the Java EE 5 Tutorial? As terrible as it sounds, you have to read the docs in order to understand what to ask. And, there is much to read. I hate to break bad news, but there will always be much to read in this profession.

What part were you trying to implement in which you did not succeed?

[Tim Holloway]

No, Leo, it's NOT insane to put security in last. Like optimization, security should be allowed for when an app is designed, but premature application of either is likely to have unfortunate consequences. The essence of container-managed security is that a great deal of the security is applied via external specifications wrapped around the app, not by coding security into the app. Container-managed security operates in large part by putting a wall in front of the app, so that many of the worst attacks never reach the application at all - they're foiled by the application server itself.

No few of the DIY security systems I'm so fond of maligning DID code in security first. Then, as the security needs changed, massive changes needed to be made to the apps, sometimes even to the business logic. So not only were they insecure (among other things, maintenance programmers rarely knew how to apply security, since it was one-off and not standard), they were expensive to maintain.

Incidentally, I have worked for a bank, and the methods I'm proposing were considered more than adequate for the apps I developed for the bank. And better than some, since we did have some DIY security kicking around. But that's not all. If you have a home mortgage in the USA, the chances are roughly one in three that part of the loan processing software that manages it was either my responsibility or a descendent of that system.

I will agree, however that documentation on container-managed security is plentiful, as are examples. I do have to do my standard "URLs are not filesystem paths" disclaimer, however, and point out that the web.xml patterns are URL patterns, not file patterns, and that a folder structure is only one of many ways to map security. JSF can be tricky, since URL-based security can require a bit of a boost in JSF, since the URLs aren't bound as directly to Views in JSF as they are in most web frameworks. But I've handled that and many other security challenges using the J2EE standard security system as a basis. I have fallbacks for specialized stuff like ultra-fine grained security needs, but I still like to use the standard stuff for the coarse-grained stuff, and I've yet to come across a case where that was a bad decision.

[leo donahue]

When you design a web application that will require security, you don't first define your user users, roles, realms (active directory vs database), authentication methods, navigation of the web app in general, etc? How would you know what you need to implement without first knowing where you are going?

I think you agree with me?

Like optimization, security should be allowed for when an app is designed

I realize most of the items I just listed can be "added" by configuring the container, without any *code* at all, but you still have configuration/security of the container to think about. I'm just saying that security should not be an afterthought once your webapp is finished.

[Abdullah Dokuyucu]

I do have my users and roles defined, just that it's implemented in a Do-It-Yourself fashion. I will certainly move on to container security at some point. Probably means I did some needless coding for my crappy security but its all done already.

But you are right on the reading part. Tonnes of cool stuff to learn! What I meant by that was some quick and dirty examples to get me started on whatever new concept I'm trying to grasp. I'm such a newbie.

As an afterthought, I should have spent some time learning container managed security rather than implementing mine

[Tim Holloway]

leo donahue wrote:When you design a web application that will require security, you don't first define your user users, roles, realms (active directory vs database), authentication methods, navigation of the web app in general, etc? How would you know what you need to implement without first knowing where you are going?

I think you agree with me?

Like optimization, security should be allowed for when an app is designed

I realize most of the items I just listed can be "added" by configuring the container, without any *code* at all, but you still have configuration/security of the container to think about. I'm just saying that security should not be an afterthought once your webapp is finished.

Well, yes, I do attempt to define business roles (with an eye to mapping security roles) and business function navigation. Authentication method is pretty much always form-based, simply because it's about the only way that's secure enough. Realms are NOT a consideration. The Container-managed security architecture places a very high wall around that to the point that program logic not only doesn't know what Realm is being used, it can't even reliably find out what Realm is in use. I've been known to test using the tomcat-users.xml file (MemoryRealm) when the production server used LDAP or Web Services authentication and authorization via a custom Realm.

So, in short, I allow for security in the architectural design phase, but the security exists to support the business, not the other way around. And actually putting security code into the app is one of the last things I do. After I've tested the business functionality.

[leo donahue]

I rarely answer anyone's questions in this forum for over 7 years. It is mostly because for some reason I can not convey correctly what I'm trying to say and/or I just don't understand what people are asking.

Ekrem, I never used the word "crappy". That was your word. What I'm trying to suggest is that implementing security is not a "quick and dirty" process. There is alot of information to digest. If you have a specific quesiton about implmenting something you have read in the Servlet Spec, or in the Java EE Tutorial, please ask.

Tim, Realms are NOT a consideration? They are if you have to implement/configure them. In Tomcat, when you configure a DataSourceRealm, you have sensitive info sitting in plain text in the context.xml file. What I'm saying is that implementing security for a webapp does not stop at the page, or container. Programmatically, no, I don't care about the Realm either, but the Realm is the way in which the application makes a connection to other secured resources, so thinking about that structure is something I consider.

the security exists to support the business, not the other way around

Did I infer that that it was the othe way around? If I said that, I'm sorry. I dont' think I said that.

[Abdullah Dokuyucu]

leo donahue wrote:I rarely answer anyone's questions in this forum for over 7 years. It is mostly because for some reason I can not convey correctly what I'm trying to say and/or I just don't understand what people are asking.

Ekrem, I never used the word "crappy". That was your word. What I'm trying to suggest is that implementing security is not a "quick and dirty" process. There is alot of information to digest. If you have a specific quesiton about implmenting something you have read in the Servlet Spec, or in the Java EE Tutorial, please ask.

Don't worry about that, I know any DIY security is so. And that's exactly why I choose this route, tehre is so much information to digest at once. Just did it like this for now, later I'll make the effort to make a real security. And thank you for the tip

[Tim Holloway]

leo donahue wrote:
Did I infer that that it was the othe way around? If I said that, I'm sorry. I dont' think I said that.

No you didn't. Some people do, however, which is why I emphasized it for our studio audience. Don't take it personally.

Realm configuration is for the server administrator, which is frequently full-time job for someone in the IT Operations department, not a programmer. Which is why I don't consider it as part of the applications design process. Or wouldn't except that as technical liaison between the grunt programmers and the operations staff, I have to look at both sides. And, no, I don't use the MemoryRealm for production. But it's the easiest way to set up accounts in a test environment sometimes. And test environments are supposed to be totally insulated from the hostile outside world anyway. Or you've got worse problems than applications security to worry about!

As you can see, I haven't been silent over the last 7 years, and I'm expert in both being confusing and being confused, I just keep plugging away, though. Eventually something resembling enlightenment usually emerges.

Returning to our original sponsor:

Ekrem Dkyc wrote:
And that's exactly why I choose this route, tehre is so much information to digest at once. Just did it like this for now, later I'll make the effort to make a real security.

Actually, since the standard security system is primarily done by wrapping the app using config information, you'll end up doing more work in cooking up a lot of DIY stuff that would complicate the app's business functions and just have to be ripped out anyway. Container-managed security isn't really that hard.

1. Figure out who's using the app and how (the actors and their business roles).

2. Determine what parts of the app must be secured and which business roles need access to what. Create a list of security roles to control that access. Note that business roles and security roles are not always identical, even though a lot of people don't realize there's a difference. For example, a security role may be something like "can view online reports" and be an attribute for the business roles of both managers and auditors. Don't forget that there may be roles needed for the operations staff as well.

3. Develop the app, minus security. It helps to set it up so that URL patterns can be used to segregate security roles, since that allows you to define that mapping in web.xml. The "folder" approach often works well, as for example, I place all my admin stuff in a folder named "admin".

4. Once the basic app is functional, you can start applying security. Set up the URL mappings in web.xml. If you have views whose natures change based on roles, add the appropriate control info there. JSF doesn't have a "natural" interface to the HTTP info, so I usually create a security bean and implement equivalent methods on it for things like the "getUser", "isCallerInRole" and "isLoggedIn" methods (the last one simply checks for a non-null userID). For testing, I may mock that bean.

5. Finally, also specific to JSF, I add <redirect/> elements to faces-config items that target sensitive functions so that they'll be submitted under the secured URL instead of via the originator's possibly insecure URL. That's because container managed security's first line of defense is the incoming URL, not the server function that invoked it.

[Abdullah Dokuyucu]

Sorry for late response, I was away for a few days.

And thank you so much Tim, for the great tips and being so helpful.