LDAP module and password recording in DB
t.le...@gmail.com
While reviewing the ldap authentication module, I found out that once
authenticated, OM records and updates the user's password in its
internal DB.
Why is that ?
In LdapLoginManagement.java: in method doLdapLogin
// Update password (could have changed in LDAP)
u.setPassword(passwd);
Since all authentications are done on the LDAP server, I think it is a
bad idea to duplicate the password in OM internal DB.
Is there another good reason to do this ?
The only reason I see so far is that in MainService, the loginUser
method fails back to non LDAP authentication if the user has admin
privileges. This also means that even if the user changes his password
in LDAP, his old password recorded to the OM db must be used...
I think it would be better:
* to set a random password value in the OM's Users tables for the Ldap users
* set a new parameter in om_ldap that will list admin users for which
LDAP auth must be bypassed (in order to keep a local admin login even if
LDAP is badly configured or unavailable).
What do you think ?
Thibault
smoeker
the original reason for storing the ldap passwd locally (md5
encrypted) within OM is to be able to use openMeetings, even if ldap
server is maintained/off/not available...
-> i remember a post, somebody saying its sometimes hard to keep syncd
with the Ldap Directory Admin - i agree with that ;-)
-> this is also the reason for storing the admins password locally -
admin users should always be able to access OM, even if there are
compilations with the Ldap Directory Server...
Since its always the Ldappassword that has to be correct (in case Ldap
is configured) , its not really duplicated, but stored as fallback
(this is working without stopping OM Server).
The userdata should be updated on every successful login , so the db
passwd should also always be in sync with the Ldap server. (The only
scenario it would fail would be, if LDAP password changes and ldap
server is off/not configured in OM, so the local password wouldn't
match the current DB password - but coding the fallback for the
fallback is not my flavour ;-))
i dont think i understand the random passowrd bypass via config -how
would a OM user authenticate, if Ldap server is off?
see ya
Smoeker
Sebastian Wagner
It would be important to me that the User-Object is the same everytime the User-Logs in.
Otherwise some of the functionality does not work like personal folders in the Recordings-UI.
But from my point of view that is already done with the code Oliver has done.
I would suggest that we write the User-id from LDAP in the field:
externalUserId of each user
and *ldap* or *openldap* or *ad* in the field
externalUserType of each user
created via LDAP
[if there is any User-id from LDAP only of course]
Sebastian
--
You received this message because you are subscribed to the Google Groups "OpenMeetings User" group.
To post to this group, send email to openmeet...@googlegroups.com.
To unsubscribe from this group, send email to openmeetings-u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/openmeetings-user?hl=en.
--
Sebastian Wagner
http://www.webbase-design.de
http://openmeetings.googlecode.com
http://www.laszlo-forum.de
seba....@gmail.com
t.le...@gmail.com
> hi Oliver and Thibault,
>
> It would be important to me that the User-Object is the same everytime
> the User-Logs in.
> Otherwise some of the functionality does not work like personal
> folders in the Recordings-UI.
> But from my point of view that is already done with the code Oliver
> has done.
Sure, it is done, and must remain the same. My concern is only about the
user password duplicated on the OM database.
>
> I would suggest that we write the User-id from LDAP in the field:
>
> externalUserId of each user
> and *ldap* or *openldap* or *ad* in the field
> externalUserType of each user
> created via LDAP
>
> [if there is any User-id from LDAP only of course]
Yes there is, it's the user DN (Distinguished Name), which is unique per
Ldap entry inside a given Ldap directory.
That would be great indeed, and should be simple to implement
>
>
> Sebastian
>
> 2010/4/15 smoeker <o.bec...@medint.de <mailto:o.bec...@medint.de>>
>
> hola,
>
> the original reason for storing the ldap passwd locally (md5
> encrypted) within OM is to be able to use openMeetings, even if ldap
> server is maintained/off/not available...
>
> -> i remember a post, somebody saying its sometimes hard to keep syncd
> with the Ldap Directory Admin - i agree with that ;-)
> -> this is also the reason for storing the admins password locally -
> admin users should always be able to access OM, even if there are
> compilations with the Ldap Directory Server...
>
> Since its always the Ldappassword that has to be correct (in case Ldap
> is configured) , its not really duplicated, but stored as fallback
> (this is working without stopping OM Server).
>
> The userdata should be updated on every successful login , so the db
> passwd should also always be in sync with the Ldap server. (The only
> scenario it would fail would be, if LDAP password changes and ldap
> server is off/not configured in OM, so the local password wouldn't
> match the current DB password - but coding the fallback for the
> fallback is not my flavour ;-))
>
> i dont think i understand the random passowrd bypass via config -how
> would a OM user authenticate, if Ldap server is off?
>
>
> see ya
>
> Smoeker
>
> On 15 Apr., 13:51, t.lem...@gmail.com <mailto:t.lem...@gmail.com>
> <mailto:openmeet...@googlegroups.com>.
> To unsubscribe from this group, send email to
> openmeetings-u...@googlegroups.com
> <mailto:openmeetings-user%2Bunsu...@googlegroups.com>.
> For more options, visit this group at
> http://groups.google.com/group/openmeetings-user?hl=en.
>
>
>
>
> --
> Sebastian Wagner
> http://www.webbase-design.de
> http://openmeetings.googlecode.com
> http://www.laszlo-forum.de
> seba....@gmail.com <mailto:seba....@gmail.com>
Sebastian Wagner
*do you use the user paswword after authentication*
=> no
Sebastian
t.le...@gmail.com
> hola,
>
> the original reason for storing the ldap passwd locally (md5
> encrypted) within OM is to be able to use openMeetings, even if ldap
> server is maintained/off/not available...
>
That is why usually an Ldap client implementation shoud propose to setup
2 Ldap servers definitions, in order to have one as backup.
> -> i remember a post, somebody saying its sometimes hard to keep syncd
> with the Ldap Directory Admin - i agree with that ;-)
>
I don't understand. What do you mean by this? Can you give an example ?
> -> this is also the reason for storing the admins password locally -
> admin users should always be able to access OM, even if there are
> compilations with the Ldap Directory Server...
>
Let's narrow down the password duplication to admins only then.
> Since its always the Ldappassword that has to be correct (in case Ldap
> is configured)
Not for Admins. for admins Ldap authentication is always bypassed.
--- in MainService ---
// AdminUser werden auf jeden Fall lokal authentifiziert
if(user != null && user.getLevel_id() >=3){
log.debug("User " + usernameOrEmail + " is admin ->
local login");
withLdap = false;
}
--- ---
> , its not really duplicated, but stored as fallback
> (this is working without stopping OM Server).
>
Well, yes it is duplicated then ;-)
This method has another pb. It supposes that all authentication systems
supported by OM in the future will let OM know the user password which
is not always the case.
Imagine that someone wants to implement an authentication module to
support the Central Authentication Service (CAS). This SSO system works
like this:
* OM gets a request, and is setup to use CAS, so that it checks if a
service ticket (either a cookie or GET param) is set
* OM sees no ticket and redirects the client to the CAS server which
performs authentication, generate a ticket and redirect the client to OM
with teh valid ticket set in URL or cookie
* OM sees the new request with a ticket, it checks the ticket by asking
the CAS server if it is valid, and then accept the client.
==> In this protocol, OM never sees the user password.
It would be a pity to prevent future developpements of any kind of
authentication systems, just because the first design was supposing a
valid password is known by OM.
But this is only my opinion.
> The userdata should be updated on every successful login , so the db
> passwd should also always be in sync with the Ldap server. (The only
> scenario it would fail would be, if LDAP password changes and ldap
> server is off/not configured in OM, so the local password wouldn't
> match the current DB password - but coding the fallback for the
> fallback is not my flavour ;-))
>
This will occur as soon as a Ldap user having admin privileges changes
his LDAP password. I'm sure of this.
> i dont think i understand the random passowrd bypass via config -how
> would a OM user authenticate, if Ldap server is off?
>
Ldap server should never be off. at least a backup should be online.
Imigine that a user gets banned from an organization, and the Ldap admin
delete his account on the Ldap server.
This user would only have to run a DOS attack on the Ldap server to keep
his access on the OM system!
So my proposal of a random password was to prevent anyone from login in
with a user imported from Ldap even if the Ldap server is offline.
But I see now that we have 2 differents point of view on the matter.
I think then that this behaviour should be switchable in config: having
a parameter that decides weither or not OM falls back to internal DB
auth if Ldap is offline.
Sebastian Wagner
*I think then that this behaviour should be switchable in config: having a parameter that decides weither or not OM falls back to internal DB auth if Ldap is offline.*
=> adding this param is no problem, you can also make it slightly different:
Still populate the password but if the user has turned off the LDAP Feature you set the user to status *disabled*. Disabled users are not able to login via the User-Database of OM.
Sebastian
--
You received this message because you are subscribed to the Google Groups "OpenMeetings User" group.
To post to this group, send email to openmeet...@googlegroups.com.
To unsubscribe from this group, send email to openmeetings-u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/openmeetings-user?hl=en.
smoeker
i agree - if its configurable via config, there should be no further
problems - hands on, Thibault ;-)
hmm, ldap clients using mutliple configurations for fallback safety
are quite new to me, i must confess - i know about scenarios ,
mirroring the Directory Servers, but i dont think, that a ldap client
should contain that logic...
concering the LDAP Auth for OM admins :
>>This will occur as soon as a Ldap user having admin privileges changes his LDAP password. I'm sure of this <<
-> nope, i dont think so - this only causes problems, if the OM Admin
himself turns Ldap Auth off for OM and afterwards his password
changes....
-> since the OM admin is the person turning the Ldap auth off, he is
the only one that can be aware of the problem, that his ldap password
isnt acutalized anymore within OM.
-> furthermore the storing of the password is a fallback for a short
time usually - i couldn't think of a scenario setting OM up with Ldap,
then switching back to local auth for ever...
>>But I see now that we have 2 differents point of view on the matter. <<
right, i am a fan of modular infrastructure - the Ldap auth was
thought as usability feature for users, that dont want to keep another
stupid password, but it shouldn't prevent them from working, if there
is trouble with the directory server....
see ya
Smoeker
On 15 Apr., 15:04, Sebastian Wagner <seba.wag...@gmail.com> wrote:
> hi,
>
> *I think then that this behaviour should be switchable in config: having a
> parameter that decides weither or not OM falls back to internal DB auth if
> Ldap is offline.*
>
> => adding this param is no problem, you can also make it slightly different:
> Still populate the password but if the user has turned off the LDAP Feature
> you set the user to status *disabled*. Disabled users are not able to login
> via the User-Database of OM.
>
> Sebastian
>
> 2010/4/15 <t.lem...@gmail.com>
> > openmeetings-u...@googlegroups.com<openmeetings-user%2Bunsu...@googlegroups.com>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/openmeetings-user?hl=en.
>
> --
> Sebastian Wagnerhttp://www.webbase-design.dehttp://openmeetings.googlecode.comhttp://www.laszlo-forum.de
t.le...@gmail.com
> hola,
>
> i agree - if its configurable via config, there should be no further
> problems - hands on, Thibault ;-)
>
challenge ;-)
> hmm, ldap clients using mutliple configurations for fallback safety
> are quite new to me, i must confess - i know about scenarios ,
> mirroring the Directory Servers, but i dont think, that a ldap client
> should contain that logic...
>
Indeed, it is up to the Ldap server to run the sync logic, the client
usually just has 2 ldap servers defined in its setup and then tries the
second one if the first one fails.
It is equivalent to giving 2 DNS servers IP addresses to your IP setup.
Thibault
>>> smoeker a �crit :
t.le...@gmail.com
> hi,
>
>
> *I think then that this behaviour should be switchable in config:
> having a parameter that decides weither or not OM falls back to
> internal DB auth if Ldap is offline.*
>
> => adding this param is no problem, you can also make it slightly
> different:
> Still populate the password but if the user has turned off the LDAP
> Feature you set the user to status *disabled*. Disabled users are not
> able to login via the User-Database of OM.
This is possible but not secure. As a security officer I know that
password duplication is a bad thing to do as this can decrease the
Information System overall security level.
For instance, OM is storing the password in a database: so now it's up
to the DB admin to secure the DB access.
==> Imagine he just doesn't think it contains confidential information,
this could lead to passwords compromise.
OM stores passwords as MD5 hashes, so it may seem to be secure anyway...
yes and no... because most of the time passwords are easy to find by
small derivations of a passwords dictionary.
Having an MD5 list of passwords is enough to break a good number of
passwords quickly. A way to increase security would be to use salted MD5
version of the passwords.
However there is a better approach to security: instead of trying to
secure the confidential data an application stores, it is better to just
store only required data. And since passwords are not required for Ldap
users in OM (unless the "to be invented" sync-ldap-password-to-om
parameter is set), then it would be better to just not record them.
Thibault
>
> Sebastian
>
> 2010/4/15 <t.le...@gmail.com <mailto:t.le...@gmail.com>>
>
> smoeker a �crit :
> <mailto:openmeet...@googlegroups.com>.
> To unsubscribe from this group, send email to
> openmeetings-u...@googlegroups.com
> <mailto:openmeetings-user%2Bunsu...@googlegroups.com>.
> For more options, visit this group at
> http://groups.google.com/group/openmeetings-user?hl=en.
>
>
>
>
> --
> Sebastian Wagner
> http://www.webbase-design.de
> http://openmeetings.googlecode.com
> http://www.laszlo-forum.de
> seba....@gmail.com <mailto:seba....@gmail.com>
Sebastian Wagner
okay Thibault I will add this to list of Issues, its a minor change if you are not aware how to add the config key and param I can do it.
http://code.google.com/p/openmeetings/issues/detail?id=1208
Can you please attached your DIFF with the Patch to it and I will commit it to the SVN.
Sebastian
hi,
*I think then that this behaviour should be switchable in config: having a parameter that decides weither or not OM falls back to internal DB auth if Ldap is offline.*
=> adding this param is no problem, you can also make it slightly different:
Still populate the password but if the user has turned off the LDAP Feature you set the user to status *disabled*. Disabled users are not able to login via the User-Database of OM.
This is possible but not secure. As a security officer I know that password duplication is a bad thing to do as this can decrease the Information System overall security level.
For instance, OM is storing the password in a database: so now it's up to the DB admin to secure the DB access.
==> Imagine he just doesn't think it contains confidential information, this could lead to passwords compromise.
OM stores passwords as MD5 hashes, so it may seem to be secure anyway... yes and no... because most of the time passwords are easy to find by small derivations of a passwords dictionary.
Having an MD5 list of passwords is enough to break a good number of passwords quickly. A way to increase security would be to use salted MD5 version of the passwords.
However there is a better approach to security: instead of trying to secure the confidential data an application stores, it is better to just store only required data. And since passwords are not required for Ldap users in OM (unless the "to be invented" sync-ldap-password-to-om parameter is set), then it would be better to just not record them.
Thibault
Sebastian
2010/4/15 <t.le...@gmail.com <mailto:t.le...@gmail.com>>
smoeker a écrit :
t.le...@gmail.com
> hi,
>
> okay Thibault I will add this to list of Issues, its a minor change if
> you are not aware how to add the config key and param I can do it.
By the way I've "implemented" the Failover Ldap support (I mean the fact
that OM can switch to a second ldap server in case the first one is down).
It's simply a matter of adding a comment in the configuration file ;-),
cause i'ts already supported by JNDI.
---
#LDAP URL
# can be a simple URL like: ldap://myldap.myorg.com
# or a list of simple URL separated by a space as in:
ldap://myldap.myorg.com ldap://myldap2.myorg.com
ldap_conn_url=
---
Thibault
>
> http://code.google.com/p/openmeetings/issues/detail?id=1208
>
> Can you please attached your DIFF with the Patch to it and I will
> commit it to the SVN.
k, will do when it's ready.
Thibault
>
>
> Sebastian
>
> 2010/4/15 <t.le...@gmail.com <mailto:t.le...@gmail.com>>
>
> Sebastian Wagner a �crit :
> <mailto:t.le...@gmail.com <mailto:t.le...@gmail.com>>>
>
>
> smoeker a �crit :
> <mailto:t.lem...@gmail.com <mailto:t.lem...@gmail.com>>
> <mailto:openmeet...@googlegroups.com
> <mailto:openmeet...@googlegroups.com>>.
>
> To unsubscribe from this group, send email to
> openmeetings-u...@googlegroups.com
> <mailto:openmeetings-user%2Bunsu...@googlegroups.com>
> <mailto:openmeetings-user%2Bunsu...@googlegroups.com
> <mailto:openmeetings-user%252Buns...@googlegroups.com>>.
>
> For more options, visit this group at
> http://groups.google.com/group/openmeetings-user?hl=en.
>
>
>
>
> --
> Sebastian Wagner
> http://www.webbase-design.de
> http://openmeetings.googlecode.com
> http://www.laszlo-forum.de
> seba....@gmail.com <mailto:seba....@gmail.com>
> <mailto:seba....@gmail.com <mailto:seba....@gmail.com>>
> --
> You received this message because you are subscribed to the
> Google Groups "OpenMeetings User" group.
> To post to this group, send email to
t.le...@gmail.com
>> http://code.google.com/p/openmeetings/issues/detail?id=1208
>>
>> Can you please attached your DIFF with the Patch to it and I will
>> commit it to the SVN.
> k, will do when it's ready.
Would you mind if I add the following hardcoded CONST as parameters in
om_ldap.cfg ?
// LDAP KEYS
public static final String LDAP_KEY_LASTNAME = "sn";
public static final String LDAP_KEY_FIRSTNAME = "givenName";
public static final String LDAP_KEY_MAIL = "mail";
public static final String LDAP_KEY_STREET = "streetAddress";
public static final String LDAP_KEY_ADDITIONAL_NAME = "description";
public static final String LDAP_KEY_FAX = "facsimileTelephoneNumber";
public static final String LDAP_KEY_ZIP = "postalCode";
public static final String LDAP_KEY_COUNTRY = "co";
public static final String LDAP_KEY_TOWN = "l";
public static final String LDAP_KEY_PHONE = "telephoneNumber";
I think this will be a little more flexible in case someone has another
Ldap schema.
Thibault
t.le...@gmail.com
t.le...@gmail.com
Another file needs to be modified so that LDap users set as admin can login.
Thibault
t.le...@gmail.com a �crit :
t.le...@gmail.com
> smoeker a �crit :
>>
>>
>>
>>>> This will occur as soon as a Ldap user having admin privileges
>>>> changes his LDAP password. I'm sure of this <<
>>>>
>>
>> -> nope, i dont think so - this only causes problems, if the OM Admin
>> himself turns Ldap Auth off for OM and afterwards his password
>> changes....
straightforward: if a user has admin rights then he is authenticated to
th OM DB and not Ldap. This means that his password will never gets
synched again later.
This is also something I have to change in my proposed patch
>> -> since the OM admin is the person turning the Ldap auth off, he is
>> the only one that can be aware of the problem, that his ldap password
>> isnt acutalized anymore within OM.
Not only his own password, but also the passwords of others.
When switching ldap config off, the OM should decide wether to go on
authenticating users that have externalId set to Ldap or not.
Anyway, this might be a very rare case.
>> -> furthermore the storing of the password is a fallback for a short
>> time usually - i couldn't think of a scenario setting OM up with Ldap,
>> then switching back to local auth for ever...
I agree.
>>
>>
>>>> But I see now that we have 2 differents point of view on the
>>>> matter. <<
>>>>
>>
>> right, i am a fan of modular infrastructure
Yes me too.
>> - the Ldap auth was
>> thought as usability feature for users, that dont want to keep another
>> stupid password, but it shouldn't prevent them from working, if there
>> is trouble with the directory server....
But there shouldn't be any troubel with the Directory server, at least
with 2 openldap servers in synch ;-)
Thibault
smoeker
to avoid misunderstandings :
"I'm sure of what I said because I've tested it and the code is
straightforward: if a user has admin rights then he is authenticated
to
th OM DB and not Ldap. This means that his password will never gets
synched again later."
database and his password is never synched with LDAP Directory
-> and btw : i am also quite sure of what i am saying, cause i wrote
the main part of the ldap code ;-)
"This is also something I have to change in my proposed patch"
user that is created on install process - his password is stored in
local database, could be confusing for users to define a password for
admin, that will be ignored on login...
"But there shouldn't be any trouble with the Directory server, at
with 2 openldap servers in synch ;-)"
maintained or insn't available every time. hard to understand, why i
shouldn't be able to communicate using OM, if admin maintains
directory server...
but as you said : as long as its configurable, everything is
finyfine ;-)
see ya
Smoeker
On 15 Apr., 20:28, t.lem...@gmail.com wrote:
> t.lem...@gmail.com a crit :> smoeker a crit :
You received this message because you are subscribed to the Google Groups "OpenMeetings User" group.
To post to this group, send email to openmeet...@googlegroups.com.
t.le...@gmail.com
>
> to avoid misunderstandings :
>
> "I'm sure of what I said because I've tested it and the code is
> straightforward: if a user has admin rights then he is authenticated
> to
> th OM DB and not Ldap. This means that his password will never gets
> synched again later."
>
> -> u r right, ldap admins are always authenticated against local
> database and his password is never synched with LDAP Directory
> -> and btw : i am also quite sure of what i am saying, cause i wrote
> the main part of the ldap code ;-)
>
> "This is also something I have to change in my proposed patch"
>
> cool, go ahead - you should also consider a solution for the admin
> user that is created on install process - his password is stored in
> local database, could be confusing for users to define a password for
> admin, that will be ignored on login...
>
AuthenticationType not set to LDAP will be authenticated against the
local DB: this means not only admins but also other users.
> "But there shouldn't be any trouble with the Directory server, at
> least
> with 2 openldap servers in synch ;-)"
>
> we can not treat that as precondition - every software has to be
> maintained or insn't available every time. hard to understand, why i
> shouldn't be able to communicate using OM, if admin maintains
> directory server...
>
> but as you said : as long as its configurable, everything is
> finyfine ;-)
>
undersatnd how you can failback to internal DB authentication apart form
temporarily disabling LDAP authentication. Is it what you do when LDAP
is unreachable, or is there somwhere in the code somethinh that I
haven't seen that takes care of this switching to internal DB when LDAP
is unreachable ?
TIA,
Thibault