You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@roller.apache.org by Brian Topping <to...@orb.org> on 2005/12/29 17:48:31 UTC
autoCreate for accounts
Hi guys,
I've got Roller set up to authenticate against an LDAP directory, but
as I might have expected, Roller doesn't like users to log in with an
LDAP password before their account has been created. It strikes me
that an autoCreate would be a good thing to have in this instance,
pulling the values that it can from the LDAP directory and saving
them to the database (or abstracting UserManager so that it can read
the small number of properties it needs from LDAP directly).
Dave mentioned on IRC that the Acegi implementation was new, and
after looking through it, I can see that it's not quite fully wired
in yet. CMA is still used with a Tomcat <Realm/> for authentication,
completely sidestepping Acegi. It seems if the answer to this
question is "get off CMA", then the idea of abstracting the
UserManager becomes easier to do. If this is a bad time for those
kinds of changes, it would be easier to addUser with values that were
replicated from LDAP.
I'm also not sure what kind of relational usages there are of the
rolleruser table or whether that table is entirely accessed through
the UserManager. The latter is of course much easier to deal with if
it were to be abstracted to get the data from LDAP.
Any thoughts appreciated!
:b
Re: autoCreate for accounts
Posted by Brian Topping <to...@codehaus.org>.
On Jan 2, 2006, at 9:33 PM, Matt Raible wrote:
>
> It looks like Acegi's LDAP support will be in the next release (1.0
> RC2).
>
> http://opensource2.atlassian.com/projects/spring/browse/SEC-12
Ok, then I guess I will explore this code today, since it appears
from the link that it is in SCM and I can check it out and use it.
If I can, I will go through and refactor the relations to the
rolleruser table such that they all use the username as the primary
key, then get the user record by username from UserManager. My aim
will be for Acegi to recover the user profile either from the
database (rolleruser) or LDAP, based on runtime configuration. Once
I complete that investigation, I'll report back to the list.
Before I get started, does anyone object in theory to this proposal?
thanks,
Brian
Re: autoCreate for accounts
Posted by Matt Raible <mr...@gmail.com>.
On 1/2/06, Brian Topping <to...@codehaus.org> wrote:
> After re-reading Elias' first message from 12/31, I realized I might
> not have made the changes that I was working on fully clear. I
> didn't actually refactor all 40+ calls to pass an autoCreate flag, I
> had added a UserManager method with the extra argument, then had the
> existing method call through to it with a default argument of
> Boolean.FALSE. In this manner, only the specific point of the code
> that needed to use the autoCreate would call the new method.
>
> My sense is that the code would be secure if this single call was
> judiciously placed, since none of the existing code would be
> affected, but I do have a concern after chatting with Elias that this
> call could be misunderstood and improperly used in the future.
>
> So if what we have below is a pretty good encapsulation of the issues
> with auto-create, it seems like we *could* make this work. But
> *should* we?
>
> If we are only doing this for LDAP, and the rolleruser table is not
> expected to grow significantly (it seems to be quite small still
> after years of development), it might be worth considering the
> questions I asked on 12/30. It seems to me that with a few changes
> we could make the rolleruser table a runtime optional configuration
> and grab the information (in this case) from LDAP.
>
> Now that Roller is using Acegi, can someone who is an expert with it
> answer what kind of abstract facilities it provides for a situation
> like this? I presume Acegi will eventually grow to abstract many AAA
> strategies, but is it sufficient for current needs and will it grow
> with projected needs?
It looks like Acegi's LDAP support will be in the next release (1.0 RC2).
http://opensource2.atlassian.com/projects/spring/browse/SEC-12
I don't believe Acegi is the problem in this situation (and in most
LDAP + RDBMS situations). It's the relationships between the tables
and the user that's an issue. That being said, Acegi is well designed
with interfaces and we should be able to hook more deeply into it in
the future. In AppFuse, we're reworking the current user-fetching
logic to rely on Acegi - at least on the authentication side. I'd
love to leverage it for all profile-related activities, but don't know
if that'll be possible.
http://issues.appfuse.org/browse/APF-118
Matt
>
> -b
>
> On Dec 31, 2005, at 4:16 PM, Elias Torres wrote:
>
> > On 12/31/05, Sean Gilligan <se...@msgilligan.com> wrote:
> >> Elias Torres wrote:
> >>>
> >>> 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.
> >>
> >> I'm not familiar with the code, but it seems to me that the only "use
> >> case" where autoCreate needs to be invoked is login (or perhaps an
> >> alternatively-configured behavior of register -- i.e. register would
> >> create a rolleruser account *only* if the user already exists in the
> >> external registry)
> >>
> >> Rather than change an existing method in UserData or UserManager
> >> wouldn't this just be a change in a login or register action?
> >
> > Correct. My version of the code did it in RollerSession when the
> > UserData bean is placed in the session *only* after you've logged in,
> > meaning that you are a valid directory user.
> >
> >>
> >> -- Sean
> >>
> >
> > -elias
> >
>
>
Re: autoCreate for accounts
Posted by Brian Topping <to...@codehaus.org>.
After re-reading Elias' first message from 12/31, I realized I might
not have made the changes that I was working on fully clear. I
didn't actually refactor all 40+ calls to pass an autoCreate flag, I
had added a UserManager method with the extra argument, then had the
existing method call through to it with a default argument of
Boolean.FALSE. In this manner, only the specific point of the code
that needed to use the autoCreate would call the new method.
My sense is that the code would be secure if this single call was
judiciously placed, since none of the existing code would be
affected, but I do have a concern after chatting with Elias that this
call could be misunderstood and improperly used in the future.
So if what we have below is a pretty good encapsulation of the issues
with auto-create, it seems like we *could* make this work. But
*should* we?
If we are only doing this for LDAP, and the rolleruser table is not
expected to grow significantly (it seems to be quite small still
after years of development), it might be worth considering the
questions I asked on 12/30. It seems to me that with a few changes
we could make the rolleruser table a runtime optional configuration
and grab the information (in this case) from LDAP.
Now that Roller is using Acegi, can someone who is an expert with it
answer what kind of abstract facilities it provides for a situation
like this? I presume Acegi will eventually grow to abstract many AAA
strategies, but is it sufficient for current needs and will it grow
with projected needs?
-b
On Dec 31, 2005, at 4:16 PM, Elias Torres wrote:
> On 12/31/05, Sean Gilligan <se...@msgilligan.com> wrote:
>> Elias Torres wrote:
>>>
>>> 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.
>>
>> I'm not familiar with the code, but it seems to me that the only "use
>> case" where autoCreate needs to be invoked is login (or perhaps an
>> alternatively-configured behavior of register -- i.e. register would
>> create a rolleruser account *only* if the user already exists in the
>> external registry)
>>
>> Rather than change an existing method in UserData or UserManager
>> wouldn't this just be a change in a login or register action?
>
> Correct. My version of the code did it in RollerSession when the
> UserData bean is placed in the session *only* after you've logged in,
> meaning that you are a valid directory user.
>
>>
>> -- Sean
>>
>
> -elias
>
Re: autoCreate for accounts
Posted by Elias Torres <el...@torrez.us>.
On 12/31/05, Sean Gilligan <se...@msgilligan.com> wrote:
> Elias Torres wrote:
> >
> > 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.
>
> I'm not familiar with the code, but it seems to me that the only "use
> case" where autoCreate needs to be invoked is login (or perhaps an
> alternatively-configured behavior of register -- i.e. register would
> create a rolleruser account *only* if the user already exists in the
> external registry)
>
> Rather than change an existing method in UserData or UserManager
> wouldn't this just be a change in a login or register action?
Correct. My version of the code did it in RollerSession when the
UserData bean is placed in the session *only* after you've logged in,
meaning that you are a valid directory user.
>
> -- Sean
>
-elias
Re: autoCreate for accounts
Posted by Sean Gilligan <se...@msgilligan.com>.
Elias Torres wrote:
>
> 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.
I'm not familiar with the code, but it seems to me that the only "use
case" where autoCreate needs to be invoked is login (or perhaps an
alternatively-configured behavior of register -- i.e. register would
create a rolleruser account *only* if the user already exists in the
external registry)
Rather than change an existing method in UserData or UserManager
wouldn't this just be a change in a login or register action?
-- Sean
Re: autoCreate for accounts
Posted by Elias Torres <el...@torrez.us>.
On 12/31/05, Sean Gilligan <se...@msgilligan.com> 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
Re: autoCreate for accounts
Posted by Sean Gilligan <se...@msgilligan.com>.
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?
>
> 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
Re: autoCreate for accounts
Posted by Brian Topping <to...@codehaus.org>.
We should think about this a bit. It seems to be that this could be
a good hole for a DOS attack if the authentication was compromised.
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...
I'm leaning toward UserManager being smart enough to handle remote
user profiles. I got sidetracked yesterday and today and couldn't
focus on it, but it seems that the username and the varchar record ID
are intermixed as the primary key for the table. If, in this case
only, the username was used as the primary key, the use of profile in
LDAP would be simplified, without adversely affecting behavior if
LDAP was not used.
I presume I must be missing something here, can we discuss it?
-b
On Dec 30, 2005, at 1:56 PM, Sean Gilligan wrote:
> Brian Topping wrote:
>> Oops, I was tired and was mixing versions. Ten thousand apologies!!
>> I'll see what I can pull together.
>
> Just to be clear: you're planning on adding "auto create" to the
> 2.1 code base? That is something I need for a project that I'm
> working on, too. I'm definitely willing to help out on this one by
> coding, testing, or writing wiki documentation. Let me know...
>
> Regards,
>
> Sean
>
>>
>
Re: autoCreate for accounts
Posted by Sean Gilligan <se...@msgilligan.com>.
Brian Topping wrote:
> Oops, I was tired and was mixing versions. Ten thousand apologies!!
>
> I'll see what I can pull together.
Just to be clear: you're planning on adding "auto create" to the 2.1
code base? That is something I need for a project that I'm working on,
too. I'm definitely willing to help out on this one by coding, testing,
or writing wiki documentation. Let me know...
Regards,
Sean
>
Re: autoCreate for accounts
Posted by Brian Topping <to...@codehaus.org>.
Oops, I was tired and was mixing versions. Ten thousand apologies!!
I'll see what I can pull together.
-b
On Dec 29, 2005, at 12:00 PM, Matt Raible wrote:
> On 12/29/05, Brian Topping <to...@orb.org> wrote:
>> Hi guys,
>>
>> I've got Roller set up to authenticate against an LDAP directory, but
>> as I might have expected, Roller doesn't like users to log in with an
>> LDAP password before their account has been created. It strikes me
>> that an autoCreate would be a good thing to have in this instance,
>> pulling the values that it can from the LDAP directory and saving
>> them to the database (or abstracting UserManager so that it can read
>> the small number of properties it needs from LDAP directly).
>>
>> Dave mentioned on IRC that the Acegi implementation was new, and
>> after looking through it, I can see that it's not quite fully wired
>> in yet. CMA is still used with a Tomcat <Realm/> for authentication,
>> completely sidestepping Acegi.
>
> Why do you say this? It sounds like there might be some cleanup we
> need to do. If you build Roller from SVN, there are no longer any
> <security-constraint>'s added to web.xml.
>
>> It seems if the answer to this
>> question is "get off CMA", then the idea of abstracting the
>> UserManager becomes easier to do. If this is a bad time for those
>> kinds of changes, it would be easier to addUser with values that were
>> replicated from LDAP.
>
> Acegi is adding support for LDAP Authentication, but I don't know if
> it'll be in the 1.0 release.
>
> Matt
>
>>
>> I'm also not sure what kind of relational usages there are of the
>> rolleruser table or whether that table is entirely accessed through
>> the UserManager. The latter is of course much easier to deal with if
>> it were to be abstracted to get the data from LDAP.
>>
>> Any thoughts appreciated!
>>
>> :b
>>
>
Re: autoCreate for accounts
Posted by Matt Raible <mr...@gmail.com>.
On 12/29/05, Brian Topping <to...@orb.org> wrote:
> Hi guys,
>
> I've got Roller set up to authenticate against an LDAP directory, but
> as I might have expected, Roller doesn't like users to log in with an
> LDAP password before their account has been created. It strikes me
> that an autoCreate would be a good thing to have in this instance,
> pulling the values that it can from the LDAP directory and saving
> them to the database (or abstracting UserManager so that it can read
> the small number of properties it needs from LDAP directly).
>
> Dave mentioned on IRC that the Acegi implementation was new, and
> after looking through it, I can see that it's not quite fully wired
> in yet. CMA is still used with a Tomcat <Realm/> for authentication,
> completely sidestepping Acegi.
Why do you say this? It sounds like there might be some cleanup we
need to do. If you build Roller from SVN, there are no longer any
<security-constraint>'s added to web.xml.
> It seems if the answer to this
> question is "get off CMA", then the idea of abstracting the
> UserManager becomes easier to do. If this is a bad time for those
> kinds of changes, it would be easier to addUser with values that were
> replicated from LDAP.
Acegi is adding support for LDAP Authentication, but I don't know if
it'll be in the 1.0 release.
Matt
>
> I'm also not sure what kind of relational usages there are of the
> rolleruser table or whether that table is entirely accessed through
> the UserManager. The latter is of course much easier to deal with if
> it were to be abstracted to get the data from LDAP.
>
> Any thoughts appreciated!
>
> :b
>