Your issue is: where to put link between authentication and the backend? Lazy realm answer is: in the app.
Spec answer is: nothing. Your proposal is: in between/in both. Implementing a custom realm: in the container Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber <http://www.tomitribe.com> 2015-03-13 20:04 GMT+01:00 Darjan Oblak <[email protected]>: > That would be an easy solution to the current problem. But what worries me > is that it doesn't seem to be portable to other containers. I still can't > see what advantage does using a lazy/cusotm realm really offer compared to > hashing the password prior request.login call? > > On Fri, Mar 13, 2015 at 3:13 PM, Romain Manni-Bucau <[email protected] > > > wrote: > > > Hi > > > > Sounds you want just a lazy realm > > > > > https://rmannibucau.wordpress.com/2012/08/27/tomee-put-your-realm-in-your-webapp/ > > Le 13 mars 2015 13:58, "Darjan Oblak" <[email protected]> a écrit : > > > > > We use TomEE 1.7.1, our app authentication scheme basically looks like > > > this: > > > > > > * FORM based login is used > > > * since the login procedure differs for different customers we omitted > > the > > > idea of introducing multiple realms and combining them as it would be > too > > > complex (for some only database is used, some use LDAP, others combine > > one > > > of those with 2FA auth) > > > * currently SHA-256 password hashes are stored in DB > > > * handling all the required checks is already done within our custom > > > authentication bean (DB/LDAP querying and authentication checks, > DB/LDAP, > > > 2FA, lock-out on multiple fails, password changing on first login for > > user > > > etc.) > > > * once the user passes the complete authentication check within our > > > authentication bean, request.login(username, password) is called and > > > container login is performed against database using JDBCRealm with > > SHA-256 > > > digest, authenticated session is set in the container and user can > begin > > > using the application > > > > > > Now two questions: > > > 1. Assuming our authentication bean logic has no bugs, did we overlook > > any > > > core aspect of the container based security and is such approach anyhow > > > flawed? > > > 2. We would like to use scrypt password hashing since SHA-256 lacks > > salting > > > and has other drawbacks. We can easily switch to scrypt hashing > function > > in > > > our authentication bean, but the container doesn't support PBKDF2, > bcrypt > > > or scrypt. So since we already have all checks done in our bean and we > > only > > > use container based autentication for session management, would it be > > wrong > > > to just change JDBCRealm to use digest="NONE" and then call > > > request.login(username, getScryptHash(password)), so the password in > > hashed > > > form is passed to container login where no additional hashing is done. > > > > > > Thank you, > > > Regards, > > > Darjan > > > > > >
