Web Application - Security Mechanism Selection
by 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.
11 years, 8 months
[PicketLink] - Version 3.0.0.Alpha1 Released
by Pedro Igor Silva
Hi All,
Today we released the first Alpha version for PicketLink. For now, we're releasing only the IDM and CORE modules.
<dependency>
<groupId>org.picketlink</groupId>
<artifactId>picketlink-idm-impl</artifactId>
<version>3.0.0.Alpha1</version>
</dependency>
<dependency>
<groupId>org.picketlink</groupId>
<artifactId>picketlink-core-impl</artifactId>
<version>3.0.0.Alpha1</version>
</dependency>
We're waiting on SourceForge to upload the distribution package with the binaries, docs and sources. I'll let you know when everything is ok.
Regards.
Pedro Igor
11 years, 8 months
