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, 11 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
11 years, 11 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
11 years, 11 months
wildfly-master-testsuite-ip6 - Build # 7311 - Failure!
by ci-builds＠redhat.com
wildfly-master-testsuite-ip6 - Build # 7311 - Failure:
Check console output at to view the results.
Public: http://hudson.jboss.org/hudson/job/wildfly-master-testsuite-ip6/7311
Internal: http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/wildfly-master-tes...
Test summary:
9 tests failed.
FAILED: org.jboss.as.arquillian.container.embedded.CdiTestCase.org.jboss.as.arquillian.container.embedded.CdiTestCase
Error Message:
jbossHome 'target/jbossas' must exist
FAILED: org.jboss.as.arquillian.container.domain.managed.test.ManagedDomainTestCase.org.jboss.as.arquillian.container.domain.managed.test.ManagedDomainTestCase
Error Message:
jbossHome '/home/jenkins/jenkins-work/workspace/wildfly-master-testsuite-ip6/arquillian/container-managed-domain/target/jbossas' must exist
FAILED: org.jboss.as.arquillian.container.domain.managed.test.ManagedDomainTwoTestCase.org.jboss.as.arquillian.container.domain.managed.test.ManagedDomainTwoTestCase
Error Message:
Arquillian has previously been attempted initialized, but failed. See cause for previous exception
FAILED: org.jboss.as.arquillian.container.managed.InjectJndiContextTestCase.org.jboss.as.arquillian.container.managed.InjectJndiContextTestCase
Error Message:
Arquillian has previously been attempted initialized, but failed. See cause for previous exception
FAILED: org.jboss.as.arquillian.container.managed.InjectManagementClientTestCase.org.jboss.as.arquillian.container.managed.InjectManagementClientTestCase
Error Message:
Arquillian has previously been attempted initialized, but failed. See cause for previous exception
FAILED: org.jboss.as.arquillian.container.managed.IntegrationTestCase.org.jboss.as.arquillian.container.managed.IntegrationTestCase
Error Message:
Arquillian has previously been attempted initialized, but failed. See cause for previous exception
FAILED: org.jboss.as.arquillian.container.managed.ManagedAsClientEnterpriseArchiveServletTestCase.org.jboss.as.arquillian.container.managed.ManagedAsClientEnterpriseArchiveServletTestCase
Error Message:
Arquillian has previously been attempted initialized, but failed. See cause for previous exception
FAILED: org.jboss.as.arquillian.container.managed.ManagedAsClientWebArchiveServletTestCase.org.jboss.as.arquillian.container.managed.ManagedAsClientWebArchiveServletTestCase
Error Message:
Arquillian has previously been attempted initialized, but failed. See cause for previous exception
FAILED: org.jboss.as.arquillian.container.managed.ManagedInContainerTestCase.org.jboss.as.arquillian.container.managed.ManagedInContainerTestCase
Error Message:
jbossHome 'target/jbossas' must exist
12 years, 1 month
byteman
by Ravi Gupta
I am having trouble using byteman, the rule seems to load, but simply won't
fire
AS7 startup log
17:08:31,523 INFO [org.jboss.ws.common.management.AbstractServerConfig]
(MSC service thread 1-5) JBoss Web Services - Stack CXF Server
4.0.4.GA-redhat-1
17:08:31,638 INFO [org.apache.coyote.http11.Http11Protocol] (MSC service
thread 1-3) Starting Coyote HTTP/1.1 on http-/127.0.0.1:8080
17:08:31,785 INFO [stdout] (MSC service thread 1-5)
org.jboss.byteman.agent.Transformer : possible trigger for rule Set
URLDelimiter in class
org.jboss.jca.adapters.jdbc.xa.XAManagedConnectionFactory
17:08:31,812 INFO [stdout] (MSC service thread 1-5)
RuleTriggerMethodAdapter.injectTriggerPoint : inserting trigger into
org.jboss.jca.adapters.jdbc.xa.XAManagedConnectionFactory.initSelector()
void for rule Set URLDelimiter
17:08:31,833 INFO [stdout] (MSC service thread 1-5)
org.jboss.byteman.agent.Transformer : inserted trigger for Set URLDelimiter
in class org.jboss.jca.adapters.jdbc.xa.XAManagedConnectionFactory
test1.btm (rule)
RULE Set URLDelimiter
CLASS org.jboss.jca.adapters.jdbc.xa.XAManagedConnectionFactory
METHOD initSelector
AT ENTRY
IF true
DO traceln("************************************************")
ENDRULE
When I configure and test a XA datasource, nothing gets printed?
Regards
12 years, 1 month
jboss-as-7.1.0.Final Stack Trace not being logged from SLF4J
by Stein, Eric
I'm not sure if this is the right list for this question, so please redirect me if I chose this one in error.
I'm having very little sucess getting JBoss to correctly log the stack trace of my error messages. Our application uses SLF4J , which is in our WAR file (slf4j-api-1.7.5.jar). This prints stack trace:
LOGGER.error("Something blew up", e);
This does not print stack trace:
final String verb = "blew";
LOGGER.error("Something {} up", verb, e);
What is going on? How do I get JBoss to work correctly with SLF4J?
Thanks,
Eric Stein
standalone.xml:
<subsystem xmlns="urn:jboss:domain:logging:1.1">
<console-handler name="CONSOLE">
<level name="DEBUG"/>
<formatter>
<pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
</formatter>
</console-handler>
<periodic-rotating-file-handler name="FILE">
<formatter>
<pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
</formatter>
<file relative-to="jboss.server.log.dir" path="server.log"/>
<suffix value=".yyyy-MM-dd"/>
<append value="true"/>
</periodic-rotating-file-handler>
<logger category="com.arjuna">
<level name="WARN"/>
</logger>
<logger category="org.apache.tomcat.util.modeler">
<level name="WARN"/>
</logger>
<logger category="sun.rmi">
<level name="WARN"/>
</logger>
<logger category="jacorb">
<level name="WARN"/>
</logger>
<logger category="jacorb.config">
<level name="WARN"/>
</logger>
<logger category="org.jboss.resteasy">
<level name="ALL"/>
</logger>
<logger category="com.mycompany">
<level name="ALL"/>
</logger>
<root-logger>
<level name="WARN"/>
<handlers>
<handler name="CONSOLE"/>
<handler name="FILE"/>
</handlers>
</root-logger>
</subsystem>
12 years, 1 month
