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

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 _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev