Skip to content

Comments

Adding a sample file to do LDAP authetication #24

Open
daviddpd wants to merge 5 commits intomanuelkasper:masterfrom
daviddpd:master
Open

Adding a sample file to do LDAP authetication #24
daviddpd wants to merge 5 commits intomanuelkasper:masterfrom
daviddpd:master

Conversation

@daviddpd
Copy link

@daviddpd daviddpd commented Aug 7, 2017

Just a simple example for doing LDAP authentication via BINDing as the user to LDAP server.

issue a token verifcation fail on badip, but just log it.

Going to be required for clients and login servers that get
dual stacked IPv4/IPv6, but app servers that still might be
v4 only.

Also, issues with NAT/VPN, when using accross a mixed network
and split DNS setups.
ldap_set_option($ldap,LDAP_OPT_PROTOCOL_VERSION,3);
ldap_set_option($ldap,LDAP_OPT_REFERRALS,0);

$success = FALSE;
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This line seems to be redundant.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed stray line with ba5f6ca

@manuelkasper
Copy link
Owner

Thanks for the LDAP sample! The login server can simply omit the "cip" key to skip the IP check (see description of "cip" key on https://neon1.net/mod_auth_pubtkt/install.html). Do you have a scenario where a TKTAuthDisableCheckIP option is still needed despite this?

@daviddpd
Copy link
Author

daviddpd commented Aug 3, 2019

Thanks for the LDAP sample! The login server can simply omit the "cip" key to skip the IP check (see description of "cip" key on https://neon1.net/mod_auth_pubtkt/install.html). Do you have a scenario where a TKTAuthDisableCheckIP option is still needed despite this?

Sorry for a two year delay ... last job was busy, and picking this back up as a hobby.

TKTAuthDisableCheckIP is needed int multiple cases.

  1. I had multiple buildings, and multiples users, NATing via Juniper SRXes. To handle the, multiple IPv4 addresses were leveraged, and a user could, in theory, auth over one public IP, and access the needed SSO protected resource via another.
  2. IPv6 in dual stack. If the ticket was gotten via IPv6, but the resource was accessed via v4, then Tickets could get caught in a loop. With things like Happy Eyeballs, et al, there is no guarantee a dual stacked resource and client would be consistent durning even a single tasks with a protected web resource.
  3. Mobile. Phones or LTE modems, laptops, etc, bouncing between WiFi and LTE/Cell, maybe jump IPs. This could be problematic for users, say in Redmine or other ticketing systems, if this happens in the middle of an update or workflow.

With TKTAuthDisableCheckIP, really need some sort of browser unique ID, something that can't be spoofed. But I don't think something like this exists. Or some side-band relay. Sort of like a VPN, but proxying a cookie or NONCE or something, but unclear how exactly how. (Header injection with a local SOCK proxy?). I'm totally open to implementing one of these, but seems to be counter the idea and my attraction to this module as being extremely simple.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants