FAQ
Hi,

I've been playing around with the LDAP stuff in Catalyst, we have a need to
share user data externally for authentication reasons and currently believe
LDAP is a good solution for this.

To this end I've got C:P:Auth:Store:LDAP correctly authenticating users
against a LDAP database. I've also got C:Model:LDAP pulling users out of the
DB so that we can display names next to user-submitted content.

Now to get to this stage I've got two lots of configuration, and effectively
two chunks of code doing very similar jobs. I now need to add a custom
method, and can't see anyway outside of doing it twice.

Next up I want to link my DBIC schema to the LDAP stuff so I can
automatically inflate users, however on this project we have some chunks of
code that work outside Catalyst using the same schema, so I can't link them
to the Catalyst Model. Ideally what I need here is some kind of generic ORM
layer, an a thinner Catalyst Model which uses it.

So anybody else got any experiences to share here? Is there some easy way to
achieve what I want that I've missed? Anybody got code to share?

Thanks

Carl

Search Discussions

  • Carl Johnstone at Jan 24, 2008 at 3:30 pm
    Oh another LDAP subject that I meant to mention - LDAP Injection. It's
    something that's been mentioned regarding our use of LDAP.

    For example C:P:Auth:Store:LDAP suggests using a filter like:

    (&(objectClass=posixAccount)(uid=%s))

    Then does:

    $filter =~ s/\%s/$replace/g;


    Which on a casual glance would seem to be a possibility for a LDAP-injection
    attack.

    The problems due to SQL Injection are well known and nobody would write
    similar code to interact with a DB. However there seems to be little in CPAN
    that acknowledges the risks of LDAP Injection.

    I suspect that Net::LDAP doesn't help here, there is a reference to making
    use of Net::LDAP::Filter to specify queries that will be properly escaped -
    however there isn't an example in the POD (hell I glanced at the source and
    couldn't be entirely sure).

    So again is this an area that anybody has considered and has some experience
    to share?

    Thanks again,

    Carl
  • Knut-Olav Hoven at Jan 24, 2008 at 3:42 pm
    use Net::LDAP::Util;

    my $escaped_search = Net::LDAP::Util::escape_filter_value($search);

    On Thursday 24 January 2008 16:30:10 Carl Johnstone wrote:
    Oh another LDAP subject that I meant to mention - LDAP Injection. It's
    something that's been mentioned regarding our use of LDAP.

    For example C:P:Auth:Store:LDAP suggests using a filter like:

    (&(objectClass=posixAccount)(uid=%s))

    Then does:

    $filter =~ s/\%s/$replace/g;


    Which on a casual glance would seem to be a possibility for a
    LDAP-injection attack.

    The problems due to SQL Injection are well known and nobody would write
    similar code to interact with a DB. However there seems to be little in
    CPAN that acknowledges the risks of LDAP Injection.

    I suspect that Net::LDAP doesn't help here, there is a reference to making
    use of Net::LDAP::Filter to specify queries that will be properly escaped -
    however there isn't an example in the POD (hell I glanced at the source and
    couldn't be entirely sure).

    So again is this an area that anybody has considered and has some
    experience to share?

    Thanks again,

    Carl


    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/


    --
    Knut-Olav Hoven
    Systemutvikler mob: +47 986 71 700
    Linpro AS http://www.linpro.no/
  • Gavin Henry at Jan 24, 2008 at 8:55 pm
    <quote who="Carl Johnstone">
    Oh another LDAP subject that I meant to mention - LDAP Injection. It's
    something that's been mentioned regarding our use of LDAP.

    For example C:P:Auth:Store:LDAP suggests using a filter like:

    (&(objectClass=posixAccount)(uid=%s))

    Then does:

    $filter =~ s/\%s/$replace/g;


    Which on a casual glance would seem to be a possibility for a
    LDAP-injection
    attack.
    It doesn't matter, it will get rejected as a bad filter:

    [ghenry@suretec ~]$ ldapsearch -x
    "(&(objectClass=posixAccount)(uid==&234%20%/ad%%%%)$1\\))"
    # extended LDIF
    #
    # LDAPv3
    # base <dc=suretecsystems, dc=com> (default) with scope subtree
    # filter: (&(objectClass=posixAccount)(uid==&234%%%%%)\))
    # requesting: ALL
    #

    ldapsearch: ldap_search_ext: Bad search filter (-7)

    The problems due to SQL Injection are well known and nobody would write
    similar code to interact with a DB. However there seems to be little in
    CPAN
    that acknowledges the risks of LDAP Injection.

    I suspect that Net::LDAP doesn't help here, there is a reference to making
    use of Net::LDAP::Filter to specify queries that will be properly escaped
    -
    however there isn't an example in the POD (hell I glanced at the source
    and
    couldn't be entirely sure).

    So again is this an area that anybody has considered and has some
    experience
    to share?

    Thanks again,

    Carl


    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive:
    http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/
  • Jonathan Rockway at Jan 24, 2008 at 3:40 pm

    "Carl Johnstone" <catalyst@fadetoblack.me.uk> writes:

    Hi,

    I've been playing around with the LDAP stuff in Catalyst, we have a
    need to share user data externally for authentication reasons and
    currently believe LDAP is a good solution for this.

    To this end I've got C:P:Auth:Store:LDAP correctly authenticating
    users against a LDAP database. I've also got C:Model:LDAP pulling
    users out of the DB so that we can display names next to
    user-submitted content.

    Now to get to this stage I've got two lots of configuration, and
    effectively two chunks of code doing very similar jobs. I now need to
    add a custom method, and can't see anyway outside of doing it twice.

    Next up I want to link my DBIC schema to the LDAP stuff so I can
    automatically inflate users, however on this project we have some
    chunks of code that work outside Catalyst using the same schema, so I
    can't link them to the Catalyst Model. Ideally what I need here is
    some kind of generic ORM layer, an a thinner Catalyst Model which uses
    it.
    I haven't done exactly this, but I have used linked two outside
    databases for the purpose of "joining" them inside Catalyst. This
    ended up being very simple. I wrote a class like this:

    package MyApp::Backend::CleverName;
    use Moose;
    use MyApp::DB::Foo;
    use MyApp::DB::Bar;

    has foo_db => (is => ro, isa => 'MyApp::DB::Foo', ...);
    has bar_db => (is => ro, isa => 'MyApp::DB::Bar', ...);

    sub operation_that_needs_both_dbs {
    my ($self) = @_;
    $self->foo_db->whatever + $self->bar_db->whatever; # you get the idea
    }

    1;

    Then I used it in Catalyst like this:

    package MyApp::Model::CleverName;
    use strict;
    use warnings;

    use base 'Catalyst::Model::Factory';

    __PACKAGE__->config( class => MyApp::Backend::CleverName' );

    sub prepare_arguments {
    my ($self, $c) = @_;
    return
    {
    foo_db => $c->model('FooDB')->schema,
    bar_db => $c->model('BarDB')->schema,
    };
    }

    Then I got a Backend::CleverName whenever I said

    $c->model('CleverName')

    inside Catalyst.

    Hope this helps.

    Regards,
    Jonathan Rockway
  • Gavin Henry at Jan 24, 2008 at 8:59 pm
    <quote who="Carl Johnstone">
    Hi,

    I've been playing around with the LDAP stuff in Catalyst, we have a need
    to
    share user data externally for authentication reasons and currently
    believe
    LDAP is a good solution for this.
    Externally in your organisation?
    To this end I've got C:P:Auth:Store:LDAP correctly authenticating users
    against a LDAP database. I've also got C:Model:LDAP pulling users out of
    the
    DB so that we can display names next to user-submitted content.

    Now to get to this stage I've got two lots of configuration, and
    effectively
    two chunks of code doing very similar jobs. I now need to add a custom
    method, and can't see anyway outside of doing it twice.
    For configuration, why don't you have one set and reference it from both
    *::LDAP ??

    Or I am being dumb here?
    Next up I want to link my DBIC schema to the LDAP stuff so I can
    automatically inflate users, however on this project we have some chunks
    of
    code that work outside Catalyst using the same schema, so I can't link
    them
    to the Catalyst Model. Ideally what I need here is some kind of generic
    ORM
    layer, an a thinner Catalyst Model which uses it.
    You're pulling LDAP users into your RDBMS? Why not keep them there? If you
    are using PostgreSQL you can use dblink-ldap as a function. Might be
    handy.
    So anybody else got any experiences to share here? Is there some easy way
    to
    achieve what I want that I've missed? Anybody got code to share?

    Thanks

    Carl



    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive:
    http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/
  • Carl Johnstone at Jan 25, 2008 at 9:24 am
    Externally in your organisation?
    No to an external organisation that has been contracted by us to provide and
    host a web application. This application needs to share a single sign-on
    with applications built in-house using Catalyst.
    For configuration, why don't you have one set and reference it from both
    *::LDAP ??

    Or I am being dumb here?
    No you're right that I can combine some of the configuration and reference
    it accordingly. However I don't have a single obvious place to add an extra
    method (although J Rockway may have a hack around that).
    You're pulling LDAP users into your RDBMS? Why not keep them there? If you
    are using PostgreSQL you can use dblink-ldap as a function. Might be
    handy.
    No I've got data in my RDBMS that has a relationship to the data in my LDAP
    directory. For example "comments" are added by users, therefore the comments
    in the database have a submitter for which the details are held in LDAP.

    dblink-ldap is interesting but we're a MySQL shop. I'm also taking a look at
    DBD::LDAP on CPAN which does a similar thing in perl-land.

    Carl
  • Gavin Henry at Jan 26, 2008 at 8:16 pm
    <quote who="Carl Johnstone">
    Externally in your organisation?
    No to an external organisation that has been contracted by us to provide and
    host a web application. This application needs to share a single sign-on
    with applications built in-house using Catalyst.

    Ah, ok. What Directory server are you using btw?
    For configuration, why don't you have one set and reference it from
    both *::LDAP ??
    Or I am being dumb here?
    No you're right that I can combine some of the configuration and
    reference it accordingly. However I don't have a single obvious place to
    add an extra
    method (although J Rockway may have a hack around that).
    Sounds good.
    You're pulling LDAP users into your RDBMS? Why not keep them there? If you
    are using PostgreSQL you can use dblink-ldap as a function. Might be
    handy.
    No I've got data in my RDBMS that has a relationship to the data in my LDAP
    directory. For example "comments" are added by users, therefore the comments
    in the database have a submitter for which the details are held in LDAP.

    dblink-ldap is interesting but we're a MySQL shop. I'm also taking a look at
    DBD::LDAP on CPAN which does a similar thing in perl-land.
    Understood.
    Carl


    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive:
    http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/
  • Carl Johnstone at Jan 28, 2008 at 5:16 pm
    From: "Gavin Henry" <ghenry@perl.me.uk>
    Ah, ok. What Directory server are you using btw?
    openldap

    Carl
  • Gavin Henry at Jan 29, 2008 at 12:00 am
    <quote who="Carl Johnstone">
    From: "Gavin Henry" <ghenry@perl.me.uk>
    Ah, ok. What Directory server are you using btw?
    openldap
    Ok. If you're using a recent version you can use back-sql and make certain
    db tables available via LDAP. It's not the best design decision you could,
    but an option if you're really stuck:

    http://www.openldap.org/software/man.cgi?query=slapd-sql&apropos=0&sektion=0&manpath=OpenLDAP+2.4-Release&format=html

    Only do it if you have no other option.

    Gavin.
    Carl


    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive:
    http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcatalyst @
categoriescatalyst, perl
postedJan 24, '08 at 3:05p
activeJan 29, '08 at 12:00a
posts10
users4
websitecatalystframework.org
irc#catalyst

People

Translate

site design / logo © 2022 Grokbase