Firstly my apologies for sending to three lists but this is a topic that has a lot of interested parties so I wanted to make sure all were covered. We are currently working on what is needed for Undertow to be integrated within AS8 - making good progress with the standard mechanisms as specified by the servlet specification but now reaching the more complex configuration scenarios which I wanted to discuss in this e-mail. The core of Undertow supports multiple authentication mechanisms being active for a given web application concurrently e.g. Client Cert, Digest and SPNEGO all at the same time. Some of this is enabled for domain management already but for web app deployments the initial behaviour is that a single mechanism is associated based on the web.xml. So the configuration I am now looking at obtaining some feedback for is: - - Defining new authentication mechanisms. - Defining a set of these mechanisms. - Where these definitions should live, webapp? subsystem? both? Initially the integration will be with the existing JAAS domains as that is what exists today, once we have PicketLink available in a subsystem and the work David is working on regarding identity/request association then we will also migrate to those as well.

For the moment a web application is also associated with a single security domain - once we migrate to PicketLink it will be associated with a single defintion there. * Historic Configuration * Up until JBoss AS 6 it was possible for single authentication mechanisms to be defined within the JBoss Web configuration, within the web.xml the custom auth-method could then be referenced to enable the new mechanism. From JBoss AS 7 the authentication mechanisms were defined by defining the mechanism as a valve within the jboss-web.xml - the presence of the mechanism was then detected during deployment causing the addition of a mechanism based on the auth-method to be skipped. In both cases the jboss-web.xml descriptor is used to associate the web application with the security domain. * AS8 Configuration * Users are already used to providing a lot of their configuration within the deployments - maybe even including PicketLink definitions where they do not want to use definitions defined within the AS config.

However I have also seen demand from users to be able to take a ready built war and deploy it to development or production and have appropriate security settings defined in each environment. So for this reason I think we should take the approach of allowing full security configuration within the deployment but allowing for subsystem defined overrides to override the defined configuration at deployment time. I think this leads us to three areas of configuration: - 1 - Mechanism Definition This would be something simple along the lines of: - <mechanism auth-method="..." module="..." class="..."> 2 - Security Compound This needs a good name to be selected but the idea is the compound is an ordered set of authentication mechanisms associated with a domain e.g. <security-compound name="..." domain="..."> <mechanism auth-method="..." /> <mechanism module="..." class="..." /> </security-compound> These mechanisms can either be a reference to previously defined mechanisms or can be a new definition that applies only to that compound. So far #1 and #2 can either be defined in a subsystem to be referenced subsequently or if these are defined within the jboss-web.xml descriptor they will apply to the web application being deployed. For #1 we will have defined internally the set of standard mechanisms and maybe a couple of additional mechanisms - the configuration can then be used to completely replace them with alternative implementations. 3 - Security Overrides This is something I am considering to live just within a subsystem, one or more fields are defined to match against web applications as they are being deployed and if there is a match the specified security-compound is applied to the web application instead of the definition within it's deployment descriptors. <security-override auth-method="..." war-name="..." security-domain="..." security-override="..." /> The idea being if auth-method, war-name or security-domain match the values currently defined for the web app being deployed then the security settings are replaced with the specified security-compound. A couple of areas that I still need to look into in more details are how is additional configuration passed to the individual mechanisms including possible service injection and additional areas to override from the web.xml such as FORM or role mapping definitions but initially I want to focus on how the mechanisms are specified and associated and then build from there to add the additional settings. * Legacy Valve Support * I am also working on wrapping existing valves so that they can be used within Undertow when deployments are deployed to AS8 - however I see this as an alternative to the mechanisms supported by Undertow. As a valve would be used for legacy compatibility this would mean that previous functionality can be retained but moving forwards for better integration the valve would need to be migrated.

Regards, Darran Lofthouse.

From mobile

Firstly my apologies for sending to three lists but this is a topic that has a lot of interested parties so I wanted to make sure all were covered. We are currently working on what is needed for Undertow to be integrated within AS8 - making good progress with the standard mechanisms as specified by the servlet specification but now reaching the more complex configuration scenarios which I wanted to discuss in this e-mail. The core of Undertow supports multiple authentication mechanisms being active for a given web application concurrently e.g. Client Cert, Digest and SPNEGO all at the same time. Some of this is enabled for domain management already but for web app deployments the initial behaviour is that a single mechanism is associated based on the web.xml. So the configuration I am now looking at obtaining some feedback for is: - - Defining new authentication mechanisms. - Defining a set of these mechanisms. - Where these definitions should live, webapp? subsystem? both? Initially the integration will be with the existing JAAS domains as that is what exists today, once we have PicketLink available in a subsystem and the work David is working on regarding identity/request association then we will also migrate to those as well. For the moment a web application is also associated with a single security domain - once we migrate to PicketLink it will be associated with a single defintion there. * Historic Configuration * Up until JBoss AS 6 it was possible for single authentication mechanisms to be defined within the JBoss Web configuration, within the web.xml the custom auth-method could then be referenced to enable the new mechanism. From JBoss AS 7 the authentication mechanisms were defined by defining the mechanism as a valve within the jboss-web.xml - the presence of the mechanism was then detected during deployment causing the addition of a mechanism based on the auth-method to be skipped. In both cases the jboss-web.xml descriptor is used to associate the web application with the security domain. * AS8 Configuration * Users are already used to providing a lot of their configuration within the deployments - maybe even including PicketLink definitions where they do not want to use definitions defined within the AS config. However I have also seen demand from users to be able to take a ready built war and deploy it to development or production and have appropriate security settings defined in each environment. So for this reason I think we should take the approach of allowing full security configuration within the deployment but allowing for subsystem defined overrides to override the defined configuration at deployment time. I think this leads us to three areas of configuration: - 1 - Mechanism Definition This would be something simple along the lines of: - <mechanism auth-method="..." module="..." class="..."> 2 - Security Compound This needs a good name to be selected but the idea is the compound is an ordered set of authentication mechanisms associated with a domain e.g. <security-compound name="..." domain="..."> <mechanism auth-method="..." /> <mechanism module="..." class="..." /> </security-compound> These mechanisms can either be a reference to previously defined mechanisms or can be a new definition that applies only to that compound. So far #1 and #2 can either be defined in a subsystem to be referenced subsequently or if these are defined within the jboss-web.xml descriptor they will apply to the web application being deployed. For #1 we will have defined internally the set of standard mechanisms and maybe a couple of additional mechanisms - the configuration can then be used to completely replace them with alternative implementations. 3 - Security Overrides This is something I am considering to live just within a subsystem, one or more fields are defined to match against web applications as they are being deployed and if there is a match the specified security-compound is applied to the web application instead of the definition within it's deployment descriptors. <security-override auth-method="..." war-name="..." security-domain="..." security-override="..." /> The idea being if auth-method, war-name or security-domain match the values currently defined for the web app being deployed then the security settings are replaced with the specified security-compound. A couple of areas that I still need to look into in more details are how is additional configuration passed to the individual mechanisms including possible service injection and additional areas to override from the web.xml such as FORM or role mapping definitions but initially I want to focus on how the mechanisms are specified and associated and then build from there to add the additional settings. * Legacy Valve Support * I am also working on wrapping existing valves so that they can be used within Undertow when deployments are deployed to AS8 - however I see this as an alternative to the mechanisms supported by Undertow. As a valve would be used for legacy compatibility this would mean that previous functionality can be retained but moving forwards for better integration the valve would need to be migrated. Regards, Darran Lofthouse. _______________________________________________ security-dev mailing list security-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/security-dev