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.
10 years, 9 months
On security context and propagation
by David M. Lloyd
The Problem
===========
In order to support all the Java EE 7 requirements, we need to be able
to propagate security context in a predictable and uniform manner.
Unfortunately, we have almost as many security context concepts as we do
projects which support authentication. There is no single way to
execute a task given a security context snapshot from another thread
that will work for all of our projects.
Project-Specific Security Context
---------------------------------
The typical implementation of a project-specific security context is
just a Subject, cached into a ThreadLocal and available via some
accessors. In addition we have the SecurityRolesAssociation concept
from PicketBox, which is meant to encapsulate roles from an EE perspective.
Available Mechanisms
====================
A number of mechanisms are provided by the JDK and the EE SDK
specifically for addressing this problem domain. Here's a quick review
so we are all speaking the same language.
javax.security.auth.Subject
---------------------------
The focal point for security in both SE and EE is the Subject class,
which is an encapsulation of related information for a security entity,
including credentials (passwords, keys, etc.) and identities (user/group
names, roles, etc.). Most (not all) of our security-aware projects
already seem to use Subject, though they may not all be using it in the
same way.
Subject has some utility methods which are intended to allow association
with the current security context. With these methods you can run tasks
as different Subjects. We currently do not support these methods.
java.security.Principal
-----------------------
The base interface for an identity. Though there are no specific
supported implementations for EE use cases, this interface would be the
base for user names, group names, role names, and so on. JDK Principal
implementations do exist for filesystem users and groups, certificate
signers and principals, JMX authenticated identities, etc.
java.security.AccessControlContext ("ACC")
------------------------------------------
This is *the* JDK-provided security context. It represents the
accumulated privileges of "protection domains", which can in turn
correspond to principals, permissions, and/or code sources (i.e. JARs).
A given ACC, in simplified terms, represents the *intersection* of
privileges granted by all the invocations on the call stack.
It gets a bit complex once you plumb the depths but imagine ACC
conceptually like a second execution stack. Every time you call into
another module, you push another layer on the stack which includes that
module's permission set (which is AllPermission by default, but can be
restricted on a per-module basis). This also includes calling into
deployments. You can also push a Subject on to this stack using
Subject.doAs*().
It is worth emphasizing that the effective permission set for an ACC is
the intersection of all of its parts, so the more calls you make, the
more restricted your permissions are. This is why we use
AccessController.doPrivileged*() and/or Subject.doAsPrivileged(): it
"clears" the stack for the duration of the invocation, adding only the
module which hosts the Privileged*Action class being executed (and
optionally the given Subject as well). This becomes important when you
consider that in many cases, you have no idea under what context a given
piece of code will be run, thus you cannot be certain whether a
restricted operation will succeed without using doPrivileged().
Perhaps the canonical case of this is class initialization. Common
sense would seem to imply that classes should always be initialized in a
privileged context, but that does not seem to be the case in reality.
Thus class init is often stuck with awkward doPrivileged constructs,
especially when field init is involved.
A Unified Security Context
==========================
The ACC affords us a uniquely suited mechanism for security association.
Subjects are already designed to be connected into ACCs; in fact, you
can query an ACC for its associated Subject with a simple get. In turn
the Subject can be queried for its Principals and credentials.
This also gives us saner integration with JAAS, to the extent that such
sanity is possible; users can use the returned Subject with
Subject.doAs() and get the results they would expect in any situation.
Finally ACC is in the JDK - any third-party security-aware framework is
much more likely to integrate with ACC and Subject than with some
framework provided by us. And, the JDK security manager framework is
ready to handle it, so a user security policy could for example forbid
certain Subjects from performing operations as an additional security layer.
Getting the Current Subject
---------------------------
To get the current subject you can do something like this:
Subject current = Subject.getSubject(AccessController.getContext());
This will work from any context - though there is a permission check
involved so a security action is in order in this case.
Propagation Within the AS
-------------------------
We need to do in-system propagation of security context in a few
situations. The predominant one (to me) is using JSR-236 thread pools -
tasks submitted by an EE component must run under the same security
context that the submitter holds.
Fortunately propagation of this nature is quite simple: use
AccessController.getContext() to acquire the current security context,
and use AccessController.doPrivileged() to resume.
Propagation to other components (e.g. EJBs) is a little different
though. In this case you do not want the baggage of the caller ACC; you
only need to preserve the caller Subject. In this case, you would
acquire the Subject as above, and the security interceptor would simply
use Subject.doAs() to resume.
Propagation Over the Network
----------------------------
It should be possible to use Principal information stored on the Subject
in combination with private credentials to provide all the information
required for network propagation of security context. This should work
particularly well with the Remoting authentication service in particular.
One Step Farther: ACC-Based Permission Checking
-----------------------------------------------
It is possible to take this idea a little farther and introduce
permission checking for JACC-style permissions based on the ACC. Using
ACC.checkPermission we can do permission checking regardless of the
presence or absence of a SecurityManager. However, it is not clear what
benefits we would derive from this move (if any).
Costs and Alternatives
======================
ACC is not free. It's a fairly heavyweight structure (though it does
make certain optimizations in some cases), and it contains what is
probably more information than is strictly necessary as it is designed
for full-bore SecurityManager sandboxing and permission checking. Thus
it is worth exploring alternatives.
Alternative: Central Security Context
-------------------------------------
Alternative #1 is to support a central security context represented by a
Subject in one place which all frameworks and libraries share.
Pros: lightweight (as much as possible anyway); conceptually simple
Cons: not compatible Subject.doAs or AccessController.doPrivileged;
additional dependency for all security-aware frameworks; third-party
stuff is less likely to just work
Alternative: ???
----------------
Add your ideas here!
Action
======
I think, barring any major dissent, we should make a move towards using
ACC as a unified security context. I think that given the EE 7 security
manager requirements and user requests over time, that standardizing
around ACC makes sense.
Discussion: go!
--
- DML
10 years, 9 months
EL 3
by Rémy Maucherat
Hi,
I reviewed EL 3, and I believe the RI looks more than acceptable
(license is GPL+CDDL - as usual, I think -, with good quality).
The new spec sources (
https://java.net/projects/el-spec/sources/source-code/show/trunk/api/src/...
) could be imported in the EE specs repository (there is no other
compatible EL 3 implementation, so no need to edit or change the
ExpressionFactory implementation loading mechanism), while the
implementation could be used directly as an external dependency, at
least for the time being.
Comments ?
Rémy
10 years, 9 months
HTTP Upgrade for AS8 Management
by Stuart Douglas
Hi everyone,
Now that we are using Undertow as the domain management HTTP server it
is now possible to use a HTTP upgrade for the native management and
remote-jmx protocols. This will allow us to run all management protocols
over port 9990, and allow us to remove 9999 from our default config. The
idea is significantly reduce the ports that are open in our default
config, ideally eventually we will just have a management and
application HTTP ports and that will be it (although some technologies
such as CORBA are not compatible with HTTP Upgrade).
With this in mind I have started working on a series of patches[1] to
implement this, that I am hoping will be ready to merge early next week.
(These patches are still a work in progress, but the core functionality
works).
For those of you who are not familiar with HTTP upgrade it is a
mechanism where a client makes a HTTP request to the client with the
Upgrade: header set, the server will then respond with a HTTP 101
response. In our implementation the server then hands the channel over
to JBoss Remoting which then performs its normal handshake, including
authentication.
The upshot of all this will be:
- We no longer have port 9999 open by default, which will break older
clients that attempt to talk to a default AS8 instance (it will still be
possible to add a native interface to allow it to work with older clients).
- ModelControllerClient.Factory.create() now allows you to specify a
protocol, which can be either remote, http or https.
- Remote JMX will now require a service:jmx:http(s)-remoting-jmx:// URL
rather than the current service:jmx:remoting-jmx://
I have not touched domain management yet, and these patches are not yet
ready for merging, but because this is a fairly big change I thought I
would get peoples thoughts before I finish it off and submit a PR.
Stuart
[1]
https://github.com/stuartwdouglas/xnio/compare/http-upgrade
https://github.com/stuartwdouglas/jboss-remoting/compare/http-upgrade
https://github.com/stuartwdouglas/remoting-jmx/compare/http-upgrade
https://github.com/stuartwdouglas/jboss-as/compare/http-upgrade
11 years
JBoss Java EE Spec APIs
by Shelly McGowan
In preparation for the first WildFly release (per the roadmap outlined by Jason a few weeks ago[1]), the EE APIs per the requirements of the EE 7 specifications have been updated and released. The compatibility signature tests have been run to verify their compliance with the tests I have available. I realize some specs are still in flux as we near the end game but wanted to let you know these have been published for use if/as needed.
For APIs that have dependencies on other APIs, I've also updated those and rereleased (e.g., JSP 2.2, JSTL 1.2, JACC 1.4).
I've also committed changes for the Java EE 7 full and web profile BOMs[2]. I have not done releases of these yet but can if there is a demand for them. Let me know.
Shelly McGowan
JBoss, by Red Hat
[1]http://lists.jboss.org/pipermail/jboss-as7-dev/2013-March/007884.html
[2]https://github.com/jboss/jboss-javaee-specs/commits/master
11 years
dmr.js
by Heiko Braun
If you want to use the DMR API form plain JS and need all the typing build in, the dmr.js might be your friend:
https://github.com/hal/dmr.js
Regards, Heiko
11 years
IMPORTANT - JBoss AS GitHub Repo Change
by Jason Greene
Hello Everyone,
We have finished the github conversion of github.com/jbossas/jboss-as -> github.com/wildfly/wildfly.
Please use this location for all purposes from now on.
Follow these steps to update your repo:
1. Create a new github fork of the above wildfly repo
2. In your local checkout execute the following commands (assuming you have an origin pointing to your fork and an upstream pointing to the above repo):
git remote set-url origin git@github.com:[username]/wildfly.git
git remote set-url upstream git://github.com/wildfly/wildfly.git
3. After these steps you can rename your jboss-as directory to wildfly (optional)
I have also left a stale clone which contains all old tags.
--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat
11 years
M1 of the Camel Subsystem available
by Thomas Diesler
Hi Folks,
I'm happy to announce that the initial Camel subsystem is now available.
cheers
--thomas
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
11 years
jboss-as -> wildfly Repo Move Happening Soon
by Jason Greene
I just wanted to give everyone a heads up that we will soon be moving and renaming the JBoss AS community github repo.
The current location here:
git://github.com/jbossas/jboss-as.git
will be renamed to
git://github.com/wildfly/wildfly.git
In addition a number of the sub project repos in the jbossas org will also be moved.
Unfortunately github does not offer redirects, but we plan to leave an old repository with a README file to indicate the new location.
--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat
11 years
