Can we please have a notification scheme enabling for the Undertow Jira
project so that we can receive e-mail notifications.
I would suggest just use the same one as is used for Remoting JMX, it
should be sufficient to have the notifications go to the general mailing
list and interested individuals.
Is there a web-site for Undertow? Any documentation or examples?
I'm hoping to start migrating Resteasy's OAuth work so that it works
with Undertow. I don't know whether or not it will require undertow
security API changes or not. I'll post some initial
requirements/how-we-do-it-now stuff below.
1. Support for multiple simultaneous auth protocols for one web-app. Any
servlet auth + oauth + bearer-token.
2. Ability to introspect principal and role mapping from underlying
"domain". We create a smart token from this information. With
JBossWeb, we hacked this information from the Principal passed back from
the security layer.
3. Ability to add additional action URLs to the web-app without
additional user configuration. With JBossWeb, we handled all these URLs
within a valve.
4. Ability to create both principal and role mappings on the fly from an
incoming request's bearer token.
5. Ability to obtain any client certificates so that they can be
verified. Verification only. For this I want to be able to verify the
client that is acting on behalf of a user. So the calling client's
certificates may not be the same identity of the actual user.
6. Ability to store state in-between requests. This isn't a session as
it will be two different clients that need to share data. in OAuth,
there's the User Agent that establishes an access code for the web-app.
The web-app makes a separate HTTP request to verify the access code
and turn it into a token.
7. Ability to log out any requested user. Our current implementation
has an admin interface that can log out a user on *every* app they are
That's all I can think of now. So, Undertow needs to provide these
capabilities within their security API, *OR*, it requires a Valve
architecture that can override any current built-in auth infrastructure,
but at the same time, have access to the "domain" and be able to
authenticate and introspect principal and role mappings.
JBoss, a division of Red Hat
A few weeks ago on jboss-as7-dev, Undertow compatibility with Tomcat
valves and -D options was briefly mentioned. Direct compatibility is a
different topic, but I think it is important to make sure that Undertow
can cover the reasons people are using some of those Tomcat options.
I've done some analysis on the JBoss support cases Red Hat deals with
and our knowledge base, and had a bit of a look over the community
forums. I looked at the forums less since it's less structured data but
what people mention there seems consistent with the the RH support cases.
I'm sorry this post is as long as it is, but hopefully what I've found
will help make sure we think about some cases people may run into using
Undertow, and remind us of a few lessons to learn from previous
The most common valves we see people add are the RewriteValve,
RequestDumperValve and AccessLogValve. UNDERTOW-12 and UNDERTOW-17 are
already filed for equivalents to the first two. I can't see any code or
open JIRA issues for access logging, which I imagine people will want.
The most commonly used Tomcat -D option is
org.apache.catalina.STRICT_SERVLET_COMPLIANCE=false. When it's
discussed, it always seems to be added for the effect of not enforcing
"any wrapped request or response object passed to an application
dispatcher will be checked to ensure that it has wrapped the original
request or response. (SRV.8.2 / SRV.188.8.131.52)". Undertow enforces that
A quick search for "ApplicationDispatcher.checkSameObjects" shows people
running into this all over the place. Including
https://issues.jboss.org/browse/RESTEASY-745 (which has a work-around).
Unfortunately a reasonable number of libraries have had or still have
bugs where their wrappers don't derive from the spec one, and it only
break when someone tries to pass it to the dispatcher.
There are a few uses of
org.apache.tomcat.util.http.Parameters.MAX_COUNT, that adjusts the
arbitrary limit on the parameter count which was added to prevent DoS
attacks using hash collisions. Looking at the code, there appear to be
several places where Undertow could suffer similar DoS attacks where
client data is used as HashMap keys: CookieHandler,
HttpServletRequestImpl.getParameterMap() and so on.
Two important things here: what protection does/will Undertow have
against those attacks (such as a limit on the number of parameters, and
is there a way of changing the arbitrary limit. It's not the best idea
to do that, but I've seen at least two people saying they have >2000
hidden parameters in some of their forms.
There are a few options that get used a bit for session cookies. You can
change the cookie name from JSESSIONID on a per-webapp basis, but Tomcat
has a org.apache.catalina.JSESSIONID option to set it globally. This is
probably more of a WildFly integration thing, but is there a plan to
allow it to be changed globally?
org.apache.tomcat.util.http.ServerCookie.ALLOW_EQUALS_IN_VALUE is used
occasionally to allow un-escaped equals signs in the cookie value.
org.apache.tomcat.util.http.ServerCookie.VERSION_SWITCH=false is used
occasionally to not switch v0 cookies to v1 cookies, to deal with some
broken clients. See JBWEB-196.
used primarily in WebLogic migrations. See JBWEB-181, but apparently
when encodeRedirectURL() adds the sessionId to the url, WL will do that
for URLs belonging to other contexts. I'm not sure if this is still
By default Tomcat un-escapes %2F in a URL to / to prevent security flaws
by something incorrectly doing it later.
org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH can be used to
disable that, for example if you want to put %2F inside a path component
of a REST service. Should Undertow to the same automatic un-escaping,
and if so have a way not to do it?
The final option that I've seen used a non-trivial number of times is
org.apache.jasper.runtime.BodyContentImpl.LIMIT_BUFFER. Jasper has
re-sizable buffers which are pooled for performance but may need to grow
arbitrarily large to render some JSPs. By default the enlarged buffers
are kept in the pool like normal ones, which means a bad JSP render
consuming hundreds of mb will not free the extra memory when it
finishes. This option causes it to shrink the buffers back down after
they're finished being used. The moral for Undertow here is if you have
resizable buffers and they get pooled, make sure the is a limit.
James "Doc" Livingston
JBoss Support Engineering Group
I have been saying for a while that I need to raise a discussion
regarding the verification of Digest based requests against an
At the moment this is predominantly needed for Undertow although there
is also a need for same with SASL.
The following document describes the proposed use of the Undertow
IdentityManager API and the requirement for the implementation i.e. what
we would need from PicketLink IDM once wrapped in the WildFly integration: -
The three methods on the IdentityManager interface previously used for
Digest based authentication will all be removed.
An identity manager that can provide this capability will also be
compatible with SASL based authentication without needing to be aware of
the actual verification requirements within SASL.
I am trying to figure out how to set up the authentication mechanisms
in undertow. If I write an authentication mechanism involving saml, how
do I make the web apps using that mechanism.
Any links to test cases.