I'm not happy with the state of our security abstractions. * For one, JBossWeb is stuck in Tomcat land and there are so many hacks to propagate configuration/service objects to the various valves and filters. * Tomcat Realm and JBoss Security Domain are stuck in user/password land. THere are a few protocols (i.e.SAML) that are not password driven, (and maybe not even username driven). If you want to hook in these protocols, you have to tunnel information through Threadlocals or the PrincipalContext. * There is no clear separation of concerns from Valve, Realm, and Security Domain. Security Domain was originally intended to be a user/password, user/role mapping. Some plugins are starting to bleed in protocol information. Valves set Tomcat specific principal information. JbossWebRealm bridges to the security domain and also sets JBoss specific principal information. * It is impossible to plug in a new Security Domain type at the moment. * It is impossible to plug in a custom auth-method. (Remy is wrong about not wanting to put this in.) * If you want to plug in your own protocol it is a mess to do it. If you look at picketlink, configuration is a combination of editing the security domain config, adding tomcat valve, adding filters to web.xml. So what do I want to do? Step 1: - Add ability to plug in a Security Domain type. Currently its all hardcoded. I don't see any mechanism in AS7 at the moment for plugging in IoC like information. I don't see mechanism for discovering config files or a place to put config files in AS7. This isn't a bad thing. I think what we could do is allow people to add a "org.jboss.security.DomainMapping" file to META-INF/services directory of any jar. When the Security Subsystem starts up it will search for all files of that name and load up a mapping file. - Add ability to define JBossWeb Authenticators. Tomcat/JBossWeb already has this ability inheritently built in, but unexposed. Similar to DomainMapping, we'll have a org.jboss.web.Authenticators file that has a class/auth-method mapping. I am already prototyping this stuff in my git branch. I'm pretty sure it can require zero changes to JBossWeb which should avoid getting Remy all flustered. Step 2: I'd like to gut JBossWeb security and Picketbox security. Redesign the whole damn thing. Its just hacked and band-aided together. Its stuck in ancient and obsolete user/password land needs to be more flexible. - I think it would be very interesting to allow the Security Domain to handle your authentication and authorization needs and have JBossWeb, EJB, etc, delegate to the SecurityDomain. Allow the security domain to view the HttpServletRequest, extract information, change the request, etc. With this type of model your admin could deploy a new authentication/authorization model onto an existing deployed application. For exmaple, an app might start with user/password, but later might convert the app to be TOTP/Soft/hard token based as they roll out hard/soft tokens to their user base. There would be a new auth-method named "JBOSS-SECURITY-DOMAIN". We'd need some serious discussion on this before moving forward. - Alternatively (and this is a must have without the above), the SecurityDomain needs to become a more generic store of information other than user/password user/role mappings. I writing some protocols that use public-keys and a valve would need to query the security domain for this key. A SAML valve may want to query the security domain for assertions. You get the idea. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com