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
Fwd: jboss-el-api_2.2_spec APIs and Wildfly
by Shelly McGowan
On a related note to this discussion about EL 3.0 APIs:
http://lists.jboss.org/pipermail/jboss-as7-dev/2013-July/008179.html
See below a previous exchange on an attempt to remove EL 2.2 API dependency from WildFly.
Shelly McGowan
JBoss, by Red Hat
> ----- Forwarded Message -----
> From: "Stuart Douglas" <sdouglas(a)redhat.com>
> To: "Shelly McGowan" <smcgowan(a)redhat.com>
> Cc: "Remy Maucherat" <rmaucher(a)redhat.com>
> Sent: Thursday, July 18, 2013 1:00:15 AM
> Subject: Re: jboss-el-api_2.2_spec APIs
>
> I created this class to address a fairly major EL performance issue (that factory finder is invoked on every EL invocation, and it is both slow and acquires locks, which cause lots of contention).
>
> We may need to do a similar performance fix in the org.glassfish EL module, but I am not really sure. Assuming the problem still exists and we remove this fix our JSF performance will drop considerably.
>
> Stuart
>
> ----- Original Message -----
>> From: "Shelly McGowan" <smcgowan(a)redhat.com>
>> To: "Remy Maucherat" <rmaucher(a)redhat.com>
>> Cc: "Stuart Douglas" <sdouglas(a)redhat.com>
>> Sent: Thursday, 18 July, 2013 9:45:01 AM
>> Subject: jboss-el-api_2.2_spec APIs
>>
>>
>>
>> Remy,
>>
>> Currently in WildFly we are using the org.glassfish:javax.el dependency for
>> EL 3.0 APIs and implementation.
>> I'm assuming the plan is to keep this in for at least WildFly 8.0.0.Final
>> releases (and EE 7 certification) due to Beta1 only a few weeks away.
>>
>> I was working on a pull request to remove the EL 2.2 APIs from WildFly and
>> found out I was unable to do that due to a dependency
>> from both the web module and the undertow module on:
>> org.jboss.el.cache.FactoryFinderCache specifically in:
>> undertow/src/main/java/org/wildfly/extension/undertow/deployment/ELExpressionFactoryProcessor.java
>> web/src/main/java/org/jboss/as/web/deployment/ELExpressionFactoryProcessor.java
>>
>> This class is included in the jboss-el-api Specs project API .jar but
>> obviously not part of org.glassfish:javax.el.
>>
>> How do you want to handle this moving forward? For tests purposes, I created
>> an org.wildfly.el module to include only this class as you can see on this
>> branch:
>> https://github.com/smcgowan/wildfly/commit/3c511ea2e74a22215f02d69ff0d07d...
>>
>> [NOTE: there are a couple of unrelated changes in that branch]
>>
>>
>> This work was prompted by some signature test failures I was seeing in TCK.
>> The EL 2.2 APIs being in the distribution were unrelated.
>>
>>
>> Shelly McGowan
>> JBoss, by Red Hat
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
AS7 7.1.3 - CLI Operations when working on Domain mode & JNDI issue
by George Vagenas
Hi guys,
For the Mobicent SIP Servlet project that is build on top of AS7, we have
some CLI operations to list available SIP Servlet application, to gracefuly
stop the context and the server. These operations work fine when the server
runs in standalone mode using the command:
/subsystem=sip:listSipAppplications
But when running in domain mode the command should be (sip subsystem
belongs to the default profile) :
/profile=default/subsystem=sip:listSipAppplications
But then we get an NPE because the context that the operation executes is
not a normal server:
@Override
public void execute(OperationContext context, ModelNode operation)
throws OperationFailedException {
ModelNode result = context.getResult();
result.get("AppName").setEmptyList();
if(context.isNormalServer()){
SipApplicationDispatcher sipApplicationDispatcher =
StaticServiceHolder.sipStandardService.getSipApplicationDispatcher();
Iterator<SipContext> sipApps =
sipApplicationDispatcher.findSipApplications();
while(sipApps.hasNext()){
result.get("AppName").add(sipApps.next().getApplicationName());
}
} else {
throw new OperationFailedException(new ModelNode().set("Operation
available only a Server"));
}
context.completeStep();
}
Is there a way we can specify a server node that the operation should
execute?
Also, in standalone mode, we gracefuly shutdown the server and the contexts
running using the following:
protected void shutdownServer() throws MalformedObjectNameException,
NullPointerException, InstanceNotFoundException, MBeanException,
ReflectionException, IOException{
MBeanServerConnection mbeanServerConnection =
ManagementFactory.getPlatformMBeanServer();
ObjectName mbeanName = new ObjectName("jboss.as:management-root=server");
Object[] args = {false};
String[] sigs = {"java.lang.Boolean"};
mbeanServerConnection.invoke(mbeanName, "shutdown", args, sigs);
}
And this one fails when server runs in domain mode.
Any ideas?
Thanks
George
10 years, 9 months
