Hi!
We're in the process of setting up OTRS (4.0.9 at the moment) as a support ticket system. Unfortunately, we have to get the customer data (read-only) from our ERP system. This results in a) password is not storable there, and b) the CustomerKey (set to the 'login' column) is something we don't want customers to log in with (it's some ID internal to the ERP system). We can't use the email addresses as CustomerKey as they are not unique (e.g. customer users are stored with multiple companies or addresses, but with the same email address).
So I wrote a new Customer::AuthModule (based on Kernel::System::CustomerAuth::DB), providing a new table that maps customer email addresses (= login name) to CustomerKey values and stores the passwords.
Unfortunately, when a customer user tries to change his password, OTRS tries to save it through Kernel::System::CustomerUser::SetPassword - which uses the read-only customer data connection.
Are my observations correct, and is there a work-around?
Thanks for any insights and suggestions,
Martin
Inconsistency in customer authentication?
Moderator: crythias
-
- Znuny newbie
- Posts: 15
- Joined: 30 Jun 2014, 14:49
- Znuny Version: 6.4.4
- Real Name: Martin Vorländer
- Company: PDV-Systeme GmbH
- Contact:
Inconsistency in customer authentication?
OTRS 6.4.4, Ubuntu 20.04.5 LTS with MariaDB 10.3.37
-
- Znuny advanced
- Posts: 121
- Joined: 30 Aug 2011, 10:48
- Znuny Version: 3.3.8 && 4.0.9
- Real Name: Artjoms Petrovs
- Location: Latvia
Re: Inconsistency in customer authentication?
If you made a new table where customer data is imported, or a materialized view that contains data from your ERP ( Exported data ), then where is the problem to use default CustomerAuth::DB connection with RW connection to it?providing a new table that maps customer email addresses (= login name) to CustomerKey values and stores the passwords
You won't edit the data in your ERP, but in the new table.
Ar cieņu / Kind regards,
----------------------------------------
Artjoms Petrovs
Sistēmu analītiķis/Programmētājs /
Systems Analyst/Programmer
----------------------------------------
Artjoms Petrovs
Sistēmu analītiķis/Programmētājs /
Systems Analyst/Programmer
-
- Znuny newbie
- Posts: 15
- Joined: 30 Jun 2014, 14:49
- Znuny Version: 6.4.4
- Real Name: Martin Vorländer
- Company: PDV-Systeme GmbH
- Contact:
Re: Inconsistency in customer authentication?
It's a tad more complicated... It was determined that we didn't want OTRS to work on a copy of the customer data but the live data. The ERP system stores address information in some index sequential file. We installed a software that presents (via ODBC) this data as a relational database. With that software I set up views that look like the customer_user and customer_company tables, installed the ODBC driver on the OTRS machine and rewrote a clone of Kernel::System::DB::DB.pm to get the database connection.
This works quite well, but
Using a custom module based on Kernel::System::CustomerAuth::DB, I changed Auth() to return the erp_key value on successful authentication. This works for logging in.
But: when a customer logs in, goes to the preferences screen, and tries to change his password, the underlying perl code (Kernel::Output::HTML::PreferencesPassword.pm) calls Kernel::System::CustomerUser::SetPassword() to store the password - and this tries to store it in the (ERP read-only) CustomerUser source.
My particular problem aside: I can't see how this could possibly work when authentication is done via LDAP, HTTP, or RADIUS ??!
This works quite well, but
- it's read-only so can't store passwords
- the key column (named 'login') uses the ERP system's key (as email addresses are not unique)
- there is a requirement to use email addresses as login names for the customer portal
Using a custom module based on Kernel::System::CustomerAuth::DB, I changed Auth() to return the erp_key value on successful authentication. This works for logging in.
But: when a customer logs in, goes to the preferences screen, and tries to change his password, the underlying perl code (Kernel::Output::HTML::PreferencesPassword.pm) calls Kernel::System::CustomerUser::SetPassword() to store the password - and this tries to store it in the (ERP read-only) CustomerUser source.
My particular problem aside: I can't see how this could possibly work when authentication is done via LDAP, HTTP, or RADIUS ??!
OTRS 6.4.4, Ubuntu 20.04.5 LTS with MariaDB 10.3.37
-
- Znuny newbie
- Posts: 15
- Joined: 30 Jun 2014, 14:49
- Znuny Version: 6.4.4
- Real Name: Martin Vorländer
- Company: PDV-Systeme GmbH
- Contact:
Re: Inconsistency in customer authentication?
Never mind... I just saw this code in Kernel::Output::HTML::PreferencesPassword::Param()martinv2 wrote:My particular problem aside: I can't see how this could possibly work when authentication is done via LDAP, HTTP, or RADIUS ??!
Code: Select all
my $AuthModule = $Self->{ConfigItem}->{Area} eq 'Agent'
? 'AuthModule'
: 'Customer::AuthModule';
# get auth module
my $Module = $Self->{ConfigObject}->Get($AuthModule);
my $AuthBackend = $Param{UserData}->{UserAuthBackend};
if ($AuthBackend) {
$Module = $Self->{ConfigObject}->Get( $AuthModule . $AuthBackend );
}
# return on no pw reset backends
return if $Module =~ /(LDAP|HTTPBasicAuth|Radius)/i;
OTRS 6.4.4, Ubuntu 20.04.5 LTS with MariaDB 10.3.37
-
- Moderator
- Posts: 10169
- Joined: 04 May 2010, 18:38
- Znuny Version: 5.0.x
- Location: SouthWest Florida, USA
- Contact:
Re: Inconsistency in customer authentication?
It's easier than you think. Because you tell the customer that they must change the password in the source location: The OTRS password is your desktop(or ERP or whatever) password. Always. If you [want to] change your desktop password, it automatically changes OTRS, not the other way around. For LDAP or RADIUS, you may also even attempt SSO so password changes aren't an issue.martinv2 wrote:It's a tad more complicated... It was determined that we didn't want OTRS to work on a copy of the customer data but the live data. The ERP system stores address information in some index sequential file. We installed a software that presents (via ODBC) this data as a relational database. With that software I set up views that look like the customer_user and customer_company tables, installed the ODBC driver on the OTRS machine and rewrote a clone of Kernel::System::DB::DB.pm to get the database connection.
This works quite well, butI set up Customer::Auth to use a table different from customer_user with columns login (=email address), pw, erp_key.
- it's read-only so can't store passwords
- the key column (named 'login') uses the ERP system's key (as email addresses are not unique)
- there is a requirement to use email addresses as login names for the customer portal
Using a custom module based on Kernel::System::CustomerAuth::DB, I changed Auth() to return the erp_key value on successful authentication. This works for logging in.
But: when a customer logs in, goes to the preferences screen, and tries to change his password, the underlying perl code (Kernel::Output::HTML::PreferencesPassword.pm) calls Kernel::System::CustomerUser::SetPassword() to store the password - and this tries to store it in the (ERP read-only) CustomerUser source.
My particular problem aside: I can't see how this could possibly work when authentication is done via LDAP, HTTP, or RADIUS ??!
OTRS 6.0.x (private/testing/public) on Linux with MySQL database.
Please edit your signature to include your OTRS version, Operating System, and database type.
Click Subscribe Topic below to get notifications. Consider amending your topic title to include [SOLVED] if it is so.
Need help? Before you ask
Please edit your signature to include your OTRS version, Operating System, and database type.
Click Subscribe Topic below to get notifications. Consider amending your topic title to include [SOLVED] if it is so.
Need help? Before you ask
-
- Znuny newbie
- Posts: 15
- Joined: 30 Jun 2014, 14:49
- Znuny Version: 6.4.4
- Real Name: Martin Vorländer
- Company: PDV-Systeme GmbH
- Contact:
Re: Inconsistency in customer authentication?
That would of course be the solution - if the customer had a source location :-)
This customer login to OTRS really is stand-alone.
Anyway: I think I solved it, by customizing Kernel/System/CustomerAuth/DB.pm, Kernel/Output/HTML/PreferencesPassword.pm, and Kernel/System/Web/InterfaceCustomer.pm (for the 'LostPassword' feature).
Thank you all for your comments.
A general remark: i still consider this behavior inconsistent. If the system allows you to configure (taken from Kernel/Config/Defaults.pm)
I would expect that I can do just that - use a table that is not customer_user to store the passwords.
This customer login to OTRS really is stand-alone.
Anyway: I think I solved it, by customizing Kernel/System/CustomerAuth/DB.pm, Kernel/Output/HTML/PreferencesPassword.pm, and Kernel/System/Web/InterfaceCustomer.pm (for the 'LostPassword' feature).
Thank you all for your comments.
A general remark: i still consider this behavior inconsistent. If the system allows you to configure (taken from Kernel/Config/Defaults.pm)
Code: Select all
# This is the auth. module for the otrs db
# you can also configure it using a remote database # !!!
$Self->{'Customer::AuthModule'} = 'Kernel::System::CustomerAuth::DB';
$Self->{'Customer::AuthModule::DB::Table'} = 'customer_user';
$Self->{'Customer::AuthModule::DB::CustomerKey'} = 'login';
$Self->{'Customer::AuthModule::DB::CustomerPassword'} = 'pw';
OTRS 6.4.4, Ubuntu 20.04.5 LTS with MariaDB 10.3.37