How to use j_security_check jsf

[chen young]

Hi,

want to use j_security_check authentication in order to validate the user credentials.

Basically what I am trying to achieve is when the user press submit then in case he is using wrong credentials then a message (p:growl) will show and if it’s successful then the dialog will closed.

There are many examples in the web but unfortunately I still can’t understand how to complete this puzzle :(

In my project I am using primefaces 4.0 & weblogic 10.3.2.0 (JAVA EE 5).

some code example:

<p:dialog id="dialog" widgetVar="dlg" resizable="false"> 
    <h:form id="fLogin" prependId="false"
            onsubmit="document.getElementById('fLogin').action = 'j_security_check';">        
        <h:panelGrid columns="2" cellpadding="5">  
            <h:outputLabel for="j_username" value="Username:" />  
            <p:inputText value="#{expBean.username}"   
                         id="j_username" label="username"/>  
            <h:outputLabel for="j_password" value="Password:" />  
            <h:inputSecret value="#{expBean.password}"   
                           id="j_password" label="password"/>  
            <p:commandButton id="submitButton" 
                             value="Submit"
                             actionListener="#{expBean.run}" /> 
        </h:panelGrid> 
    </h:form>
</p:dialog>

web.xml

<servlet-mapping>
    <servlet-name>Faces Servlet</servlet-name>
    <url-pattern>/faces/*</url-pattern>
    <url-pattern>*.jsf</url-pattern>
</servlet-mapping>
<security-constraint>
    <web-resource-collection>
        <web-resource-name>main</web-resource-name>
        <description/>
        <url-pattern>main.jsf</url-pattern>
        <http-method>POST</http-method>
    </web-resource-collection>
</security-constraint>
<login-config>
    <auth-method>BASIC</auth-method>
    <realm-name>my-realm</realm-name>
</login-config>
<security-role>
    <description/>
    <role-name>MyRole</role-name>
</security-role>

exeBean:

public void run() {
      FacesContext facesContext = FacesContext.getCurrentInstance();

   }

Any guidelines and useful example will be much appreciated

Thanks

[Tim Holloway]

It doesn't work that way.

You cannot code a J2EE standard container login as a JSF page. The container login is controlled by the container (that is, the webserver itself) and not by application code. Nor, in most cases will a JSF login page even display properly, since the container may not route the page through the FacesServlet.

If you enter a URL to something like "https://www.myserver.com/mywebapp/j_security_check", it won't function properly. You cannot explicity navigate to the login/loginfail pages. Something may display, but it won't function.

J2EE container-managed authentication is done whenever an incoming URL matches a security URL pattern defined in web.xml and the user isn't already authenticated. In such as case:

1. The original URL request is temporarily put aside.

2. The container looks in web.xml to find the login page and displays it.

3. On receipt of the login form, the container takes the incoming j_username and j_password values and invokes the server's internal authentication method. This method will either return "failure", which causes the server to present the loginfail page or "success", in which case the server will have constructed a UserPrincipal object and attached it to the user's HttpSession.

4. On successful login, the original URL request is taken out of its temporary holding place and restarted just as if the login had never happened (except that now there is a UserPrincipal in the session).

This particular arrangement has certain advantages.

* No user-written code to have bugs in the login process.
* Invalid requests are rejected by the server and thus, can never gain access to the webapp to exploit it.
* Bookmarked URLs can be secured while still enjoying direct access to the bookmarked page instead of being hijacked to a post-login page.

Note that since the security mechanism is sensitive to the incoming URL, JSF has a problem, since the URL and the actual View can be out of sync. To remedy this, use the "redirect" JSF navigation option. It adds some overhead, but it ensures that the View and its URL are in sync so that the proper security rules will be followed.

[chen young]

Hi,

Thank you for the deeply explanation :)

Its look like my approach of using j_security_check for my specific scenario is wrong

Can you please advise how should I check user permission(maybe JAAS authentication) in order to decide who can execute the method (run())?

[Tim Holloway]

Based on what you have said, I can only assume that you are very new to web security in Java. And based on that, I can pretty confidently predict that if you attempt to create your own login/security system, it will be very insecure, since most "expert" Java web developers do, based on my years of experience. Most user-designed security systems have major holes in them such that unskilled non-technical users can bypass security in under 15 minutes, based on what I've seen.

The J2EE standard container web security system has several advantages.

1. It was designed by people who were full-time security professionals, not someone who was told to "write this app - and while you're at it, make it secure".

2. It conforms to best practices in security, such as never volunteering information that could help an invader break in.

3. It is a standard system, so anyone competent with J2EE can sit down and work with it and even find books about it. One-off systems almost never have that advantage.

4. The container-based security system is the ONLY system that can use the security definitions that you code in web.xml or via the J2EE security methods such as "isCallerInRole". No user-defined security system can tie into them. At least not without doing serious violence to the server/application architecture.

5. This is a system that has been used for many kinds of apps in many places for well over 10 years. If it has ever been broken, I haven't heard about it. It has withstood the test of time virtually unchanged.

One of the things that sounded odd in your original question had to do with some sort of login "dialog". Web applications have several choices on how to prompt for login security credentials. BASIC login causes a dialog to pop up on the client's screen, but the client application (browser) is solely in charge of presenting that dialog and in making it go away, as well as sending the credentials to the server. FORM-based login presents an actual web page (form), uses the j_security_check pseudo-action and does not pop up any dialogs. FORM-based login is considered more secure than BASIC login. Also BASIC logout can be difficult, often requiring the user to terminate the browser to log out, whereas FORM-based logins are terminated by simply invalidating the HttpSession object.

In any event, web applications are not processed in the same way that non-web applications are. There is no protection for methods as such, only for URLs, since the client can never directly call the server methods, only transmit HTTP requests that cause control to be routed to application code. While you can use JAAS as a plug-on for container authentication, the actual authentication process is still exactly the same as it is when you're using databases, LDAP/Active Directory, XML "tomcat-users.xml" or any other possibly more exotic authentication reference (including Single Signon services).

I think, in short, that what you really need to do is look at some good books on J2EE and Java Web Security. Also, be warned that a LOT of basic J2EE books cover how to work with the container security system and then promptly invalidate what they have taught by using "login screen" examples using user-designed security. I wish they wouldn't do that.

[chen young]

Indeed my experience with security is very limited

I will go back to the books

Thank you