[security-dev] Web Application - Security Mechanism Selection

[Darran Lofthouse]

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.