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.
Related
We have a self-developed proprietary user management and self-developed Single Sign-on. (OpenID Connect wasn't born at that time)
Our authentication server and our thick clients are in a private network, without internet access.
The task is to integrate a third-party thick client - its users should authenticate against our existing authentication server.
The general idea is to use an existing future-oriented framework which offers a standard authentication interface (like Keycloak?) and implement our own OpenID Connect authentication provider (or User storage SPI for keycloack).
Is the way with keycloack and User storage SPI recommendable or are there better approaches?
As you say, this is a good choice for meeting your immediate requirements:
External client uses a modern OpenID Connect flow - eg OIDC for desktop apps
It connects to an Authorization Server with support for standards based endpoints
Authorization Server has extensible support for data sources and can potentially reach out to your existing user data source
As an example, Curity, where I work, supports multiple data sources and there is a free community edition if useful.
Any provider that meets the same requirements would be fine though - and I've heard some good things about Keycloak.
LONGER TERM
It makes sense to then gradually update other apps to use modern OAuth and OIDC behaviour.
At a suitable point it is worth making the Authorization Server the only place from which Personally Identifiable user data is accessed, and moving the storage there. See this data privacy article for some advantages of this.
I can vouch for Keycloak User Storage SPI approach. Recently implemented this for a project and it is working pretty well. For any existing user-database I highly recommend it.
I found some example source on github that you could look at (although needed some modification to run it):
https://github.com/mfandre/KeycloakSPI
I have also written an article summarizing my findings working with Keycloak in case you're interested in other features:
https://dev.to/kayesislam/keycloak-as-oidc-provider-42ip
It's extremely customisable.
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 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 an organization with several hundred internal users in Active Directory. We have some of our computer systems integrated with AD but have many disparate web applications scattered through the organization that have separate authentication and authorization mechanisms.
In addition, we have about 60K external users who will eventually be able to log into and use some of the aforementioned web applications (albeit with different permissions most of the time). These users will not be in AD, but some other data store (probably just a database table that would be maintained as part of some other processes we have in the company). The application should be flexible in the data stores it can authenticate against.
We are looking for a centralized authentication and authorization system that we can tie the web apps to. On the authentication side of things, we are working towards Single Sign-On (SSO). For the authorization side of things, we would like a centralized location where we can assign application permissions to users or groups of users. Bonus points for permission "groupings" or "templates" which would allow further organization.
We have looked at Atlassian's Crowd, which seems ideal for authentication, but the authorization side is bleak.
The mechanism by which the web applications would communicate with the central auth server must be standards based and easy to implement in many different platforms (ASP classic, .NET, php, Python, Java).
So, the specific question is: Do you know of any open-source or proprietary software that will function as both a centralized authentication and authorization server as discussed above? Or, do you know of any software that might do centralized authorization and integrate well with other centralized authentication applications.
I found this question which is a year old and doesn't seem to have a answer. I am hoping this time around, a solution can be found: Centralized Authentication and Authorization for several Web Services
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.