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.
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.
Problem Statement:
I am trying to build a custom management system which would require authentication and authorization both.
The system needs to have capabilities to manage/create/update/delete users, roles, permissions and groups.
My Design Solution
I am planing to implement this in-house from scratch and would provide authentication and authorization as follows.
Authentication : user would provide their credentials and the system would authenticate if the user is valid or not.
Authorization: once the user is authenticated, based on the user groups and the permissions they could access the requested pages on the site.
Question:
Now, my question is that suppose I have this application built successfully and in future my application requires LDAP (active directory) authentication would it be possible to plug in LDAP related features keeping my existing application intact or I would have to re-write the entire or most application using LDAP API's.
I have had a look at at apache shiro and spring security which
provides LDAP functionality and they also provide capabilities to manage/create/update/delete users.
As of now I have not yet decided if I would go with either of them or write my own.
Would appreciate if I could get a detailed reponse about how to go about things.
Note:
I am a complete newbie to LDAP so please excuse me if I have used some wrong terminology with regards to LDAP.
I would recommend NOT implementing this your self, just integrate with existing API.
Disclosure: I work for Stormpath (which provides exactly this) and on Apache Shiro.
Also, if your application needs to be backed by LDAP, most LDAP setups I've seen only support read operations when integrating with applications, so you may want to chat with your LDAP admin and see if your 'manage' user use case is viable.
Security is a serious domain, with lots and lots of hidden complications. I would definitely recommend against implementing this yourself. Since you mention Spring LDAP, I'm guessing you're in a Spring-based project. The obvious choice in such a setup would be the excellent Spring Security project.
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).
What is LDAP and why people use LDAP instead of rel. DB?
I've read some about LDAP on Wikipedia, but I'm still confused what is it.
Thank you
As you surely already know, LDAP is a particular sort of database (plus a protocol to access it) for "directory services", oriented towards mostly-read-only, hierachical, distributed scenarios. It's mostly used for authentication, authorization, searching/listing of users with their roles and data (and/or other entities) of some organizations.
LDAP is hated by many developers because of it's very idiosyncratic terminology/idioms, very different from relational databases and SQL. Many had hopes about its slow death, but the fact that Microsoft adopted it for Windows (Active Directory), among other facts, tells it's probably going to be around for some time.
When consider to use it in web applications? Assuming you are not confortable with it, only use if you have to, I'd say. That is, if you need to authenticate/interact with some existing LDAP infrastructure (AD, for example).
LDAP is used to centralize the Authentication and Authorization inside an enterprise network. If a applications has to use the existing infrastructure for Authorization and Authentication then LDAP should be used. By using LDAP you don't have to implement any other authentication logic.
From the Wikipedia LDAP page:
The Lightweight Directory Access Protocol, or LDAP (pronounced /ˈɛl dæp/), is an application protocol for querying and modifying data using directory services running over TCP/IP.
It and similar technologies are most often used in enterprise software to allow centralized management of users and related data. If multiple unrelated applications run in the same environment, using LDAP is a standard way to allow users to use the same credentials and keep system administrators sane.
I work for a company with multiple public-facing web sites.
Some of these sites are built using third party products (Moveable Type, myBB, Trac and others). We also have a couple of bespoke sites built on the Microsoft stack.
Currently, we have no unified authentication/authorisation solution; each site implements its own user store.
I'm keen to implement unified user authentication across all sites. I don't expect to achieve single sign-on (it won't be terrible if users are prompted for credentials when switching sites), but I do need each user to have a single username & password.
It seems to me that the most likely solution will be to implement an LDAP server. LDAP is supported by some of the third-party products we use, and I can amend our bespoke sites to use LDAP.
However, I've never used an LDAP store to manage external users (I've always built my own user store).
What are the pros and cons of using LDAP? Have I overlooked other options?
Thanks
Sandy
I don't have experience with OpenLDAP but as pros and cons for the ActiveDirectory-based LDAP:
Pros:
It standardised so quite often there are some binding plug-ins already;
A lot of development frameworks have support for communication with LDAP; (I've done it from PHP some time ago; .NET have a dedicated namespace for that.)
There are all necessary authentication methods and security mechanisms implemented -- passwords are stored securely, authentication with the server can be performed in a secured way if necessary;
Account lockout policy/Password history features can be enabled if needed;
AD have convenient tools for user management, also it can be scripted or accessed via API;
Users can have complex group membership;
Permissions to any object/attribute can be customized;
Directory can be distributed/replicated by adding more domain controllers.
Cons:
Deployment requires some planning;
ActiveDirectory should be regularly back-upped.
If you authenticate against Active-Directory you need a Microsoft licenses.
The license is quite expensive.
LDAP is a great way to store user information in a structured tree. The LDAP protocol also makes it readily available across the web. There are several different LDAP solutions out there but the one you choose will of course be based on your server's operating system. If you have any Microsoft sites your best bet is to go with an Active Directory or ADAM (MS). It is easier to slave a unix machine to an Active Directory than the other way around. If all of your queries will be web-based though and handled through code, then you could use any LDAP source you choose (they're all fairly complicated but with the right tools easy to administer).
LDAP by its nature is lightweight (hence the L) and fast. It's structured for heirarchical access to user information and easy to search based on all of this information. It also has support for an SSL protocol (LDAPS) which I highly recommend.
The cons are the basic heirarchical structure and the differences within the LDAP structures themselves. Active Directory is not a pure LDAP with respect to the RFC but it's close enough that it can be figured out easily.