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

[Scott Stark]

There is also a new identity jsr for updating the java ee/se security apis:
http://jcp.org/en/jsr/detail?id=351

On 9/22/11 4:38 PM, Anil Saldhana wrote:
> Detailed Response here:-
>
> On 09/22/2011 04:23 PM, Bill Burke 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?
>>
> Security domain is just an abstract concept to pool in together
> authentication/authorization/mapping/audit mechanisms etc. There is no
> coupling to passwords.
>
>> 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.
> This is a variant of "Knowledge based authentication" which gives an
> additional layer of security rather than an additional factor of
> authentication.
>
>> - 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.
>>
> Just write a Tomcat authenticator.  You don't have to go through the
> context/realm or any of the heartburning issues you have.
>
>> 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.
>>
> Please influence the PicketLink IDM project. That is where the security
> store api needs to be refined to your needs.
>
>> #2  Deprecate JAAS and write our own SPIs/APIs.
>>
> Agree on this.  JAAS is cumbersome for developers.
>> #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.
> You came back to the security domain/realm abstraction.
>> #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.
> I mentioned about writing your own authenticator. You can use that to
> short circuit the JBoss Web security infrastructure.
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev