Version 45

    Security FAQs

     

    Q1: Why cannot I access an ejb that has unchecked method permissions?

     

    A1: The unchecked method permission only removes the requirement that the call have sufficient permissions in terms of roles. The caller still has to be an authenticated caller. If you don't care about caller authentication, use the unauthenticatedIdentity option of the security domain login module to grant anonymous callers a fixed identity.

     

    Q2: Why does access fail with a principal=null error.

     

    A2: There is no caller context. Either the caller needs to have an established security context due to an existing security constraint or the context needs to be established via a JAAS login.  This needs to be explained more, because it seems to contradict the answer to Q7.  How do you establish a context via a JAAS login?

     

    Q3: Why isn't my authentication info propagating to the called component

     

    A3: Unless the login module configuration includes the org.jboss.security.ClientLoginModule module, there is no propogation of the caller security context.

    Here is an example of an application-policy XML fragment in login-config.xml for a ficticious security domain, using a custom LoginModule and including the ClientLoginModule for propogation:

    <application-policy name="mydomain">
       <authentication>
          <login-module code="com.domain.MyLoginModule" flag="required">
             <module-option name="additionalRole">Authenticated</module-option>
          </login-module>
    
          <!-- Add this line to your login-config.xml to include the ClientLoginModule propogation -->      
          <login-module code="org.jboss.security.ClientLoginModule" flag="required" ></login-module>
    
       </authentication>
    </application-policy> 

    This example is for a scenario where a calling client is using the LoginContext directly and requires feedback from the LoginContext.login() method if authentication using the users username and password was successful.  The ClientLoginModule then allows for the propagation of the credentials onto the EJB container for further calls.

     

    When using this approach it is important to wrap any calls in a try / finally block so that as soon as the call completest logout can be called on the LoginContext to clear the credentials set by the ClientLoginModule.

     

    It is important to remember that this example is for a client that requires feedback that LoginContext.login() is a success, the ClientLoginModule must never be added to the security domain that is being used for the authentication within the container.

     

    Q4: How do I debug the security layer?

     

    A4: Enable debug/trace level logging on the following categories:

    • org.jboss.security

    • org.jboss.web.tomcat.security

    • org.apache.catalina

    JBoss up to 5.1:

    The conf/log4j.xml fragment to enable this would be:

    <category name="org.jboss.security">
       <priority value="TRACE" class="org.jboss.logging.XLevel"></priority>
    </category>
    <category name="org.jboss.web.tomcat.security">
       <priority value="TRACE" class="org.jboss.logging.XLevel"></priority>
    </category>
    <category name="org.apache.catalina">
       <priority value="DEBUG"></priority>
    </category>
    

    JBoss 6:

    The config is located at: deploy/jboss-logging.xml

    To enable TRACE logging of the security layer:

    a) switch e.g. the CONSOLE appender to TRACE (default is "INFO", which would not produce much output from the security layer):

      <console-handler name="CONSOLE" autoflush="true" target="System.out">
          ...
          <level name="TRACE"/>
          ...
       </console-handler>

    b) activate TRACE logging for the category "org.jboss.security". If you need to trace security problems in the web layer, you might also have to add the categories "org.jboss.web.tomcat.security" and "org.apache.catalina":

       <logger category="org.jboss.security">
         <level name="TRACE" />
       </logger>
       <logger category="org.jboss.web.tomcat.security">
         <level name="TRACE" />
       </logger>
       <logger category="org.apache.catalina">
         <level name="TRACE" />
       </logger>
    

     

     

    Q5: How do I logout of a web application?

     

    A5: Invalidate the web session

     

    Q6: How do I logout with basic auth, I did invalidate the session?

     

    A6: It did logout, but then the browser automatically logged back in with saved/cached information. Your web browser needs to be restarted, or its password setting cleared.

     

    Q7: Why does getUserPrincipal/getPrincipal return null after a JAAS login

     

    A7: The only time getUserPrincipal/getPrincipal return a non-null value is when the user has authenticated to the container. Doing a JAAS login from within a servlet/ejb method is simply executing an independent authentication against the corresponding JAAS login configuration.

     

     

    Q8: Why does the getUserPrincipal return null when I am logged in to a web app.

     

    A8: The only time getUserPrincipal return non-null is when the user has been authenticated to access the secured resource invoking the getUserPrincipal. Unsecure content does not involve validating the user authentication/permissions and so the user is not associated with the request.

     

     

    Q9: How do I access the current authenticated call Subject?

     

    A9: By using the JACC subject policy context handler as shown here:

     

    import javax.security.auth.Subject;
    import javax.security.jacc.PolicyContext;
    import javax.security.jacc.PolicyContextException;
    ...
       /** The JACC PolicyContext key for the current Subject */
       private static final String SUBJECT_CONTEXT_KEY = "javax.security.auth.Subject.container";
    ...
             Subject caller = (Subject) PolicyContext.getContext(SUBJECT_CONTEXT_KEY);
    

     

    Q10: Why isn't my authentication info picked up from the JNDI InitialContext

     

    A10: Because there is no reason for it. You have to use an InitialContextFactory implementation that supports this. See the Available InitialContext Factories section, and LoginInitialContextFactory or JndiLoginInitialContextFactory in particular.

     

    Note that this implicit login does not work any longer in JBoss 5.0! You will have to do a "clean" login.

     

    The easiest way is to use "org.jboss.security.client.SecurityClient":

     

    For a "plain" login:

    SecurityClient client = SecurityClientFactory.getSecurityClient();
    client.setSimple("user", "mypass");
    client.login();
    

    For a JAAS login:

     

     

    SecurityClient client = SecurityClientFactory.getSecurityClient();
    client.setJaas("loginconfigname", mycallbackhandler);
    client.login();

    In this case, you need a file "auth.conf" in META-INF with this content:

     

    loginconfigname {
       // jBoss LoginModule
       org.jboss.security.ClientLoginModule  required
       ;
    };
    

     

    See this forum thread for more details: http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4198157

     

     

    Q11: When I change the security information in the backend store (jdbc, ldap, etc.), why aren't the changes are not immeadiately seen?

     

    A11: Because the security manager caches credentials by default. See CachingLoginCredentials for information on configuring the cache and flushing the cache.

     

    Q12: Why can't I access an ejb method that does not have a method-permission?

     

    A12: Because the default permission mode assigned to a method that has no explicit method-permission mapping is to treat the method as though it was assigned an excluded permission. You either need to assign a method-permission, or change the default behavior using the missing-method-permissions-excluded-mode flag in the deployment jboss.xml or global conf/standardjboss.xml:

    <jboss>
      <!--
       The missing-method-permissions-excluded-mode is a boolean
       that allows the deployer to globally indicate that all methods without a
       method-permission element should be treated as excluded(= true and the default),
       or that methods without a method-permission element should be treated as
       unchecked(= false)
      -->
      <missing-method-permissions-excluded-mode>true</missing-method-permissions-excluded-mode>
    ...
    

     

    Q13. How do I get the Servlet Request after authentication? http://wiki.jboss.org/wiki/Wiki.jsp?page=AccessingServletRequestForAuthentication

     

    Q14. For Form Authentication, how do I get hold of the userid/password/exception etc?

     

    A14: http://wiki.jboss.org/wiki/Wiki.jsp?page=ExtendedFormAuthenticator && http://wiki.jboss.org/wiki/Wiki.jsp?page=CustomizingSecurityUsingValves

     

    Q15. For Form Authentication, how do I get hold of the roles for the user?

     

    A15: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=83874

     

    Q16. Primer for SSL Certificates

     

    Q17. How do I encrypt the keystore password in the tomcat connector?

     

    A17: http://wiki.jboss.org/wiki/Wiki.jsp?page=EncryptKeystorePasswordInTomcatConnector

     

    Q18. How do I secure (authentication/authorization) the JMX invoker?

     

    A18: http://wiki.jboss.org/wiki/Wiki.jsp?page=SecureTheInvokers

     

    Q19: How do I secure the JMX console?

     

    A19: http://community.jboss.org/wiki/SecureTheJmxConsole

     

    Q20. How do I become my own Certificate Authority?

     

    A20: http://churchillobjects.com/c/11201g.html

     

    Q21. Guide to securing web applications? Can you help me understand FORM based auth?

     

    A21: http://www.cgisecurity.com/owasp/html/index.html

     

    Q22. Does JBoss support programmatic web authentication?

     

    A22. http://wiki.jboss.org/wiki/Wiki.jsp?page=WebAuthentication

     

    Q23. How do I programatically establish an identity?

     

    A23: You need to perform a JAAS login against a configuration that includes the JBoss ClientLoginModule. When inside of a server/multi-threaded environment, the multi-threaded=true and restore-login-identity=true options should be enabled. An example login fragment:

    import javax.security.auth.login.LoginContext;
    import org.jboss.security.auth.callback.UsernamePasswordHandler;
    
       void runAsUser(String username, String password)
       {
             UsernamePasswordHandler handler = new UsernamePasswordHandler(username, password);
             LoginContext lc = new LoginContext("client-login", handler);
             lc.login();
             // Any calls to secured resources now use the username/password identity
             ...
             // Clear and restore the previous identity
             lc.logout();
       }
    

     

    Q24.  I upgraded from JBoss 4 to JBoss 5 and receive the message below in the server log.  What is the solution?

         WARN  [SecurityAssociation] You are using deprecated api to getSubject. Use security context based approach

     

    A24: Subject caller = (Subject) PolicyContext.getContext("javax.security.auth.Subject.container");

     

    Q 25. Web Authentication based on http request parameters.

    A25. http://community.jboss.org/wiki/WebAuthenticationUsingHTTPRequestParameters

     

    Additional Tips can be had here. See if any of the tips answers your question.