Inconsistency in customer authentication?

[martinv2]

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

[artjoms15]

providing a new table that maps customer email addresses (= login name) to CustomerKey values and stores the passwords

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?

You won't edit the data in your ERP, but in the new table.

[martinv2]

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

• 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

I set up Customer::Auth to use a table different from customer_user with columns login (=email address), pw, erp_key.
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 ??!

[martinv2]

My particular problem aside: I can't see how this could possibly work when authentication is done via LDAP, HTTP, or RADIUS ??!

Never mind... I just saw this code in Kernel::Output::HTML::PreferencesPassword::Param()

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;

So I'll clone Kernel/Output/HTML/PreferencesPassword.pm and modify it to store the password in the correct place...

[crythias]

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

• 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

I set up Customer::Auth to use a table different from customer_user with columns login (=email address), pw, erp_key.
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 ??!

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]

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)

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';

I would expect that I can do just that - use a table that is not customer_user to store the passwords.