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
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
Undeploy due to server shutdown vs. explicit undeploy operation
by Thomas Diesler
Folks,
an explicit undeploy operation should remove state that otherwise needs
to survive server restart.
How can I distinguish between these two cases in a DUP?
cheers
--thomas
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
11 years
Notification of shutdown commencing
by Brian Stansberry
I can't figure out a way to produce a notification of an impending
server shutdown if a user does a soft kill of the server process.
It's easy enough if shutdown is initiated by a management op; the op
handler can trigger the notification. But a soft kill triggers a
shutdown hook registered by the MSC ServiceContainer, and once that
starts, services start stopping semi-randomly and its too late to notify
anyone that that is going to start happening.
The MSC shutdown stuff isn't exposed, so there's no way to tie into
that. Adding another shutdown hook doesn't help as there's no
predictable order of execution.
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
11 years
Community AS8 Roadmap Proposal
by Jason Greene
Hello Everyone,
I am happy to announce a proposed roadmap for AS8. After some discussions with various AS developers and community members, the goals we think are important are:
1. Java EE7
2. Integration of Undertow (EE7 Web Sockets + performant non-blocking i/o)
3. Patching
4. Migration from JacORB to the JDK Orb
5. Transition to the new yet to be announced name
I am proposing an agressive 6 month timeline for this release, with the following key milestones:
May 7 - Release Alpha1
+ Includes undertow, some ee7
June 11 - Release Beta
+ more progress on EE7
July 11 - Release CR1
+ EE7 feature complete
July 25 - Release CR2 if needed
(Hopefully TCK 100% by this date)
August 8 - Release Final
As usual the August 8th date is conditional on the Java EE certification process.
I look forward to any and all feedback. Thanks!
--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat
11 years
Unit test failure / regression for remoting
by Rob Stryker
Hi All:
We have a few unit tests which interact with the app servers to see if
and when you guys break stuff ;) And.... we found one.
Tools currently uses the as7.1 jars, which in general communicate quite
nicely with as7.0.x through eap6.1. However, there is a problem. One
specific test fails against eap6.1 (and therefore i assume as7.2). It
has to do with getting the futures from a ModelControllerClient command.
The thread locks up, and nothing can proceed.
I've tried updating our client jars to those in eap6.1, and it also
mostly works... mostly... except the same unit test fails when run
against as7.0.0.
So to summarize, as7.1.0 jars work 95% correctly against all versions,
but fail when getting futures against eap6.1. Eap6.1 jars work 95% of
the time, but fail when getting futures against as7.0.0.
Tools needs to have one set of jars in general which work with
everything, if possible. So, the most reasonable solution is to fix the
bug in as7.2 / eap6.1 which fails against as7.0.0 if at all possible.
If it's not possible, well, tools will have to make a decision on
whether to do a costly workaround or remove support for AS 7.0.0 in
eclipse entirely. This would take time to research the extent of the
risk of eclipse locking up all the time, and it might involve expertise
we don't have.
So *I* think, it'd be cool if the bug had someone look at it sometime
EARLY next week, if at all possible ;)
Max is taking a no-holds-barred approach in assigning blame here, and
though he's a smiley-viking, he's a viking nonetheless. I'd tiptoe
around him unless you're willing to help find a solution ;)
Link to bug in question: https://issues.jboss.org/browse/AS7-6779
Anyway, it'd be really really great if someone could look at this,
because it does have the potential to lock up eclipse, leave stalled
jobs and workers, etc.
Thanks.
- Rob Stryker
I break things, but I didn't break this.
11 years, 1 month
