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

Thu Sep 22 17:46:15 EDT 2011

I'm going to put on my Bill hat here and say, "JSR 196 is crap".

I've been saying this exact thing for over a year now.  And the response 
has ever been "we'll have a call, we'll talk about it, we'll gather 
requirements, let's write an agenda, get some minutes, talk talk talk talk".

Let's have some action.

On 09/22/2011 04:38 PM, Anil Saldhana wrote:
> 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<bburke at redhat.com>  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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

-- 
- DML