Hi Jeremy, can you elaborate more what does this Glassfish configuration do? This com.company.MyAuthenticRoastSAM is some custom authentication mechanism? After authentication is performed, then security-role-mapping mapping is performed?
If so, you can use predefined login modules  or write custom one. And use SimpleRoles mapping module. You register your login module for web application in jboss-web.xml .
Thanks, but that's not quite it. It's probably close though and pointing in the right general direction.
The Glassfish settings set up Authentication using a library built on the AuthenticRoast libraries (Google Code Archive - Long-term storage for Google Code Project Hosting.) It was used in a wide variety of configurations for a number of years, but the project appears to have gone dormant. It is JASPIC type approach.
In Glassfish the server is configured at the Message Security level to load their Authorization Module as authentication at the HttpServlet layer, then in the sun-web.xml file you specify the name of the class that you have implemented that inherited from their PluggableAuthenticator class. It will then take care of authenticating the user (in our case by checking a database based on username/password/GUID combinations) and set up the session, datasource, etc.
In Tomcat, it's pretty straight forward in setting up a Valve in context.xml, but while that was supported in AS7, Wildfly appears to be using Undertow with completely different ways of doing things.
Any suggestions are appreciated as the more I dig the more it looks like I'm going to need to write a Filter that wraps it all up, or else rewrite our authentication pieces.
Replacement for jboss-web (tomcat) valve mechanism in undertow are http handlers. See  for details.
When you say "and set up the session, datasource, etc. ". Does that mean you create database connection with user credentials? For database authentication you can use prepared Database Login module.
Thanks. While the page wasn't exactly what I needed, it led to other pages that were what I needed.
For what it's worth for others that come across this page and need an answer:
We had been using AuthenticRoast as our JASPIC compliant authentication piece. For Tomcat and for Glassfish, there are a couple of places where the specifications say "null or empty" and they accept null values, while WildFly dies hard on a Null Pointer Exception. Wildfly also requires a constructor which takes a string value for the JASPIC initialization. Fortunately AuthenticRoast is open source, so updating the code to meet the Wildfly requirements wasn't too tedious (create a constructor for AuthModule that takes a String, resolve null pointer exceptions when initialize called with null requestPolicy and responsePolicy doesn't blow up, and getSupportedMessageTypes returns an array of Class that contains Object.class instead of a null value).
After that, following the directions to set up JASPIC on Wildfly (found at Arjan Tijms' Weblog: Activating JASPIC in JBoss WildFly) and specifying the correct auth-module in the settings worked.
Thanks for the responses and the guidance.