[security-dev] [jboss-as7-dev] Web Application - Security Mechanism Selection

[Anil Saldhana]

Darran,
   I like all the options you have put forward here.  Would you create a 
wiki article with the
design choices you are outlining?

Also answers inline.


On 03/12/2013 08:44 AM, Darran Lofthouse wrote:
> 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.
JAAS can be one of the authentication mechanisms.  Ideally we should
look at providing an SPI. I presume we will have an SPI.
>
> 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.
The configuration in the web app deployment should only be used to
override the configuration in the domain model IMO.
>
> 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.
Very low priority. Maybe for backwards compatibility. But this will mean
you will be getting a lot of the older web code. If they have to deploy 
a legacy
valve, why not they rewrite the valve to the newer SPI?

> Regards,
> Darran Lofthouse.
>