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

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.