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
9 years, 2 months
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
9 years, 5 months
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
9 years, 5 months
JTA Synchronization.afterCompletion callback can occur in a background thread but JPA EntityManager must be accessed in single-threaded manner...
by Scott Marlow
Related jira issues are HHH-7910 + AS7-6586. HHH-7910 has been around a
bit longer and contains comments about the current plan to address the
issue in Hibernate.
As mentioned in HHH-7910, the JTA specification allows
Sychronization.afterCompletion callbacks to occur in a different thread
than the application thread that is using the transaction (typically for
transaction timeout or when a transaction is propagated to a remote thread).
Since the JPA EntityManager is by design, not thread safe, invoking the
EntityManager.clear() or EntityManager.close() methods from a background
thread while the application thread may be in the middle of an
EntityManager invocation is not the best situation (IMO).
One improvement that we talked to the JBossTM/TS team about, is adding a
TM policy that arranges for the Synchronization.afterCompletion to
always run in the application thread (some of the IRC discussion is
attached to HHH-7910). The TM team doesn't think that they could do
that for both the TX timeout and tx propagating to a remote thread
(JBossTS) uses.
One alternative solution, might be to create a top level container level
queue that the background thread Synchronization.afterCompletion defers
processing to. As soon as the application thread returns control to the
top level, the queue is processed in FIFO order.
*Does AS have any other uses of Synchronization.afterCompletion or
Synchronization.beforeCompletion that expect to run in the application
thread*?
From the JPA specification about thread unsafety:
"
An entity manager must not be shared among multiple concurrently
executing threads, as the entity manager and persistence context are not
required to be threadsafe. Entity managers must only be accessed in a
single-threaded manner.
"
9 years, 6 months
Add Notification support to the domain management API
by Jeff Mesnil
I've started to work on [AS7-370] Add Notification support to the domain management API[1].
To make sure we agree on the content and scope of this task, I've created a doc on our dev forum summarizing what I intend to do (and not do) about this[2].
It's a simple draft but I'd appreciate any feedback on this.
I'm particularly interested by the use cases what would benefit from such notifications (Web Console, auditing, others…) to make sure they'd be covered by the requirements.
I'm trying to keep this as simple as possible for subsystems to leverage notifications without too much involvement while making sure there are no performance or memory penalty for the AS7 to handle them.
jeff
[1] https://issues.jboss.org/browse/AS7-370
[2] https://community.jboss.org/wiki/AddNotificationSupportToTheDomainManagem...
--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/
9 years, 6 months
Subsystem model version for AS8
by Tomaž Cerar
Hi,
I remember few discussions on IRC in last weeks(s) about how to handle
version bumps for subsystem model when changes are done on AS8 codebase.
It was somewhat agreed that instead of bumping minor version we should
upgrade major version.
aka instead of doing 1.2 --> 1.3, new version should be 2.0
That gives us flexibility of bumping minor version to 7.x codebase if need
arises.
I am writing this as there was some PRs lately that bump just minor version.
So, can we get an agreement of new versioning rules, that we will then
follow.
I personalty favor major version bumps...
--
tomaz
9 years, 6 months
Removing JAXR & backward compatiblity
by Thomas Diesler
Folks,
related to
* [AS7-6612] Remove JAXR support
I'd like to know whether we need to preserve backward compatibility of the configuration and if so what should happen if there is a jaxr config item? Generally, can AS8 break backward compatibility with respect to the config?
cheers
--thomas
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
9 years, 7 months
Security manager test runs
by David M. Lloyd
The AS codebase now supports running under a security manager. Well,
sort of. There are a few places where we need privileged blocks and/or
permission checks, but you can boot up AS under a security manager today
if you want. Just follow these steps:
1. Modify standalone.sh so that the -secmgr flag is passed in to JBoss
Modules.
Well, I guess there's just the one step. Anyway I've noticed that the
impact on startup time is not as bad as I had expected, which is good.
So the question is: Should we set up a security manager-enabled test
run? How should it work?
--
- DML
9 years, 7 months
cant get rid of jetty maven plugin - so lets mavenize JBoss Modules
by Bill Burke
JBoss AS and jboss-as-maven-plugin just doesn't meet my needs, so I've
started the process of fixing it. I have some initial code, but I need
to know that my suggestions and pull-requests will be accepted before I
proceed with the rest of the changes I would need to make.
What missing or very hard to do:
* Jetty maven plugin is great because there is no pre-installation
needed. It builds your war, automatically downloads jetty and runs it
in embedded mode, then runs your tests (if you have maven pom configured
right). I'd like to replace this with JBoss AS....But...it is just not
feasible. jboss-as-maven-plugin does download the AS7 ZIP artifact if
jboss isn't running already, but...it unzips the zip into every maven
projects target/ directory. FOR EVERY PROJECT. So, if you have more
than one test, you are unzipping 100M+ PER PROJECT. This is just
unworkable.
* I need the above for my O'Reilly Restful Java book examples.
Currently I use Jetty and I can't replace with jboss-as-maven-plugin. I
refuse to require download/install of jboss and will just stick to jetty
if I must.
* If you are developing on a subsystem integration on AS codebase, as
you build your submodule, you need to either rebuild the distribution,
or copy the library to the built JBoss distribution. Its just a pain.
I'd like to remove this step and streamline integration module development.
* I'd like to have automated AS integration tests in the Resteasy build.
This sucks because of the previous problems. Not only is an unzip of
AS required per maven project, but I need to override resteasy speific
AS modules with the current resteasy build.
* You can't distribute a profile of a complete jboss install without
distributing *EVERY* jar it depends on.
What I'm doing to fix it:
* I've got a pull request for JBoss Modules that allows you to specific
a maven repository artifact instead of a path for a resource-root: i.e.
<resources>
<resource-root group="org.jboss.resteasy"
artifact="resteasy-jaxrs" version="3.0-beta-4"/>
<resource-root group="org.jboss.resteasy"
artifact="resteasy-client" version="3.0-beta-4"/>
</resources>
Looks in the local maven repository for the artifact, if not there,
barfs unless you've pointed a system property to a remote maven
repository. Then it will download the artifact with a nice updated
download-progress message displayed on the console window.
Here's my pull request:
https://github.com/jbossas/jboss-modules/pull/28
* I'd like to change the JBoss AS distribution to use this new
jboss-modules maven artifact feature. This requires modifying
module.xml creation as well as creating and distributing a local maven
repository with the jars needed.
* Besides the modified distro, I'd like a new maven artifact that is
just a zip of the JBoss AS directory structure and the corresponding
configuration files. No jars.
* I want to rev jboss-as-maven-plugin to take advantage of these new
features and distros. Specifically:
- Allow a src/jboss directory so that users can provide their own config
files that are overlayed on top of the config-only AS distro.
- Make config-only AS distro something you can reference as an artifact
dependency
- provide in-pom support for defining new and override modules.
I hope you can see that not only does this make development easier, but
it also opens the door define JBoss AS profiles that can easily be
exchanged and distributed.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
9 years, 7 months
