On 12/31/05, Sean Gilligan <[EMAIL PROTECTED]> wrote: > Brian Topping wrote: > > We should think about this a bit. > > I've added a Wiki page for a proposal to collect our thinking: > http://www.rollerweblogger.org/wiki/Wiki.jsp?page=Proposal_ExternalAuthentication > > > It seems to be that this could be a > > good hole for a DOS attack if the authentication was compromised. > > How is this situation any different from possible DOS (or worse) attacks > if the current authentication is compromised? If you're using an > external authentication server we can only assume that it is secure. > (We need to make sure that whatever communication channel between Roller > and the external auth server is secure -- *that* could result in an > additional security weakness.) Am I missing something?
No you are not. I think what Brian is talking about is the fact that we have to place the code in the right place if not we can open ourselves to a DOS attack. For example, he was adding "autoCreate" to the getUser(username) function in UserData or UserManager. I pointed out to him that there are many (40+) calls that use this function like the RollerAtomHandler class. The handler grabs the userid from the auth header and calls UserManager.getUser. If we had autoCreate it would "register" as many users as there are requests to this servlets. Hence, a DOS attack. I'm not against autoCreate, all I'm asking is that we place it in the correct location. > > > > > The other consideration for me was that all the information in the > > rolleruser table is (or can be) in LDAP. What does it mean if someone > > updates that information? Do we replicate it again? What is the > > trigger? etc... > > These are good questions. Since I haven't really looked at the source I > don't know the best answer (if there is a "best" answer) or even the > tradeoffs. My inclinations at this time are to be pragmatic and come up > with a solution that works well enough with minimum effort. For > example: allow the duplication, but consider the LDAP/external server to > be the master. Update the data whenever the user logs in or whenever an > admin views that user in a Struts form. I suppose there could also be a > read-only flag that applies to the user information. > > -- Sean > > Elias
