[prev in list] [next in list] [prev in thread] [next in thread] 

List:       forgerock-openam
Subject:    Re: [OpenAM] OpenAM authenticating against LDAP using custom attributes
From:       Andy Cory <Andy.Cory () kcom ! com>
Date:       2016-08-07 15:34:23
Message-ID: BD3593802EE5EE44883831A34EE1A440A576DB () KCOMEXMBX02 ! kcom ! com
[Download RAW message or body]

Thanks Ian. So the ‘obvious missing thing' isn't in OpenAM config, but in my \
understanding of how the simple mode bind works. OpenAM (as the client) passes some \
credential values and it's up to the LDAP server against which attributes it matches \
the password sent in based on its own internal ‘knowledge'.  That's probably a \
piece of LDAP 101 that I should have known, but didn't – thanks for filling in the \
gaps!

Andy

On 07/08/2016, 15:03, "openam-bounces@forgerock.org on behalf of Ian Packer" \
<openam-bounces@forgerock.org on behalf of ian.packer@forgerock.com> wrote:

    Hi Andy,

    >  I may be missing something blindingly obvious, but I could see a way to set \
OpenAM to authenticate against an LDAP and specify which attribute to use for \
authentication, since the password isn't stored in userPassword. (I have the same \
problem with the service account with which OpenAM should bind in the first place; \
the service accounts I could use that already exist in this LDAP also don't store \
passwords in userPassword.)

    OpenAM uses a 'simple mode' BIND operation to perform the
    authentication against LDAP (for both service account and when using
    LDAP/DataStore modules).

    The reason you can't find a 'userPassword' configuration for this is
    that there isn't one, the LDAP client doesn't specify a password
    attribute, it's simply passing an optional DN and optional password as
    per the spec. It's entirely up to the LDAP server to choose what it
    does with this (for example, in OpenDJ you can change the actual
    password attribute matched against via the password policy mechanism).

    If you want to authenticate users based simply on the attribute values
    stored in an LDAP server (but not using the BIND operation) then you'd
    need to write a custom auth module to carry out that logic.

    Regards,
    Ian Packer

    On Sun, Aug 7, 2016 at 2:39 PM, Andy Cory <Andy.Cory@kcom.com> wrote:
    > Hello all
    >
    >
    >
    > It would greatly ease one of the problems we have to solve on a particular
    > project if we set up a realm in OpenAM in which the end users authenticate
    > against a (non OpenDJ) LDAPv3 over which we do not have control. This would
    > just be for username/password authentication over the /authenticate REST
    > endpoint, no further profile attributes are required. It sounds simple, but
    > the username and password that the end users use to authenticate against the
    > LDAP in other contexts are the cn attribute and a custom password attribute
    > belonging to a custom object class. I may be missing something blindingly
    > obvious, but I could see a way to set OpenAM to authenticate against an LDAP
    > and specify which attribute to use for authentication, since the password
    > isn't stored in userPassword. (I have the same problem with the service
    > account with which OpenAM should bind in the first place; the service
    > accounts I could use that already exist in this LDAP also don't store
    > passwords in userPassword.)
    >
    >
    >
    > I can't believe this is a unique requirement, I'm much more able to believe
    > I've missed something – any advice?
    >
    >
    >
    > Regards,
    >
    > Andy
    >
    >
    >
    >
    >
    > This email has been scanned for all viruses.
    >
    > Please consider the environment before printing this email.
    >
    > The content of this email and any attachment is private and may be
    > privileged. If you are not the intended recipient, any use, disclosure,
    > copying or forwarding of this email and/or its attachments is unauthorised.
    > If you have received this email in error please notify the sender by email
    > and delete this message and any attachments immediately. Nothing in this
    > email shall bind the Company or any of its subsidiaries or businesses in any
    > contract or obligation, unless we have specifically agreed to be bound.
    >
    > KCOM Group PLC is a public limited company incorporated in England and
    > Wales, company number 02150618 and whose registered office is at 37 Carr
    > Lane, Hull, HU1 3RE.
    >
    >
    > _______________________________________________
    > Visit the OpenAM forum at https://forgerock.org/forum/fr-projects/openam/
    > OpenAM mailing list
    > OpenAM@forgerock.org
    > https://lists.forgerock.org/mailman/listinfo/openam
    >
    _______________________________________________
    Visit the OpenAM forum at https://forgerock.org/forum/fr-projects/openam/
    OpenAM mailing list
    OpenAM@forgerock.org
    https://lists.forgerock.org/mailman/listinfo/openam






This email has been scanned for all viruses.

Please consider the environment before printing this email.

The content of this email and any attachment is private and may be privileged. If you \
are not the intended recipient, any use, disclosure, copying or forwarding of this \
email and/or its attachments is unauthorised. If you have received this email in \
error please notify the sender by email and delete this message and any attachments \
immediately. Nothing in this email shall bind the Company or any of its subsidiaries \
or businesses in any contract or obligation, unless we have specifically agreed to be \
bound.

KCOM Group PLC is a public limited company incorporated in England and Wales, company \
number 02150618 and whose registered office is at 37 Carr Lane, Hull, HU1 3RE.

_______________________________________________
Visit the OpenAM forum at https://forgerock.org/forum/fr-projects/openam/
OpenAM mailing list
OpenAM@forgerock.org
https://lists.forgerock.org/mailman/listinfo/openam


[prev in list] [next in list] [prev in thread] [next in thread]