1 2 Previous Next 19 Replies Latest reply: Mar 3, 2011 11:32 AM by Marcus Moyses RSS

Security Configuration in Domain Model - AS7

Anil Saldhana Master

I want to dedicate this thread for discussions surrounding the security configuration in AS7 based on the proposed domain model.

 

Currently, we have the following security configuration needs:

1) Configuration driving the security domains. (login-config.xml, xxx-jboss-beans.xml)

2) JSSE configuration (JaasSecurityDomain)

3) JCA configuration if desired.

 

Ideally, we should consolidate these in the domain model.

 

Apart from this, we may need the PicketLink IDM to model the users/roles etc for administration of the AS instances.

 

Passwords are going to be a first class objects of the domain model.  So they can have the in built masking feature.

  • 1. Re: Security Configuration in Domain Model - AS7
    Anil Saldhana Master

    I had the domain model the wrong way.  Currently the domain model has the ssl settings at an high level as follows:

     

     

    <ssl>
      <cipher/>
    </ssl>
    

     

    The idea is to have a subsystem independent model of settings in the domain model and then can be applied to the various subsystems.

     

     

    In the case of security,  we definitely need to think about the JSSE settings.

     

    Passwords are first class objects of the domain model so we should be able to apply masking/obfuscation.

  • 2. Re: Security Configuration in Domain Model - AS7
    Marcus Moyses Novice

    I think we need to be able to set more than one ssl configuration for the domain. Something like:

     

    <ssl id="config1">

      <cipher/>

    </ssl>

    <ssl id="config2">

      <cipher/>

    </ssl>

     

    Customers often use different certificates for each service like EJB3, HTTPS, etc.

  • 3. Re: Security Configuration in Domain Model - AS7
    Anil Saldhana Master

    Further discussions with AS team has yielded something like the following:

     

    <security-domain name="foo">

        <ldap-auth server="...">

        <jdbc-auth ...>

        <extension module="..."  class="...">

    </security-domain>

     

    This is just a natural language description in the domain model. What "ldap-auth" maps to is an implementation detail.

  • 4. Re: Security Configuration in Domain Model - AS7
    Anil Saldhana Master

    The domain model should also consider SSO into various containers.  It will be a sub element of the ejb, web domain language.  We are going to be pushing for the use of STS.

  • 5. Re: Security Configuration in Domain Model - AS7
    Marcus Moyses Novice

    I'm still learning AS7 so I'm gonna start with some basic configuration that we definitely need in the security container.

    For now I'm trying to set up something as simple as:

    <subsystem xmlns="urn:jboss:domain:security:1.0" >

         <security-manager class-name="org.jboss.security.plugins.auth.JaasSecurityManagerBase" deep-copy-subject-mode="false" default-callback-handler-class-name="org.jboss.security.auth.callback.JBossCallbackHandler"/>

    </subsystem>

     

    I can already see we are going to need another sub element for the authentication cache. Maybe one for the default login module xml.

    I'll update this thread once I manage to install the basic security container.

  • 6. Re: Security Configuration in Domain Model - AS7
    Anil Saldhana Master

    I am thinking we should choose a better name than "security-manager" given that people get confused with the Java Security Manager.  Can we qualify it further as authentication-manager, authorization-manager etc, maybe?

     

    Also,  in AS5/6,  for the web layer,  we always go through the authorization layer for each security check.  In my view, we should now stop doing that by default.  Let the user configure that the web authorization goes through PicketBox authorization stack (needed for JACC, XACML etc). In AS5/6, there is a property that turns off the authz layer.  But since 95% of web deployments dont care about JACC or XACML, we should turn it off by default/.

  • 7. Re: Security Configuration in Domain Model - AS7
    Marcus Moyses Novice

    I guess "authentication-manager" is as good a name as any.

    I will change it to that then.

  • 8. Re: Security Configuration in Domain Model - AS7
    Marcus Moyses Novice

    Actually I think a better model would be:

    <security>

      <security-management security-management-class-name="org.jboss.as.security.plugins.JNDIBasedSecurityManagement">

        <authentication authentication-manager-class-name="org.jboss.security.plugins.auth.JaasSecurityManagerBase" deep-copy-subject-mode="false" default-callback-handler-class-name="org.jboss.security.auth.callback.JBossCallbackHandler"/>

        <authorization authorization-manager-class-name="org.jboss.security.plugins.JBossAuthorizationManager"/>

      </security-management>

      <subject-factory subject-factory-class-name="org.jboss.as.security.plugins.JBossSecuritySubjectFactory"/>

    </security>

     

    This way we can start a separate service for the ISecurityManagement interface and make other services depend on it, like the subject factory for instance.

    I will also work on a sub element of security for the authentication cache.

    I need some ideas on where to model the configuration for the security domains. Maybe we should just get rid of login-config.xml and map the security domains directly in the domain model. What do you think? We could start the container with only the "other" configuration and let each application deploy it's own security domain configuration.

  • 9. Re: Security Configuration in Domain Model - AS7
    Anil Saldhana Master

    I think in the domain model, they do not want any mention of the FQN. So you can use an alias.  I would check with the AS7 team on this.

     

    I would definitely get away from login-config.xml.  It has been abused a lot. Some users do prefer the centralized security domain config, though.

  • 10. Re: Security Configuration in Domain Model - AS7
    Brian Stansberry Master

    Yes, we don't want fully qualified class names. They are fragile (refactoring breaks existing configs). They are verbose, which makes them user-unfriendly. And they often don't convey a lot of information that would help a user understand the configuration.

     

    FQCNs if absolutely necessary are ok for extension points (where users plug in some class that implements an extension API). But then use a different attribute (and perhaps a different element) where the user declares the class. For standard configurations using our classes, use a different element, and/or a different attribute with aliases as the value. Or, if we only ship one implementation of something, don't mention it at all in the config.

     

    For example, the domain configuration for HornetQ involves configuring connectors, so there are options like:

     

    <netty-connector  name="external"><param name="x" value="y"/></netty-connector>

    <in-vm-connector name="in-vm"><param name="x" value="y"/></in-vm-connector>

    <connector name="custom"><factory-class>com.xyz.XyzConnectorFactory</factory-class><param name="x" value="y"/></connector>

     

    The 3rd variant supports arbitrary extensions, but 99% of users won't use it; they'll use one or both of the first two variants.

     

    Note the 2nd variant is much better than the first; the first leaks implementation details (use of netty).

  • 11. Re: Security Configuration in Domain Model - AS7
    Marcus Moyses Novice

    We do ship only one implementation of those classes so in fact we wouldn't need to set the default values for the FQCNs and the security configuration in domain.xml and standalone.xml for 99% of the users would be simply

     

    <subsystem xmlns="urn:jboss:domain:security:1.0"></subsystem>

     

    I was just trying to show the complete model with all the attributes filled with their default values so we can evaluate the options available to customize security.

    Some customers do need to use custom implementations so there is not much way around setting the FQCN of the implementation somewhere in the configuration.

  • 12. Re: Security Configuration in Domain Model - AS7
    Brian Stansberry Master

    OK, good. If any attribute that takes a class name is optional, please don't include the standard implementation class name as the default in the XSD.

  • 13. Re: Security Configuration in Domain Model - AS7
    Jesper Pedersen Master

    You are planning to put the code outside of AS 7, and just have a small integration layer with the specifics for AS 7, right ?

     

    That way the Picketbox code can be used for other projects out there.

  • 14. Security Configuration in Domain Model - AS7
    Darran Lofthouse Master

    Is this approach still being considered?  I see from the current schema that we seem to now be configuring using a login-module element rather than mechanism specific elements as in this post.

     

    Anil Saldhana wrote:

     

    Further discussions with AS team has yielded something like the following:

     

    <security-domain name="foo">

        <ldap-auth server="...">

        <jdbc-auth ...>

        <extension module="..."  class="...">

    </security-domain>

     

    This is just a natural language description in the domain model. What "ldap-auth" maps to is an implementation detail.

     

    Just really checking if there will be authentication mechanism specific elements / types I can re-use or if we are remaining with the generic login-module elements?

1 2 Previous Next