User in many roles

[michal stankiewicz]

Hi guys,
This is my first post on that forum, so I say hi :P

I want to make user authentification. In my authentification, user gives his password and login and if it is correct he is logged. It sounds simple. But what I want to do, is to restrict his access to some parts of service based on group he belong to. Sounds normal too.
But the problem is, I want to be there many groups, every groups has its name, description and roles it is assigned to. Roles and groups are many-to-many relationship, so basicly, user <-> role is many to many relationship. How to do that kind of authentification, that user will belong to many roles.

Lets say I will be using Java 1.8. Java EE 7, JavaServer Faces, Glassfish server with realm authentification and mysql database.

I have read, you can do it using multi realm authentification or using method isUserInRole, but no idea how to use it. Moreover, as I have read, JDBC realm will see only one role per one user.

Correct me if I am wrong, and move thread if it is not in correct section.

[Tim Holloway]

Hi right back, Michal! :) Welcome to the JavaRanch!

It is perfectly acceptable for a user to have more than one security role granted to him/her/whatever. This is very convenient in that, for example, a person in the "employee" role could be granted also the "manager" role while the boss is on vacation, then when the boss returns, the security administrator simply deletes the database record pairing that person's ID with the "manager" role id.

It is not true that the JDBC realm allows only one role per user. The effective implementation of the isUserInRole() method is as follows:

String SQL_CMD = "SELECT COUNT(*) FROM USER_ROLE WHERE USER_ID=? AND ROLE_ID=?";
String userId = httpServletRequest.getRemoteUser();
PreparedStatement stmt = realmConnection.prepareStatement(SQL_CMD);
stmt.setString(1, userId);
stmt.setString(2, roleName);
int n = stmt.query();
return (n > 0);

This is the effective code - the actual code is more complicated (plus I forget if a preparedStatement query truly returns the number of records or if in the real world you have to ask the statement itself.

Note that like all good security, the query doesn't actually fetch the role record because that exposes data. Instead it merely asks if it exists.

One VERY thing to remember when using container security in JSF. The security system maps against the incoming URL. Since JSF URLs often lag behind what you're actually accessing, secured requests should navigate using the "REDIRECT" option. That will force the URLs to track properly at the expense of a small overhead.

[michal stankiewicz]

So i can just have table
users ( username VARCHAR(32) PRIMARY KEY, passwd VARCHAR(32) NOT NULL, ...)
roles ( rolename VARCHAR(32) PRIMARY KEY, ...)
roles_users ( username VARCHAR(32) REFERENCES users(username), rolename VARCHAR(32) REFERENCES roles(rolename), ...)
and view
v_roles_users ( username VARCHAR(32), passwd VARCHAR(32), rolename VARCHAR(32))

give it to JDBC realm on glassfish server, and he will get it, i mean view,

than in program how do I get access? Will normall javax.annotation.security.RollesAllowed work? Will he see all roles? Or do I need servlet for each access, there check if user is in role, if yes redirect to page he want, if not redirect to page "access denied"? If I need to make servlet, how do I do redirection, so primefaces will work

One more question. Any tutorial on how to do unit test in java ee / or other tests

[Tim Holloway]

Actually, you only need the users (userid/password) and roles_users (userid/roleid) tables. The JDBC Realm doesn't use anything more.

There is no mechanism whereby the appplication can enumerate what roles a user has. That violates the "don't volunteer" axiom of good security I mentioned previously. All you can do is ask IF the user is in a role, either directly (request.isUserInRole()) or as part of a URL security mapping in web.xml.

You would not write servlets to invoke usUserInRole(), you'd do that from the property and action methods. Since getting to the actual is UserInRole() method in a JSF app is messy and requires platform-dependent code, I use a service class to abstract that part out (this also aids unit testing).

So, for example:

/**
 * Secured save action method for form
 * @returns next View
 */

public void doSave() {
  if ( ! JSFUtils.isUserInRole("editor") ) {
     JSFUtils.addErrorMessage("You are not authorized to save data.");
     return null; // redisplay the form with message on it.
  }
  // otherwise, save the data
  return NEXT_VIEW;
}

The Struts framework allowed role-checking on the View tags, but stock JSF does not (some extension may, however). So the alternative is to fake it:
<h:commandButton id="ctlSave" value="Save" action="#{myBean.doSave}" rendered="#{mybean.editingUser}"/>

/**
 * This read-only property indicates that the user has the editing role
 *  and thus can be used to show/hide  the "Save" button.
 * @return <b>true</b> if the user can edit.
 */
public boolean isEditingUser() {
   return JSFUtils.isUserInRole("editor");
}

In the real world, I usually define my roles as manifest constants and I may abstract things further, but this is the basic idea.

[Tim Holloway]

Incidentally, if you'll ask about testing as a separate topic, I'll discuss it there. Making it a new topic helps other people find it easier and keeps questions on one subject from getting muddled by answers on another subject.

Also, I'm not sure that the @RolesAllowed annotation works with JSF. It's primarily for stuff like EJBs where methods are secured on a per-method basis and that doesn't fit as easily to JSF backing bean methods.

[michal stankiewicz]

Ok so I will ask in other topic.
This is my glassfish-web.xml file. Is it correct? I have a problem now -> #{request.remoteUser} returns correct user, but #{request.isUserInRole('admin')} returns always false
I am using glassfish 4.1, JavaServer Faces 2.2, Primefaces 5, Java 8, Java EE 7
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE glassfish-web-app PUBLIC "-//GlassFish.org//DTD GlassFish Application Server 3.1 Servlet 3.0//EN" "http://glassfish.org/dtds/glassfish-web-app_3_0-1.dtd"> <glassfish-web-app error-url=""> <class-loader delegate="true"/> <jsp-config> <property name="keepgenerated" value="true"> </property> </jsp-config> <security-role-mapping> <role-name>admin</role-name> <group-name>admin</group-name> </security-role-mapping> <security-role-mapping> <role-name>see_notifications</role-name> <group-name>see_notifications</group-name> </security-role-mapping> <security-role-mapping> <role-name>security</role-name> <group-name>security</group-name> </security-role-mapping> <security-role-mapping> <role-name>b_propose</role-name> <group-name>b_propose</group-name> </security-role-mapping> <security-role-mapping> <role-name>b_accept</role-name> <group-name>b_accept</group-name> </security-role-mapping> <security-role-mapping> <role-name>c_propose</role-name> <group-name>c_propose</group-name> </security-role-mapping> <security-role-mapping> <role-name>c_accept</role-name> <group-name>c_accept</group-name> </security-role-mapping> </glassfish-web-app>

and this is my web.xml file

<?xml version="1.0" encoding="UTF-8"?> <web-app version="3.1" xmlns="http://xmlns.jcp.org/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"> <context-param> <param-name>javax.faces.PROJECT_STAGE</param-name> <param-value>Development</param-value> </context-param> <servlet> <servlet-name>Faces Servlet</servlet-name> <servlet-class>javax.faces.webapp.FacesServlet</servlet-class> <load-on-startup>1</load-on-startup> </servlet> <servlet-mapping> <servlet-name>Faces Servlet</servlet-name> <url-pattern>/awizacja/*</url-pattern> </servlet-mapping> <session-config> <session-timeout> 30 </session-timeout> </session-config> <welcome-file-list> <welcome-file>awizacja/login/login.xhtml</welcome-file> </welcome-file-list> <login-config> <auth-method>FORM</auth-method> <realm-name>awizacje-realm</realm-name> <form-login-config> <form-login-page>/awizacja/login/login.xhtml</form-login-page> <form-error-page>/awizacja/login/login.xhtml</form-error-page> </form-login-config> </login-config> <security-constraint> <display-name>admin</display-name> <web-resource-collection> <web-resource-name>admin</web-resource-name> <description></description> <url-pattern>/awizacja/users/*</url-pattern> <http-method>GET</http-method> <http-method>POST</http-method> <http-method>HEAD</http-method> <http-method>PUT</http-method> <http-method>OPTIONS</http-method> <http-method>TRACE</http-method> <http-method>DELETE</http-method> </web-resource-collection> <auth-constraint> <description/> <role-name>admin</role-name> </auth-constraint> <user-data-constraint> <transport-guarantee>NONE</transport-guarantee> </user-data-constraint> </security-constraint> </web-app>

and i have a login bean like that:

import java.io.Serializable;
import java.util.Collection;
import javax.ejb.EJB;
import javax.ejb.Stateless;
import javax.faces.application.FacesMessage;
import javax.faces.context.FacesContext;
import javax.inject.Named;
import javax.servlet.ServletException;

import javax.servlet.http.HttpServletRequest;
import model.Groups;
import model.GroupsRoles;
import model.Users;

//adnotacje
@Stateless
@Named
public class LoginBean implements Serializable {
    //informacje do zalogowania
    private String username;
    private String password;
    
    public String getUsername() { return username; }
    public String getPassword() { return password; }
    
    public void setUsername(String username) { this.username = username; }
    public void setPassword(String password) { this.password = password; }
    
    //uprawnienia, na podstawie informacji z bazy
    private Boolean admin = Boolean.FALSE;
    
    public Boolean isAdmin() { return admin; }
    
    public void setAdmin(Boolean admin) { this.admin = admin; }
    
    @EJB
    UsersFacade uf;
    @EJB
    GroupsFacade gf;
    @EJB
    GroupsRolesFacade grf;
    
    /**
     * Ustawia wszystkie role na fałsz
     */
    private void removeRoles() {
            admin = Boolean.FALSE;
    }
    
    /**
     * Ustawia role na takie, jakie należą się użytkownikowi
     * @param username - Na podstawie nazwy z bazy pobiera role i je ustawia
     */
    private void setRoles(String username) {
        Users u = (Users) 
                    uf.getEntityManager().
                    createNamedQuery("Users.findByUsername").
                    setParameter("username", this.username).
                    getSingleResult();
            
        Groups g = (Groups) 
                gf.getEntityManager().
                createNamedQuery("Groups.findById").
                setParameter("id", u.getGroupId().getId()).
                getSingleResult();
        
        Collection<GroupsRoles> cgr = 
                grf.getEntityManager().
                createNamedQuery("GroupsRoles.findByGroupId").
                setParameter("groupId", g.getId()).
                getResultList();
            
            //przejedź po wszystkich relacja grupa - rola by znaleźć odpowiednie
        for(GroupsRoles gr : cgr) {
                
                //przypisanie odpowienich ról
            String roleName = gr.getRoles().getName();
            if (roleName.equals("admin")) admin = Boolean.TRUE;
        }
    }
    
    /**
     * sprawdza czy ktoś jest zalogowany, a jak nie to sprząta
     * @return czy jakikolwiek użytkownik jest zalogowany
     */
    private Boolean isUserLogged() {
        FacesContext context = FacesContext.getCurrentInstance();
        HttpServletRequest request = (HttpServletRequest) 
                context.getExternalContext().getRequest();
        
        String user = request.getRemoteUser();
        
        //jeżeli ktoś jest zalogowany
        if (user != null)
            return Boolean.TRUE;
        
        username = null;
        password = null;
        
        removeRoles();
        
        return Boolean.FALSE;
    }
    
    public void login() {
        FacesContext context = FacesContext.getCurrentInstance();
        HttpServletRequest request = (HttpServletRequest) 
                context.getExternalContext().getRequest();
        
        try {
            request.login(username, password);
            
            //udało się zalogować, trzeba przypisać role
            setRoles(username);
        } catch (ServletException e) {
            context.addMessage(null, 
                    new FacesMessage("Logowanie nie powiodło się"));
        }
    }
    
    /*
     * Na razie wersja próbna
     */
    public void logout() {
        FacesContext context = FacesContext.getCurrentInstance();
        HttpServletRequest request = (HttpServletRequest) 
                context.getExternalContext().getRequest();
        try {
            request.logout();
            
            //wylogowywanie powiodlo sie, wiec pozwalam usuwam uprawnienia
            //nie chcemy by ktoś po wylogowaniu miał dostęp do tego
            //do czego nie powinien
            removeRoles();
            
            username = null;
            password = null;
            
        } catch (ServletException e) {
            context.addMessage(null,  
                    new FacesMessage("Wylogowywanie nie powiodło się"));
        }
    }
}

How can i make a bean like that disapper if I remove history with coockies? Od do I need to check it every time, if difference had been made?

[michal stankiewicz]

Do not see anymore edit button, I changed web.xml adding



<security-role> <role-name>admin</role-name> </security-role>

[Tim Holloway]

Try and keep your examples short. It's easier to read them that way, and when you get free help you have to expect that there's a limit to how hard people will work.

One thing that really puzzles me is your "setRoles" function. The JEE security framework does not assume that the Realm has a databse behind it. I've written Realm modules for web services, and my standard site security on my own server farm isn't database-based, it's LDAP-based. So right off, you're violating the write-once/run-anywhere aspect of JEE security.

Also, more practically, it's common for the authentication mechanism to cache information. Changes to a user's role set usually requires that the user must log out and log back in again before the new roles take effect. In fact, it may be mandatory, since changing a user's role set in the middle of a session is an opportunity for security exploits where an unfriendly agent might be able to catch the user with parts of both role sets in effect at the same time. Recall that JEE is multi-threaded.

This EL expression offends me:

 #{request.isUserInRole('admin')}

1. It tightens coupling by explictly requiring an HTTP interface to work (JSF was conceived as an abstract MVC framework. HTTP is just the standard transport).

1a. It also tightens coupling by requiring the View to explicitly know what the literal values of the role names are.

2. It puts what is effectively server-side code on the client-side View definition. Which doesn't always do what you think it will do.

3. EL should be kept as simple as possible if for no other reason than it is hard to get a debugger to work with it.

That's why my example had a property method to do role-checking.

[michal stankiewicz]

Tim Holloway wrote:
This EL expression offends me:

 #{request.isUserInRole('admin')}

.

Can I at least use #{request.isUserInRole('admin')} to render menu elements in template? Set roles has been removed from LoginBean, out of sense that was.

Do you know how to insert/update/delete recods in join table if I want to only use auto-generated persistance macanism I get from "create entity classes ..." and "create jsp pages ..." ?

[Tim Holloway]

I really don't recommend coding any more complexity in EL than is absolutely necessary. And, as I said, by using a "magic constant" value in your View Template, you've coupled your View and Model environments more tightly than necessary.

The biggest problem with having code spill into the View is that there's not longer any one indisputable place to find out where things are being done. You have to go on a "treasure hunt" to find out and you may have to juggle multiple objects to make sense of things.

JSF does not concern itself with persistency, so the mechanisms you employ would be the same ones that work for non-web applications.