Anil Saldhana [http://community.jboss.org/people/anil.saldhana%40jboss.com] created the discussion "Re: Security Configuration in Domain Model - AS7" To view the discussion, visit: http://community.jboss.org/message/575183#575183 -------------------------------------------------------------- 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/. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/575183#575183] Start a new discussion in PicketBox Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]

Marcus Moyses [http://community.jboss.org/people/mmoyses] created the discussion "Re: Security Configuration in Domain Model - AS7" To view the discussion, visit: http://community.jboss.org/message/577054#577054 -------------------------------------------------------------- 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. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/577054#577054] Start a new discussion in PicketBox Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]

Brian Stansberry [http://community.jboss.org/people/bstansberry%40jboss.com] created the discussion "Re: Security Configuration in Domain Model - AS7" To view the discussion, visit: http://community.jboss.org/message/577097#577097 -------------------------------------------------------------- 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). -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/577097#577097] Start a new discussion in PicketBox Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]

Brian Stansberry [http://community.jboss.org/people/bstansberry%40jboss.com] created the discussion "Re: Security Configuration in Domain Model - AS7" To view the discussion, visit: http://community.jboss.org/message/577263#577263 -------------------------------------------------------------- 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. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/577263#577263] Start a new discussion in PicketBox Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]