[jboss-as7-dev] security APIs/SPIs really need a redesign

[Bill Burke]

I'll try to write a blog about this too, but, the security APIs/SPIs 
really need a rethink.  Originally, the whole security-domain concept, 
and Tomcat Realm centered around passwords or an X509Certificate (for 
client cert).  Passwords alone basically suck for security.  We use a 
soft or hard token for our VPN, why wouldn't we use something similar 
for JBoss-deployed applications?

There's all different kinds of information that needs to be stored in a 
security-domain now:

- passwords
- hashed passwords
- secret-keys (for TOTP, soft-tokens)
- remembering nonces (Digest and OAuth come to mind hear)
- remember request and access tokens (Think OAuth)
- URLs (Think OpenID)
- KeyPairs when you're dealing with digital signatures or client 
certificate authentication
- JPG images.  Think of Bank of America that shows you a secret image 
when you log in so that you know somebody isn't spoofing their site.
- Client IP addresses for when you want to tie a user to a client IP

Our legacy APIs/SPIs worked nicely because, since everything was 
password based, the Security-Domain could also do authentication. 
Extract the username/password from the HTTP request (or remote EJB 
request) and just check it vs. the password storage.  Now though, 
there's a growing set of protocols that need access to the HTTP request 
itself, especially if the request is digitally signed in some manner, 
and the line between the protocol and security-domain starts to really blur.

Another huge problem with our security SPIs is that LoginModules are 
stateless.  There's really no way, other than hacks, to point it at 
specific storage so it can do things like:  remember nonces, temporary 
secrets or certificates, previous IP address connections.

Yet another that I think may come up is dual-authentication mechanisms 
for the same resources (URLs).  A regular user may query the site via 
traditional authentication vs. a 3rd party consumer which uses OAuth. 
With our current WAR/web.xml model, you can only use one or the other.

The final problem I'm currently seeing is that its hard to re-use the 
storage capabilities of our security plugins (.properites, ldap, JDBC, 
etc.).  What you currently have is a mish-mash of weird, hard-to extend 
class hierarchies with no clear line between storage of information and 
the algorithm being used and the process of authentication and 
authorization.  If we're going to support more complex models, we need 
to create better SPIs here.

So what to do?

#1 I suggest defining a Security Storage SPI.  Something that is 
key/value/values based that is listable. i.e. something like:

interface SecurityStore {

    public Object get(String key);
    public List<Object> list(String key);
    public void put(String key, Object value);
    public void put(String key, List<Object> value);

}

A key would look like a URL i.e.:

/users
/users/bill
/users/bill/private-key
/users/bill/public-key
/users/bill/password
/users/bill/totp-key
/applications/myapp
/applications/myapp/roles
/applications/myapp/roles/admin
/applications/myapp/roles/admin/users
/applications/myapp/roles/admin/users/bill

The the security store could be mapped to a properties file, XML file, 
LDAP storage, JDBC, etc.

Whether or not we use an existing thing here i.e. Infinispan, JCR, or 
whatever is irrelevant, but we need a simple generic storage mechanism 
to give ultimate flexibility to security extension developers.  Some 
suggestions on what to use for this mechanism would be greatly appreciated.

#2  Deprecate JAAS and write our own SPIs/APIs.

#3 Decide where authentication happens.  Does it happen within a Tomcat 
Valve and persistent security information queried directly from the 
SecurityStore?  Do we have a Security domain and delegate to it for 
authentication? (In this case, the Security-Domain would need access to 
the request object).  I think I prefer a full delegation to a 
SecurityDomain as storage, the authentication mechanism, and 
configuration of the authentication mechanism pretty much go hand in hand.

#4 We need to make it fairly easy to develop security extensions.

#5 Try to support legacy deployment options with the new model.

#6 Going along with #3, I really like the idea of adding a <auth-method> 
of JBOSS, or JBOSS-SECURITY-DOMAIN, so that authentication is handling 
fully by a JBoss subsystem.






-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com