I am in the preparation phase of testing an application that will be using LDAP for user authentication. What are some tips or advice you might have for this endeavor?
I don't have a great understanding of LDAP but I believe all that will be used is the application client calls to LDAP with a username and sees if the password matches. Is that an accurate description? Also, what are some edge cases to test? Thanks.
LDAP authentication is often (but not always) a 2-step process: first the application does an LDAP query to locate the "distinguished name" (dn) of the account the user's trying to authenticate to, then it tries to log in ("bind", in LDAP parlance) as that dn, using the user-supplied password.
If the "bind" attempt works, the application knows the password is correct. (The LDAP server is likely not configured to allow the application to actually extract the password and do the comparison itself, for obvious security reasons).
An LDAP-enabled application will typically require a way to configure:
hostname/port of LDAP server
search base (e.g., dc=mycompany,dc=org)
user search filter (e.g. "(|(cn=%userid)(mail=%userid))")
application credentials for the initial LDAP query (unless the server allows anonymous queries)
You will most likely need to support SSL, so you don't send the user's password to the LDAP server in cleartext.
This strongly depends on your technology.
If you are directly querying the ldap you have to care about performance e.g. how fast are your queries, how often you have to do them and if you server is sized appropriately.
If you are using some kind of container that it providing SSO then these will usually have some caching features, etc.. There you have to check if everything is working properly.
You would need ldap_connect and ldap_bind functions. Also once you are binded with the ldap server you can search for entries on the ldap and get the user information.
You should surely check if encodings are handled properly (try umlauts or other weird stuff in passwords).
And take care to test with the LDAP servers you care about, Active Directory, OpenLdap, Apaches LDAP Server, and a few others, they might show different behaviours.
Also check if the client handles 'referrals' correct, e.g. when you try to lookup users in a different domain (e.g. two AD forrests with forrest trust installed).
Related
So i'm tasked with implementing SSO for our Windows application. Currently, after a user logs into the machine, he or she has to re-log in to our app when he or she loads the application. The application validates the user by querying a LDAP server.
What we're looking to have is for the user to automatically be logged into the app when they click on it. My understanding is that the LDAP authentication must still happen, but Im not exactly sure what the workflow would be, and how exactly we can validate a user without requiring them to re-enter a username / password. Note that this is not a web application so I can't use tools like SAML or OAuth (unless i'm mistaken about this too..?)
So my specific question is as follows:
Is it possible to use LDAP for SSO, and if so, how? Is it possible for me to authenticate a user with just his or her username, or is a password also required?
Any guidance would be appreciated, and am happy to provide further clarification if needed.
First of all, LDAP is a protocol, which you use to communicate with databases that implement this protocol.
So LDAP databases (commonly called directories) are ... databases and so do not provide SSO functionality.
To deploy a SSO solution, you need a SSO service. All your applications will have to be "compliant" with this service in a way or another.
The only way I can think of to make a "Windows SSO" without adding a third party application is that the applications can retrieve NTLM informations in requests made by the client and uses the user data to identify him. (but in term of security, I let you judge what you think about it ;) ) . See this php example
Some LDAP implementations, including OpenLDAP, provide some level of support the Generic Security Service Application Program Interface (GSSAPI) or SPNEGO (a specific GSSAPI implementation)
Although not trivial, it is possible to perform SSO from a "browser" that supports GSSAPI. AFIK, IE, Firefox, Safari and Chrome all provide some level of support for GSSAPI although each browser requires specific configuration (typically whitelisting of Servers).
There are many SSO Products that implement these features in a "probably" more secure and easier process than doing it yourself.
There are many known vulnerabilities details that have been exploited with GSAPPI/SPNEGO typically due to implementation issues.
I read some blogs about the LDAP integration in liferay and understood that LDAP is a Lightweight Directory Access Protocol for accessing and maintaining distributed directory information services over an Internet Protocol (IP) network.
Also it is mainly for user authentication.
Still I am blind in my mind where exactly and in which scenarios do we need to use the LDAP?
Can anyone please explain this in brief with simple real time example.
Liferay as a portal platform also keeps track of user identity. If you have your existing user database already in LDAP (because that's what has been established as a standard) you probably don't want to recreate it in the portal. In fact, many other applications might need this data as well and they all connect to LDAP (again, because that's the standard format).
Thus Liferay allows you to tap into the standard as well.
If you don't have your users in LDAP yet, you might not need to bother. If you start with the user database in Liferay and it grows large, needing to be shared with many other applications, you might want to migrate to LDAP later. And, funny enough, there's also a plugin (EE only) to Liferay that publishes Liferay's user database in the LDAP format. But now we're going quite meta.
We have number of intranets sites, hosted in web logic server, each have its own authentication framework. Now we have a new requests to implement the single sign on. There is another team who are communicating with active directories [pass the domain name and username like phillip_r and it will return the primary email etc], how do I utilize , I read few article about CAS, Kerbos etc and now I more confused do I need to implement them in my case or not, please help me on this, as I don't know where to start.
WebLogic is not 'kerberized' so you can not actual use Kerberos. However you can use WebLogic's SPNEGO handler to provide 'auto-login' from user perspective this is like 'single-sign on' but actually it's only 'auto-login'. The Kerberos token provided via SPNEGO typically has 'userpricipalname#REALM' ... that can be email address, but most of the time it's not email. It will not return arbitrary attributes from AD... you have to do this own your own (e.g. via LDAP).
However Kerberos via HTTP (SPNEGO) only works for enterprise clients, which can directly communicate with the Key Distribution Center (AD KDC).
CAS or OpenAM (http://openam.forgerock.org) are web-based, java-based single sign on systems which offer different means for authentication.
As long as all apps are on Weblogic and all users are in AD domain, you can use Kerberos SSO for all of them with no problem and don't need CAS. Set it up using instructions from Oracle.
One of our customer will switch the authentication from LDAP to integrated Windows authentication(IWA). But I don't know exactly what the differences are between them in a programmer's view. How does integrated Windows authentication work? What are the advantages using IWA over LDAP?
Windows authentication is OS-based authentication which involves Windows' verification of user supplied principal (e.g., username, ID, etc.) and credentials (e.g., password, biometrics data, etc.) against its user registry, which is probably local. LDAP is a protocol (and an IETF standard) that defines elements, controls, and operations to access directory services. One of the LDAP operations is called a "bind" which can be "simple" or "SASL." Simple LDAP binds can be anonymous, unauthenticated, and authenticated (i.e., distinguished name and password). The result of an LDAP "authenticated bind" or "SASL bind" is what you called "generic LDAP authentication." Please see RFC 4511 and 4513 for more on how LDAP "bind" works. Local OS authentication is probably faster and more reliable (in terms of high availability as the user registry is locally stored and always available). However, OS user registries are not easy to maintain and extend if the number of users is large. An LDAP directory service can act as a single, authoritative user registry for thousands of users and can be accessible to many applications, middleware, and systems (h/w and/or OS) without requiring proprietary libraries or access schemes. Many OS' can be configured including Windows to use an LDAP directory as their user registry for more efficient identity management.
One more reason can be:
To authenticate Mac and Linux users in the organization we cant use windows authentication
I have a web application (PHP, but doesn't matter). It uses LDAP for authentication (already working), and it allows users to search LDAP (already working).
But when searching, I use a generic process account to bind() and then run the search().
What I would like is to use the LDAP account that logs in to be the same account that binds for the searching. But the only way I see to do that is to store the user's credentials in the sessions (bad!).
Nutshell: can I get a "state/session/??" token from LDAP, to bind() and then search() on subsequent http requests?
(btw, using Active Directory.)
Basic LDAP doesn't provide anything like this. The credentials that you present when binding are used for the rest of the connection, so if you could keep an LDAP connection open across multiple HTTP requests (and share LDAP connections among however many server jobs you have running), then you could avoid saving credentials.
There are various extensions to LDAP floating around (including several within Active Directory), so it's possible that one of those adds sessions-across-connections, but if so, I'm not aware of it.
As a sort-of-workaround, because Active Directory supports GSSAPI and because of how Kerberos works, you ought to be able to use the user's credentials to request a Kerberos ticket for accessing LDAP then store that ticket as your "state/session/??" token. This Kerberos ticket would only be valid for accessing LDAP and would auto-expire, so this would avoid the pitfalls of storing the user's credentials in the session. I don't know if your LDAP library supports GSSAPI and would give you enough control to do this or not.