1 2 3 Previous Next 40 Replies Latest reply: Jan 15, 2007 8:14 AM by George Gastaldi Go to original post RSS
  • 16. Re: Generalizing the JAAS and JACC service
    Anil Saldhana Master

    Scott, I wanted to ask you this sometime ago, but thought I would try to figure it out myself. It did not get any clearer to me.

    <xsd:element name="application-policy">
     <xsd:complexType>
     <xsd:annotation>
     <xsd:appinfo>
     <jbxb:class
     impl="org.jboss.security.auth.login.AuthenticationInfoContainer"/>
     <jbxb:addMethod name="add" valueType="child"/>
     </xsd:appinfo>
     </xsd:annotation>
    
     <xsd:sequence>
     <xsd:element minOccurs="1" maxOccurs="1"
     ref="jbsx:application-policy-type"/>
     </xsd:sequence>
     <xsd:attribute name="name" use="required" type="xsd:string"/>
     </xsd:complexType>
     </xsd:element>
    


    So what exactly do the jbxb annotations do ? The reason I ask is that when I run the XMLLoginModulesTestCase, XB layer does not call "addChild" of AuthenticationInfoContainer and we are explictly instantiating "AuthenticationInfo" in LoginConfigObjectModelFactory. So these annotations are not coming into picture.

    Are these annotations becoming alive in a MC environment? Any related testcases?

    I really need to get an handle on these annotations before I commit changes to the security_config_5_0.xsd.

    Can you please explain?

  • 17. Re: Generalizing the JAAS and JACC service
    Scott Stark Master

    The unit tests are in:

    org.jboss.test.xml.DynamicLoginConfigUnitTestCase
    testsuite\src\resources\xml\loginconfig\config.xml
    testsuite\src\resources\xml\loginconfig\security-config_4_1.xsd
    testsuite\src\resources\xml\loginconfig\user-roles_1_0.xsd

    The jbxb:class is mapping the application-policy element to a org.jboss.security.auth.login.AuthenticationInfoContainer instance. The jbxb:addMethod is mapping the application-policy element object to add to the parent PolicyConfig object using its add(AuthenticationInfo) method.

    This test looks to still be working in jboss-head:

    one-test:
     [mkdir] Created dir: C:\cvs\JBossHead\jboss-head\testsuite\output\log
     [junit] Running org.jboss.test.xml.DynamicLoginConfigUnitTestCase
     [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.813 sec
    



  • 18. Re: Generalizing the JAAS and JACC service
    Anil Saldhana Master

    I will take a look at the testcase.

    Earlier I was wondering why you had not explicitly modeled an ApplicationPolicy instance to be plugged into PolicyConfig, rather than a direct plug of AuthenticationInfo. Now it makes sense.

  • 19. Re: Generalizing the JAAS and JACC service
    Anil Saldhana Master

    Subsection 1:
    I want to remove the jaas prefix completely in favor of a new prefix called jbsx for the jbxb annotation based injection.

    Subsection 2:
    Given this, any feedback on the following schema file?

    <?xml version="1.0" encoding="UTF-8"?>
    <!-- $Id -->
    
    <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
     elementFormDefault="qualified"
     xmlns:jbsx="urn:jboss:security-config"
     xmlns:jbxb="http://www.jboss.org/xml/ns/jbxb"
     targetNamespace="urn:jboss:security-config">
    
     <xsd:annotation>
     <xsd:appinfo>
     <jbxb:schemaBindings>
     <jbxb:package name="org.jboss.security.auth.login"/>
     <jbxb:ignoreUnresolvedFieldOrClass>
     false</jbxb:ignoreUnresolvedFieldOrClass>
     </jbxb:schemaBindings>
     </xsd:appinfo>
     </xsd:annotation>
    
     <xsd:element name="policy">
     <xsd:complexType>
     <xsd:annotation>
     <xsd:appinfo>
     <jbxb:class
     impl="org.jboss.security.auth.login.PolicyConfig"/>
     </xsd:appinfo>
     </xsd:annotation>
    
     <xsd:sequence>
     <xsd:element maxOccurs="unbounded" ref="jbsx:application-policy"/>
     </xsd:sequence>
     </xsd:complexType>
     </xsd:element>
    
     <xsd:element name="application-policy">
     <xsd:complexType>
     <xsd:annotation>
     <xsd:appinfo>
     <jbxb:class
     impl="org.jboss.security.auth.login.AuthenticationInfoContainer"/>
     <jbxb:addMethod name="add" valueType="child"/>
     </xsd:appinfo>
     </xsd:annotation>
     <xsd:choice>
     <xsd:element ref="jbsx:authentication"/>
     <xsd:element ref="jbsx:authentication-jaspi"/>
     </xsd:choice>
     <xsd:attribute name="name" use="required" type="xsd:string"/>
     </xsd:complexType>
     </xsd:element>
    
     <xsd:element name="authentication">
     <xsd:annotation>
     <xsd:appinfo>
     <jbxb:skip/>
     </xsd:appinfo>
     </xsd:annotation>
     <xsd:complexType>
     <xsd:sequence>
     <xsd:element ref="jbsx:login-module"/>
     </xsd:sequence>
     </xsd:complexType>
     </xsd:element>
    
     <xsd:element name="login-module">
     <xsd:complexType>
     <xsd:annotation>
     <xsd:appinfo>
     <jbxb:class
     impl="org.jboss.security.auth.login.AppConfigurationEntryHolder"/>
     </xsd:appinfo>
     </xsd:annotation>
     <xsd:sequence>
     <xsd:element minOccurs="0" maxOccurs="unbounded"
     ref="jbsx:module-option"/>
     </xsd:sequence>
     <xsd:attribute name="code" use="required" type="xsd:string"/>
     <xsd:attribute name="flag" use="required">
     <xsd:simpleType>
     <xsd:restriction base="xsd:string">
     <xsd:enumeration value="required"/>
     <xsd:enumeration value="requisite"/>
     <xsd:enumeration value="sufficient"/>
     <xsd:enumeration value="optional"/>
     </xsd:restriction>
     </xsd:simpleType>
     </xsd:attribute>
     </xsd:complexType>
     </xsd:element>
    
     <xsd:element name="module-option">
     <xsd:complexType mixed="true">
     <xsd:annotation>
     <xsd:appinfo>
     <!-- ModuleOption declares a constructor that takes name as a parameter
     while the value should be set with the setter.
    
     This use-case is not supported out-of-the-box. So, we use this container. -->
     <jbxb:class
     impl="org.jboss.security.auth.login.ModuleOptionContainer"/>
     </xsd:appinfo>
     </xsd:annotation>
     <xsd:sequence>
     <xsd:any minOccurs="0" maxOccurs="1" namespace="##other"/>
     </xsd:sequence>
     <xsd:attribute name="name" use="required" type="xsd:string"/>
     </xsd:complexType>
     </xsd:element>
    
    
     <xsd:element name="authentication-jaspi">
     <xsd:annotation>
     <xsd:appinfo>
     <jbxb:skip/>
     </xsd:appinfo>
     </xsd:annotation>
     <xsd:complexType>
     <xsd:choice>
     <xsd:element maxOccurs="unbounded" ref="jbsx:login-module-stack"/>
     <xsd:element maxOccurs="unbounded" ref="jbsx:auth-module"/>
     </xsd:choice>
     </xsd:complexType>
     </xsd:element>
    
     <xsd:element name="login-module-stack">
     <xsd:complexType>
     <xsd:annotation>
     <xsd:appinfo>
     <jbxb:class
     impl="org.jboss.security.auth.login.LoginModuleStackContainer"/>
     </xsd:appinfo>
     </xsd:annotation>
     <xsd:sequence>
     <xsd:element minOccurs="1" maxOccurs="unbounded"
     ref="jbsx:login-module"/>
     </xsd:sequence>
     <xsd:attribute name="name" use="required" type="xsd:string"/>
     </xsd:complexType>
     </xsd:element>
    
     <xsd:element name="auth-module">
     <xsd:complexType>
     <xsd:annotation>
     <xsd:appinfo>
     <jbxb:class
     impl="org.jboss.security.auth.container.config.AuthModuleEntryHolder"/>
     </xsd:appinfo>
     </xsd:annotation>
     <xsd:sequence>
     <xsd:element minOccurs="0" maxOccurs="unbounded"
     ref="jbsx:module-option"/>
     </xsd:sequence>
     <xsd:attribute name="code" use="required" type="xsd:string"/>
     <xsd:attribute name="login-module-stack-ref" type="xsd:string"/>
     </xsd:complexType>
     </xsd:element>
    </xsd:schema>
    


    Subsection 3:
    and a sample config file that includes the jaspi configuration with backward support for jaas authentication configuration(minus the jaas prefix renamed as jbsx).
    <?xml version="1.0" encoding="UTF-8"?>
    <!-- $Id$ -->
    
    <jbsx:policy
     xsi:schemaLocation="urn:jboss:security-config security-config_5_0.xsd"
     xmlns:jbsx="urn:jboss:security-config"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     >
     <jbsx:application-policy name="conf1">
     <jbsx:authentication>
     <jbsx:login-module code="org.jboss.security.auth.spi.XMLLoginModule"
     flag="required">
     <jbsx:module-option name="userInfo">
     <ur:users
     xsi:schemaLocation="urn:jboss:user-roles user-roles_1_0.xsd"
     xmlns:ur="urn:jboss:user-roles">
     <ur:user name="jduke" password="theduke">
     <ur:role name="Role1"/>
     <ur:role name="Role2"/>
     <ur:role name="Echo"/>
     <ur:role name="callerJduke" group="CallerPrincipal"/>
     </ur:user>
     <ur:user name="scott" password="echoman">
     <ur:role name="Echo"/>
     <ur:role name="ProjectUser"/>
     <ur:role name="callerScott" group="CallerPrincipal"/>
     </ur:user>
     <ur:user name="stark" password="javaman">
     <ur:role name="Java"/>
     <ur:role name="Coder"/>
     <ur:role name="callerStark" group="CallerPrincipal"/>
     </ur:user>
     <ur:user name="jdukeman" password="anotherduke">
     <ur:role name="Role2"/>
     <ur:role name="Role3"/>
     <ur:role name="callerJdukeman" group="CallerPrincipal"/>
     </ur:user>
     <ur:user name="invoker" password="invoker">
     <ur:role name="HttpInvoker"/>
     </ur:user>
     <ur:user name="admin" password="admin">
     <ur:role name="JBossAdmin"/>
     </ur:user>
     </ur:users>
     </jbsx:module-option>
     <jbsx:module-option name="unauthenticatedIdentity">guest</jbsx:module-option>
     </jbsx:login-module>
     </jbsx:authentication>
     </jbsx:application-policy>
    
     <jbsx:application-policy name="conf-jaspi">
     <jbsx:authentication-jaspi>
     <jbsx:login-module-stack name="lm-stack">
     <jbsx:login-module
     code="org.jboss.security.auth.spi.UsersRolesLoginModule"
     flag="required">
     <jbsx:module-option name="usersProperties">props/jbossws-users.properties</jbsx:module-option>
     <jbsx:module-option name="rolesProperties">props/jbossws-roles.properties</jbsx:module-option>
     <jbsx:module-option name="unauthenticatedIdentity">anonymous</jbsx:module-option>
     </jbsx:login-module>
     </jbsx:login-module-stack>
     <jbsx:auth-module code="auth.module1.class.name">
     <jbsx:module-option name="usersProperties">props/jbossws-users.properties</jbsx:module-option>
     <jbsx:module-option name="rolesProperties">props/jbossws-roles.properties</jbsx:module-option>
     <jbsx:module-option name="unauthenticatedIdentity">anonymous</jbsx:module-option>
     </jbsx:auth-module>
    
     <jbsx:auth-module code="auth.module2.class.name" login-module-stack-ref="lm-stack"/>
     </jbsx:authentication-jaspi>
     </jbsx:application-policy>
    </jbsx:policy>
    


    Subsection 4:
    Since JASPI has no configuration like JAAS, I am introducing AuthModuleEntry similar to AppConfigurationEntry (in JAAS)

    Subsection 5:
    PolicyConfig now contains a Map of BaseAuthenticationInfo objects rather than a Map of AuthenticationInfo objects where:
    public AuthenticationInfo extends BaseAuthenticationInfo and
    public JaspiAuthenticationInfo extends BaseAuthenticationInfo
    


  • 20. Re: Generalizing the JAAS and JACC service
    Anil Saldhana Master

    Also, I think the following optimization in the JBXB annotations based injection process is good.

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

  • 21. Re: Generalizing the JAAS and JACC service
    Scott Stark Master

    The namespace should include the version number in it as is done starting with the 4.1 version of the login config:

    <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
     elementFormDefault="qualified"
     xmlns:jaas="urn:jboss:security-config:4.1"
     xmlns:jbxb="http://www.jboss.org/xml/ns/jbxb"
     targetNamespace="urn:jboss:security-config:4.1">
    ...
    


    Otherwise there is no ability to understand the schema version without referring to the schemaLocation and that should not be the case.

  • 22. Re: Generalizing the JAAS and JACC service
    Anil Saldhana Master

    I have added the following support:
    1) Updated schema file with support for both authentication and authentication-jaspi elements.
    2) A Server Auth Module called "DelegatingServerAuthModule" that basically delegates to a stack of login modules.
    3) DynamicLoginUnitTestCase updated to handle the new schema file.
    3) Unit tests. (tests-security-jaspi-unit)

    Future:
    1) I now have to tie the PolicyConfig to a security service that is higher level than the current JaasSecurityManagerService. I intend to call it "JBossSecurityManagerService" (Any better name?) I need to start the discussion on the new security service that will have enhanced caching capabilities, federation, configuration etc in a new thread.

    2) An webapp will still refer to a security domain in its jboss-web.xml. But the security-domain element will look as:

     <security-domain>java:/jbsx/jmx-console</security-domain>
    


  • 23. Re: Generalizing the JAAS and JACC service
    Scott Stark Master

    The security-domian naming convention should not have to change. By default the existing java:/jaas/jmx-console usage needs to continue to work. This should simply map to the DelegatingServerAuthModule implementation with a login-module-stack matching the jmx-console configuration.

  • 24. Re: Generalizing the JAAS and JACC service
    Anil Saldhana Master

    If you see my previous post showing the final version of the login-config policy element, you will see that I said I will retain the existing JAAS authentication element as is AND introduce an authentication-jaspi element which can include a loginmodule stack and one or more authmodule entries.

    Given this, the user will still be able to use the existing java://jaas security domain configuration that will flow through the JaasSecurityManagerService.

    I am proposing the new java://jbsx/jmx-console naming convention for the authentication-jaspi element that relies on the new securitymanager service which I plan to call JBossSecurityManagerService. (You can suggest a better name)

    I have been thinking that the JaasSecurityManager framework can exist side by side with the new JBossSecurityManager setup for a while, to allow users to migrate to the new setup.

    So the default/conf/jboss-service.xml would look like:

     <mbean code="org.jboss.security.plugins.JaasSecurityManagerService"
     name="jboss.security:service=JaasSecurityManager">
     .....
     </mbean>
    
     <mbean code="org.jboss.security.plugins.JBossSecurityManagerService"
     name="jboss.security:service=JBossSecurityManager">
     .....
     </mbean>
    


    Scott, do you have any other thoughts or clarifications? If I have digressed, please let me know, so that I can make the adjustments.

  • 25. Re: Generalizing the JAAS and JACC service
    Scott Stark Master

    I don't think there should be two security manager related services deployed. I'm saying that the java:/jaas/xxx reference should be interpretted as a preconfigured java:/jbsx/xxx reference with the login module stack pulled from the legacy xxx configuration:

     <application-policy name="xxx">
     <authentication>
     <login-module>
    ...
     </jogin-module>
     </uthentication>
     </application-policy>
    


    The server auth module would be the server auth module that delegates to jaas.


  • 26. Re: Generalizing the JAAS and JACC service
    Anil Saldhana Master

    Another issue to consider is that the JASPI stuff is tied heavily to the message format/container, where as the JAAS security managers have no notion of the layer (HTTP/EJB). Hence they can be shared across the layers.

    Here is the JASPI stuff:

    AuthContextFactory factory = AuthContextFactory.getFactory();
    
    //MessageLayer is a string holder. standard names are HTTP and SOAP
    //But nothing is stopping us from using the jaas config name as the message layer name (May not be standards compliant)
    
    ServerAuthConfig authConfig = factory.getServerAuthConfig(MessageLayer layer, java.net.URI uri, javax.security.auth.callback.CallbackHandler handler);
    
    //Auth config will have the information about the authmodules to use
    ServerAuthContext authContext = factory.getAuthContext(authConfig , java.lang.String operation)
    
    //AuthParam is a holder for HttpServletRequest/Response etc
    
    authContext.validateRequest(AuthParam authParam,
    javax.security.auth.Subject source,
    javax.security.auth.Subject recipient, java.util.Map
    sharedState)
    


    And our current AuthenticationManager interface looks like:


    /** The AuthenticationManager is responsible for validating credentials
     * associated with principals.
     */
    public interface AuthenticationManager
    {
    
     String getSecurityDomain();
     public boolean isValid(Principal principal, Object credential);
     boolean isValid(Principal principal, Object credential,Subject activeSubject);
     Subject getActiveSubject();
    }
    


    This is inadequate.

    Possible solution:
    -Beef up the AuthenticationManager interface to include layer information plus the messages (httpservletrequest etc) in the validation methods. Then the securitymanagers can use the passed information to pass to the JASPI layer. [This is needed for the tomcat federation project also where the auth process should consider the request message for headers, cookies etc]

    Any other thoughts on this?




  • 27. Re: Generalizing the JAAS and JACC service
    Scott Stark Master

    The AuthenticationManager is closest to the *AuthContext so the initial update should just support those methods by extending ServerAuthContext, and the default implementation (say JASPISecurityManager) would default to the externalized login configuration like the JaasSecurityManager does today.

    The factory stuff is just an alternative mechanism for accessing the ServerAuthContext rather than using jndi as is done today for the AuthenticationManager.

  • 28. Re: Generalizing the JAAS and JACC service
    Anil Saldhana Master

    I have this implemented. Will take another couple of days to test it further.

    Currently I have tested with unit tests and also with the FormAuthUnitTestCase (uses the ExtendedFormAuthenticator and has a test for flushonsessioninvalidation.)

    Supports:
    a) Both java:/jaas/xxx and java:/jbsx/yyy are supported.
    b) JASPISecurityManager currently has a cache that is a rip off of the DomainCache in the JaasSecurityManager.

    Todo:
    a) Need to run with a security manager and add privilegedactions.
    b) More testing.

    A few things to note:
    Point 1:
    a) I have created a marker interface called "GeneralizedAuthenticationManager" that extends SubjectSecurityManager and ServerAuthContext interfaces. Can you suggest a better name please? I do not like JBossAuthenticationManager also.
    Note:
    SubjectSecurityManager is a legacy interface that extends AuthenticationManager. Atleast the tomcat layer (JBossSecurityMgrRealm) and the JCA layer(org.jboss.resource.connectionmanager.BaseConnectionManager2) have references.

    public class JASPISecurityManager extends ServiceMBeanSupport
    implements GeneralizedAuthenticationManager,RealmMapping
    


    I think we should remove the SubjectSecurityManager interface.

    Point 2:
    The JaasSecurityManagerService manages security managers, but is not tied to Jaas, which is good plus provides a manageable securityMgrClass (where my JASPISecurityManager will reside). One thing I notice is that this service chops the "java:/jaas/XXX" to provide just the XXX to the security manager. This is no big deal as the securitymgr can figure out whether the authenticationinfo is legacy or is the new jaspi config from the PolicyConfig object provided a policy/securitydomain name(See also point 3).

    Point 3:
    In this current cut of the implementation, I have added a value added method in the XMLLoginConfigImpl to return me the AuthenticationInfo given a policyname. This is not right because XMLLoginConfigImpl extends Configuration (from the Jaas World) and it should only be returning AppConfigurationEntries when asked.

    The issue is that the SecurityConfig service that externalizes the configuration is heavily Jaas based. Do you want me to add a new service to establish JASPI config similar to SecurityConfig or is this extra method in XMLLoginConfigImpl ok?

    public class XMLLoginConfigImpl extends Configuration
    /**
     * Method that returns the parsed AuthenticationInfo needed by
     * the JASPI framework until a seperate Configuration mechanism
     * for JASPI is established
     *
     * @return the parsed AuthenticationInfo object
     */
     public BaseAuthenticationInfo getAuthenticationInfo(String domainName)
     {
     if(appConfigs == null)
     loadConfig();
     return appConfigs.get(domainName);
     }
    


  • 29. Re: Generalizing the JAAS and JACC service
    Scott Stark Master

    JASPISecurityManager should not be extending the ServiceMBeanSupport class as its not consistent with the pojo model. The jmx management interface should be introduced via another JASPISecurityManagerService wrapper.

    Its debatable as to whether the JASPISecurityManager should implement RealmMapping as this is another legacy interface that needs to be generalized and really should be a seperate service as is the case with the JACC authorization service, even though this does not implement RealmMapping. Authentication and authorization should be independent services that simply align on the authenticated identity.

    The JaasSecurityManagerService securityMgrClass and java:/jaas jndi object factory are simply acting as a factory for AuthenticationManager instances. The JaasSecurityManagerService does not care whether the AuthenticationManager uses JAAS, but it does require a ctor(String, CallbackHandler) signature for the securityMgrClass. Where does the JaasSecurityManagerService care about whether the securityMgrClass care about whether a JaasSecurityManager or JASPISecurityManager is being used?

    Exposing additional info from the XMLLoginConfigImpl is not a problem. Implementing a new SecurityConfig will be more a function of what the default jboss javax.security.auth.container.AuthContextFactory implementation will be I would think.