on 1/21/02 4:22 AM, "Gonzalo A. Diethelm" <[EMAIL PROTECTED]> wrote:
>> Dan Diephouse, could you summarize your ideas in a stand-alone posting? >> We may be getting closer to a consensus, and it would be good to look >> again at what you propose in full. > > Also, I think it would be good to keep in mind that it is probably > a good idea that the design of the security system separates these > concerns: > > 1. Authentication (log-in, log-out, password admin?) > 2. Authorization (is this user allowed to do this) > 3. Profiling (user preferences) > 4. Administration (add, edit, remove users) > $0.00 What seems to be missing here and all of the conversations I have seen about this up until this point, is 'What' we want to secure. In other words, we know that we need to have some concept of 'users'...but once you have that, what are you actually securing? I think that should be what defines how the security system is built. Yes, we realize, we need #1 and #2...but if you think about #2 further, you need to realize that we need to also answer that question with joins against other data such as: "is the user part of a project and if so, what roles does the user have in that project"? API's like JAAS are great at securing access to source code. But, they really don't go beyond that without trying to munge them into something they aren't. Honestly, I don't even see why this conversation is happening. The Turbine security system is pretty good as it stands. Renaming Group -> Project and documenting the heck out of it would be the only changes I see as being necessary in order to have a pretty functional security system for webapps. $0.00. -jon -- Standard rules apply: Ask any questions, and you get the job. ;-) -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
