[FX.php List] [OFF] SSO from another site, via LDAP w/ AD...
KFutter at sbc.vic.edu.au
Mon Oct 20 20:29:42 MDT 2014
We don’t have a separate LDAP server, as AD *is* effectively an LDAP
server. When verifying credentials against AD, you basically have to bind
against AD as that user, and if bind is successful, the user is OK,
otherwise, the credentials are invalid. If bind is successful, AD returns
all public attributes for that user, including group membership. IIRC,
PHP’s LDAP functions convert this to an array, where you might have
something like $user[‘memberof’], which itself will be an array of group
I wrote a separate login script to handle all the AD stuff (which I really
need to convert to a class!), and once it successfully returns some user
data, I write the bits I need into a PHP session for that site. Since you
can’t share these sessions across sites or servers (that I know of), it
makes it difficult to share authentication state and data.
The closest I’ve come to an idea about how to handle this is to create a
proxy database in MySQL, query-able from anywhere on our local network,
that houses authentication state and data for each resource for each user,
and is queried first before AD. If current and valid login information is
found in the MySQL database, then just set up their session as usual,
else, query AD via LDAP for authentication. While I’m pretty sure I could
make this work, it seems like a lot of work to solve what isn’t really a
big problem, and could potentially introduce all kinds of security
nightmares. Keeping auth state up-to-date and in sync could also be
Another option might be to pass some kind of encoded user token between
web resources, via GET or POST, but that’s probably even less secure, and
relies on you having control over the login functionality, as you’d have
to bypass the AD auth check. I gather you’re trying to automate it, rather
than bypass it.
On 21/10/2014 1:00 pm, "Joel Shapiro" <mail at jsfmp.com> wrote:
>Hi Kev, thanks for the reply.
>Do your website logins hit AD directly or an LDAP server?
>Do/can AD Group memberships get returned upon successful logins?
>On Oct 20, 2014, at 6:53 PM, Kevin Futter <KFutter at sbc.vic.edu.au> wrote:
>> I don¹t really see how this could be made to work securely Joel. We
>> similar set up at my workplace, where AD credentials mediate access to
>> both FileMaker databases and any local web solution requiring
>> authentication. Authentication to websites though happens entirely
>> of FM; once credentials have been verified and group membership
>> established (where relevant), access to the web resource is granted, and
>> by extension, any content pulled out of FM. We have several sites that
>> work like this, and I¹d love to know a secure way of emulating an
>> SSO-style scheme, so that once you¹ve logged into one, you¹ve logged in
>> them all. There are multiple web servers involved too, so it remains
>> firmly in the too-hard basket for us.
>> On 21/10/2014 12:38 pm, "Joel Shapiro" <mail at jsfmp.com> wrote:
>>> Hi all
>>> I've got a client using Active Directory for FM's External
>>> Authentication. They maintain AD Groups, and we use these accounts for
>>> both FMP & CWP logins. It all works well.
>>> They also use a service that's got a separate, non-FM web 'portal' that
>>> users log into with their AD credentials, using an LDAP server in the
>>> client's network. (I'll call this site ExternalSite)
>>> They would like to allow a user who's logged into ExternalSite to
>>> their CWP site(s) without having to log in again through the CWP
>>> interface. (SSO)
>>> I don't know LDAP very well. Here are my thoughts:
>>> a) It seems to me that in order to log into the current CWP sites with
>>> authentication data from ExternalSite we'd need to get the password as
>>> well as the username so that we could hit the AD server and determine
>>> user's AD Group.
>>> b) If we don't get the password from ExternalSite, we could potentially
>>> create a generic "web" account in FM and allow verified users to log in
>>> with that -- but then we woud not have access to their AD Group to
>>> determine their role, so it seems we'd need to maintain a User/Access
>>> table in FM (ugh).
>>> ExternalSite's IT says they *can* include the password in their hashed
>>> string but would rather not.
>>> Have any of you dealt with this before? Is it a bad idea to have
>>> ExternalSite include the password in their hashed string? Could there
>>> a way to get something from ExternalSite and use that to hit the LDAP
>>> server again to somehow get AD credentials? (remember, I don't know
>>> well :-P) Any other thoughts/suggestions?
>>> FX.php_List mailing list
>>> FX.php_List at mail.iviking.org
>> St Bernard's College
>> Achieving Excellence By Learning And Doing
>> Kevin Futter
>> Ph: +61392891095 | Mobile:
>> Email: KFutter at sbc.vic.edu.au<mailto:KFutter at sbc.vic.edu.au>
>> 41 Rosehill Road, Essendon, Victoria, 3040 | Ph: 03 9289 1000 | F: 9337
>>1741 | www.sbc.vic.edu.au<http://www.sbc.vic.edu.au/>
>> This e-mail and any attachments may be confidential. You must not
>>disclose or use the information in this e-mail if you are not the
>>intended recipient. If you have received this e-mail in error, please
>>notify us immediately and delete the e-mail and all copies. The College
>>does not guarantee that this e-mail is virus or error free. The attached
>>files are provided and may only be used on the basis that the user
>>assumes all responsibility for any loss, damage or consequence resulting
>>directly or indirectly from the use of the attached files, whether
>>caused by the negligence of the sender or not. The content and opinions
>>in this e-mail are not necessarily those of the College.
>> FX.php_List mailing list
>> FX.php_List at mail.iviking.org
>FX.php_List mailing list
>FX.php_List at mail.iviking.org
St Bernard's College
Achieving Excellence By Learning And Doing
Ph: +61392891095 | Mobile:
Email: KFutter at sbc.vic.edu.au<mailto:KFutter at sbc.vic.edu.au>
41 Rosehill Road, Essendon, Victoria, 3040 | Ph: 03 9289 1000 | F: 9337 1741 | www.sbc.vic.edu.au<http://www.sbc.vic.edu.au/>
This e-mail and any attachments may be confidential. You must not disclose or use the information in this e-mail if you are not the intended recipient. If you have received this e-mail in error, please notify us immediately and delete the e-mail and all copies. The College does not guarantee that this e-mail is virus or error free. The attached files are provided and may only be used on the basis that the user assumes all responsibility for any loss, damage or consequence resulting directly or indirectly from the use of the attached files, whether caused by the negligence of the sender or not. The content and opinions in this e-mail are not necessarily those of the College.
More information about the FX.php_List