[jboss-as7-dev] security/web sucks, what can we change?

[Bill Burke]

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