Harmeet,
You're again missing the point. > > ii) Correctly designing a pluggable, flexible, correct > > authentication/authorization mechanism is highly non-trivial. It > > It may not be the best mechanism, but AuthServiceFactory fixes the problem > you found and it is better than coupling auth stuff inside handler. > > > We do not have the time to do this properly without pushing out the > > release. > > I'll make sure AuthService issue is corrected before release. The change > delta will be smaller with AuthServiceFactory from current codebase. No, a simple AuthServiceFactory hack is not better than the current situation. A simple AuthServiceFactory would further expose the lousy AuthService interface - which remains wrong for all the reasons I discussed earlier. There never was a pluggable AuthService. And AuthService had other, substantial issues that I corrected by incorporating it into the handler (Exposure of user/password as sole authentication mechanism, failure to wipe username/password on bad auth, etc.). I'm not interested in minimizing the delta from the past code base. I'm interested in minimizing the delta from the current, correct, tested code base. And no change like the one you're proposing is going to do that. > We have so far talked about what should not be. Let us talk about what > should be the right way. ideas... And that's exactly what we shouldn't be doing so close to a release. Planning new architectural changes for things that haven't worked for nine months, after they've just been fixed, is ridiculous. But since you asked, here goes: I want an AuthService that allows me to load different JAAS providers for the purpose of authentication, to allow us to take advantage of numerous third-party authentication modules. It should have per-protocol callbacks, to allow us to use the same root class for all of the James services authentication needs. A limitation to user/password is obviously not acceptable. It should support complex, dynamic policy definition and should be able to link into external policy engines for authorization (i.e. RSA ClearTrust, IBM Policy Director) as well as into a simple home-grown policy class. Of course everyone agrees with me on this one, right? We're going to have this by tomorrow, right? Of course not. As I've tried to explain, doing something like this properly is difficult. It's not something you toss on the end of a release. There are a number of issues that need to be discussed and clarified. And it affects basically the whole server. --Peter -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
