[security-dev] Web Application - Security Mechanism Selection

[Boleslaw Dawidowicz]

I like it. Especially the overrides part

>From mobile

Dnia 12 mar 2013 o godz. 14:45 Darran Lofthouse <darran.lofthouse at jboss.com> napisał(a):

> 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/security-dev