Caching is a great idea, except when a user's password changes. Of course, the problem could be worked around via business logic that could recheck the 'official' login info via the FTP session bean if the user's login fails. To do this, we definitely would have to incorporate JCE or some kind of encryption (as mentioned in the reply from Rolando)--we can't store people's network passwords in clear text--too much of a security risk. This is definitely a viable idea, if I can count on the encryption to the database to be somewhat secure.
Thanks for the idea...
-Jason
| "Keith L. Musser" <[EMAIL PROTECTED]>
11/09/2000 10:02 AM
|
To: jBoss <[EMAIL PROTECTED]> cc: Subject: Re: [jBoss-User] Security question |
Jason,
If performance is the concern, why not keep what you have, but cache the successes in a local database?
- Keith
-----Original Message-----
From: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Thursday, November 09, 2000 8:12 AM
Subject: [jBoss-User] Security question
Just looking for the experiences of others on the list...
How are you handling client authentication in your jBoss applications? I get the feeling that many developers on the list are using servlet/jsp/<insert-web-technology-here> front-ends to their ejb applications. I work in a corporation where NT authentication is pretty standard (i.e., everyone will have an NT logon id and password), and JNDI is not implemented. From what I understand of JAAS, the client side must have server call-backs. In my case, the client will be a web front-end, most likely running on a *nix box (ejb server also running on *nix). Makes it kind of tough to integrate with NT domains.
I have coded a simple session bean that gets around this, but I haven't load tested it yet. When an authentication request comes in, it actually tries to open an FTP session to one of the NT servers here, and determines whether or not the logon was successful. I can't believe that this will hold up under any kind of stress--that remains to be seen. My other option is to have the user pass through a web-based authentication system on an NT web server that could set a cookie if the user is authenticated, but I'd rather not do that...I hate spreading the application so thin, with so many points of failure.
Obviously, we could ask people to register and set up passwords, etc. But, besides being a security concern (housing people's passwords that they probably use for other services too), it's a major hassle to ask our customers to remember yet another password.
Has anyone else dealt with this? What have you done about it?
-Jason
