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

Bill, will send a detailed response soon. We are going to have a call soon on cdi and developer focused security API. Let's club your remarks into that agenda. JSR 196 spec was written to give more control of the container authentication to modules. That gets away from the jaas limitations to a large extent. It is in ee6. Regards. On Sep 22, 2011, at 4:26 PM, Bill Burke&lt;bburke(a)redhat.com&gt; wrote: > 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 _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev