I know that there are several similar posts available discussing the same but I didn't find the answer for my case.
I have just basic idea of LDAP which we can get through google search like it is a directory database, used for hierarchical data and optimised for reads than writes. And of course LDAP is protocol to access the database.
A little background of problem:
We have to create a presence service(publish-subscribe) for which we
have to choose between a directory based DB and an RDBMS.
The DB will be on cloud so if RDBMS is chosen it will be exposed as
a Web Service and if a directory based is chosen it will be accessed
via LDAP.
Service is a pub-sub model where each user may be a publisher with many subscriber and it may itself be subscriber. So, it is mn relationship.*
Now, I have two questions regarding the same.
Can we model this in directory based database? I looked through the
schemas but could not figure out how to do that.
Second question is regarding the approach of accessing the data i.e.
using LDAP or using web service. I don't know what are the
advantages/disadvantages of using LDAP over usage of web service.
Appreciate any help.
Thanks
Can we model this in directory based database? I looked through the schemas but could not figure out how to do that.
There isn't an existing schema for this that I'm aware of. All the schemas I've ever seen are for X.500 directory information, not messages or transactions.
I wouldn't give LDAP a moment's consideration for a publish/subscribe system. I wouldn't use a database either. I would use a messaging system, e.g. MQ.
Second question is regarding the approach of accessing the data i.e. using LDAP or using web service. I don't know what are the advantages/disadvantages of using LDAP over usage of web service.
LDAP isn't suitable anyway, and making this decision won't make it any more suitable.
Related
I have to develop a Django webapp which can handle several customers with their own databases.
Each customer should manage their different users and groups, with associated permissions and a set of Django's apps.
I need separate databases for security and scaling reasons. Moreover, each base size may exceed 200MB. Besides these dedicated databases, I need a "common" database to store data common to every customer (and must not be replicated to every customer database).
The fact is that I don't know how to handle the multiple customers databases (and keeping Django's auth capabilities for each customer independently : user/group/perms).
I found django-constance (https://github.com/comoga/django-constance) which allow to change settings on the fly, and I have in mind to auth with a customer identifier + username ; this way I may load the right DB with the customer identifier and auth on that one with the username.
Well, this solution does not seem to me so good, and I would appreciate if anybody has a better idea or if someone has already encountered this problem and found a workaround...
I have not found similar problems on the net, and that's quite annoying because that does not seem to me as unusual...
Thanks a lot for the time spent on this.
Keep It Simple -- leverage what Apache (or nginx or whatever) offers you.
Use mod_wsgi.
Use Apache (or nginx or whatever) to split the customer's URL's from each other
/cust1/path/to/resource
/cust2/path/to/resource
If you use Apache (or nginx or whatever) to split these things up, then each top-level path element can direct the request to a specific mod_wsgi instance
Each mod_wsgi instance has it's own settings.py that has the customer's specific database credentials.
Each customer settings.py should probably start with from master_settings import * so that you can have a "for all customers" settings which is extended by each specific customer.
I am considering using Solr in a multi-tenant application and I am wondering if there are any best practices or things I should watch out for?
One question in particular is would it make sense to have a Solr Core per tenant. Are there any issues with have a large number of Solr Cores?
I am considering use a core per tenant because I could secure each core separately.
Thanks
Solr Cores are an excellent idea for multitenant, particularly as they can be managed at runtime (so not requiring a server restart). You shouldn't run into too many problems with performance for having multiple Solr cores, but be aware the performance of one core will be impacted by the work on other cores - they're probably going to be sharing the same disk.
I can see why you might want to give direct API access - for example if each 'user' is a Drupal site or similar, for a shared hosting type environment. The best thing would be to secure the different URLs, e.g. if you had /solr/admin/cores, /solr/client1 for a client core, and /solr/client2 for another, you would have three different authentications, one for your admin, and one each for your tenants. This is done in the container (Jetty, Tomcat etc.), take a look at the general Solr Security page: http://wiki.apache.org/solr/SolrSecurity - you'll want to setup a basic access login for each path in the same way.
You would no more use a separate table in a database for each tenant than you would a solr core for each tenant.
If you think of a core like a database table and organize your project in such a way that each core represents an object in your problem space then you can better leverage solr.
Where solr shines in when you need to index text and then search it quickly. If you are not doing that you might as well use a relational database.
Also from your question about securing solr for each tenant , I hope you're not suggesting allowing your logged in users to access the solr output directly? Your users should not be able to directly access your solr instance.
Good luck.
That's OK .. you can not use cache(inbuild) properly and for your requirements. You add permission bit in which you can change the query component in which you can. It should work properly according to the permission. There is a bitwise operation also available for this. Make use of this for your needs.
Let's say you have many applications in your environment all of which store their connection strings to SQL Server in a web config. Is it possible to have the application retrieve those connection strings from Active Directory?
We're moving some database servers around and would like a way to have them read from a central location. Active Directory was suggested as one possibility, but we didn't know if it was possible.
This would, in theory, allow us to gradually change our applications to use AD to read the connection strings, then as we move our database servers, make one change in AD to update all the applications.
Is this possible? Maybe you have a better suggestion. Thanks!
Technically speaking, you can't store the information in LDAP since it is a protocol, not a storage mechanism. However, there is no reason (that I know of) that you couldn't store the information in Active Directory or other directory services type engine, and retrieve them with a query from the application. You would just need to come up with some organizational scheme and I would suggest some common code in a library or something that allows you to access the information.
I'm not saying that storing it in Active Directory is the best option, but I believe you should be able to do it without a problem.
We had a design to do that. Our architecture allowed multiple servers, each with multiple databases. We were using Active Directory to manage attributes about the users, including which databases they had access to.
It seemed logical design at the time, since we either had to do that or have a "master" database to direct. Using Active Directory, we no longer had a single point of failure.
Have no idea how it turned out, I left that company.
"The LDAP should be for directory information"
What does that mean? Configuration information is a perfect candidate for being stored in the Dit - it is read intensive, secure, replicated, and easy to access. Most of what is stored in Active Directory is "configuration information".
You can store the connectionstrings about anywhere you want. You could even do them as TXT records on your DSN servers. But you would have to build the resolution framework yourself. Also keep in mind that the connection strings make contain secure information. (such as passwords). If you store these in LDAP (I am speaking genericly for any ldap based server) you will want to make sure the attribute is not public. The upside is LDAP proxy accounts (anonymous connections) would not be able to see the information. The downside is you will have to do an LDAP bind before you can get the information back out of the system. As long as you cache a connection string on the client/server that is going to be making the database calls, you shouldn't see any real performace issues. But if you had to query an LDAP server before each database call you might have problems.
a custom object or even an extension attribute for an exsisting object may be best.
Extend AD Schema
You could create a non-person user and have the connection string be an attribute in the user, but, that would be misusing the LDAP, IMO.
What may be better is to use dependency injection and just have common information such as a connection string, be in one file and just have it either read in when the application starts, or have it be injected in when recompiling.
For example, you could use Spring or Spring.NET, but there are a myriad of DI frameworks that would work.
UPDATE: You could also just create a database table that has this information, and all the applications could read from the database to get all their configuration information.
An LDAP should be used for directory-related issues, I believe, as well as, now, user-management and account information.
In every larger company I worked for they used LDAP as a way to access the central repository of user information, but very few have taken efforts to extend the schema to include objectClasses that aren't derived from inetOrgPerson.
Microsoft's Active Directory makes extensive schema extensions but very few commercial products leverage the capabilities of LDAP.
Is it because most LDAP developers don't know how to model beyond users? Find value in it but just haven't thought deeply about it? Have tried it and ran into performance problems? Something else?l
I've always thought LDAP was too high level for network administrators and too low level for software developers. Neither of them seem to be confortable with it.
There is the perception that since almost every enterprise application will use a relational database, then adding one more data source lowers the availability and reliability for the application.
The barrier to make custom schemas in LDAP is still high. In LDAP servers, you have to put the schema file in the schema directory, usually with root or administrative priviledges an restart the LDAP server; whereas current ORMs can create, update or verify relational database schemas when the application gets started.
Personally I think it's because LDAP is a directory, not a database. Directories are good for looking up people and their associated data, but they're not particularly good for tracking highly relational data -- which is what a lot of the rest of our data looks like. In fact, our use of LDAP is actually as a front-end to "people"-data, merging a lot of data streams into a single directory view. We still have the "people" data in the backend databases along with the rest of our institutional data and have only chosen LDAP (in our case ADAM) as a front-end to allow convenient lookup of the merged "people" data. Now that we're moving to web services as a means of accessing this data, I'm not sure that it even makes sense to continue down the LDAP route (except to support existing services that haven't been updated).
We have done work for some companies with 65Million LDAP records an none of the records were for people.
The data was a variety of items mostly for devices including:
* DHCP
* DNS
* Mac Addresses
* Location
* SN
* Brand
* Model
* etc....
-jim
I would think that it is due to A) the complexity of working with LDAP (much higher than SQL) and B) the fact that your product would be tied completely to it. That is, it would have no market outside of large organizations running LDAP. For less money and effort, I could build an app that works anywhere.
Now, internal applications written specifically for the organization that need access to other LDAP data are a different story. But you will obviously hear less about them because they are not commercially marketed.
I thought LDAP was highly optimized for fast, frequent reads. I don't think they'd scale for transactional systems.
The relational model and its expression in SQL is a powerful thing. I don't think it will be easily supplanted by LDAP or object databases.
Closed. This question is not about programming or software development. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed last month.
The community reviewed whether to reopen this question last month and left it closed:
Original close reason(s) were not resolved
Improve this question
I often hear things like "Can we load our employee info using LDAP?" Yet, the title "Lightweight Directory Access Protocol" makes me think of it as a protocol rather than a physical database management system like Oracle or MSSQL.
So could someone please explain to me what LDAP is, how it's used, and how it basically works? Is LDAP simply a standard protocol for extracting data from a variety of DBMSs? In an architecture diagram, would LDAP be simply an arrow drawn between the DB and the application server?
LDAP is a protocol for querying user directories. For example, Active Directory or Novell eDirectory both support LDAP. It is also, to a degree a syntax for doing such queries, like how SQL is a querying language for querying databases.
An LDAP command could look like
(givenName=Mike)
And it would return all Mikes in the directory.
LDAP is usually used as authentication database. Let's say you have CMS product you sell as Software-as-a-Service. So user gets CMS and you maintain it etc.
So, you install it to examplecustomer1.com, examplecustomer2.org, examplecustomer3.net (one software per domain). Now you have THREE user databases to maintain. So you add yourself to all systems as admin and customers accounts as well.
Then you discover LDAP. You add LDAP support to your product and now you have one central database of users. You can login as admin to all systems with your own ONE username and password. CMS system still contains user database and rights for each user but username is now used as reference to LDAP database and password field is deleted from CMS database schema.
Yes, LDAP (Lightweight Directory Access Protocol) is a protocol that runs on TCP/IP.
It is used to access directory services, like Microsoft's Active Directory, or Sun ONE Directory Server.
A directory service is a kind of database or data store, but not necessarily a relational database. The structure is usually much simpler, storing hierarchical collections of name-value pairs, e.g. lastName=Smith, firstName=John.
LDAP IS a protocol, but many people I know like to overload its meaning to include "any store capable of responding to LDAP queries." Active Directory is such a store, and there are many others. It is used when architects don't really care what the store is. It's used in the same as if you were to say "Store it in the SQL" when you don't care whether it's MySql or Oracle or SQL Server.
LDAP stands for Lightweight Directory Access Protocol. This is an extensible open network protocol standard that
provides access to distributed directory services. LDAP is an Internet standard for directory services that run on
TCP/IP. Under OpenLDAP and related servers, there are two servers – slapd, the LDAP daemon where the
queries are sent to and slurpd, the replication daemon where data from one server is pushed to one or more slave servers. By having multiple servers hosting the same data, you can increase reliability, scalability, and
availability.
It defines the operations one may perform like search, add, delete, modify, change name
It defines how operations and data are conveyed.
LDAP has the potential to consolidate all the existing application specific information like user, company phone
and e-mail lists. This means that the change made on an LDAP server will take effect on every directory service
based application that uses this piece of user information. The variety of information about a new user can be
added through a single interface which will be made available to Unix account, NT account, e-mail server, Web
Server, Job specific news groups etc. When the user leaves his account can be disabled to all the services in a
single operation.
So LDAP is most useful to provide “white pages” (e.g. names, phone numbers, roles etc) and “yellow pages” (e.g.
location of printers, application servers etc) like services. Typically in a J2EE application environment it will be
used to authenticate and authorise users.
LDAP is a protocol created in response to the complexity of the X.500 family of protocols. It is intended to represent a hierarchical directory structure. The X.500 standard was originally intended to be used over a complete OSI layer stack and was created to fulfill the requirements of the telecom industry. LDAP was designed to use TCP/IP to provide similar functionality without the extra overhead. You can find information on X.500, OSI and LDAP on wikipedia. X.500 and OSI are both covered in most data communications textbooks as well.
http://en.wikipedia.org/wiki/X.500
http://en.wikipedia.org/wiki/Open_Systems_Interconnection
http://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol
What is LDAP:
All LDAP is a communication protocol which Microsoft implemented for the Active directory directory service and is used for other NTDS.DIT files. Lets get the confusion out of the way. NTDS.DIT contains Active Directory database. To ACCESS the data base you need the communication protocol LDAP. Thats it. So again NTDS.DIT is a simple database i.e ADDS Database (Active Director Directory Services) How do we access it?
We access it using LDAP.
lets use LDAP quick example.
C:/users/data.doc
or
LDAP Syntax
CN=Bob,OU=Users,DC=Youtube,DC=Com
CN = Canonical Name (object or name)
OU = Organizational Unit (Folder in Active directory)
DC = Domain Controller (Where it is)
Other info: Active directory is database based on the X.500 Standard which contains all the AD object which is the NTDS.DIT file.
LDAP is an internet protocol, which is used to look up data from a server, this protocol is used to store as well as retrive the information from the hierarchical directory structure. LDAP also follow a data model whch is hierarchical type. In simple term we can say its a hierarchical database where data is stored in tree like structure where leaf node hold the actual data.
LDAP never define how program function either on the client or server but it explain more about the type of messages that will be used to communicte between client and server. Message can be client requested information , server response and format of the data. These messages arepassed over TCP/IP protocal. So there should be some operation exist that will established a session connection and disconnect it after the operation completion between client and server. LDAP can bes used in the cased where large number of read operations and less number of write operation is required. For example User Authentication as we know that User Name and password are not change so frequently.
LDAP Operations Process
To start the communication, the client needs to create a session with a server. This process is called as binding. To bind to the server, the client has to specify the IP address or the host name and TCP/IP port-no, where the server is attending. The client can also provide credentials like username and password to ensure proper authentication with the server. Alternatively, the client can also create an anonymous session by using default access rights. Or both parties can establish a session which uses stronger security processes like data encryption.
Once the session gets established, the client then performs its intended operation on directory data. In LDAP the directory information can be managed and queried as it provides read as well as update capabilities.
The client closes the session when it finished making a request. This process is called as unbinding.
LDAP Modes
LDAP majorly relies on to the Data Models like
Information model
The directory includes the basic unit of information and it is known as entry, which represents a real-world object like servers, people and so on. Entries include collection of attributes which define information about the object. Each attribute includes Type associated with syntax, and one or more values. The following diagram illustrates the relationship between entry and its attributes and their type & value:
Naming model
The naming model of LDAP denotes how entries are recognized and organized. In LDAP the entries are organized in a hierarchical or tree-like structure called DIT (Directory Information Tree). The entries are ordered within the DIT according to their DN (Distinguishable Name), a unique name which clearly identifies a single entry.
Functional Model
LDAP defines operations requested by a client and can be divided into three categories. They are:
1. Query which is used to fetch information from a directory. Include operations like search and compare.
2. Update which is used to update the information stored in the directory. Include operations like add, modify and delete.
3. Authentication which is used to connect and disconnect with a server, create access rights and preserve information. Include operations like bind, unbind and abandon.
Security Model
In LDAP, the security model relies on the bind operation. Three different bind operations are possible according to the security mechanisms applied. They are:
No Authentication
The simplest method but could only be applied when data security isn’t a problem and where no access control permissions are tangled. For example, the directory includes the address book that can be browsable by anyone. If the user left the DN and password field empty during the bind API call, the server will automatically adopt anonymous user session, and grants access along with the corresponding access controls described for this type of access.
Basic Authentication
Basic authentication is the alternative simple security mechanism used in LDAP and it is employed in several other web-oriented protocols, like HTTP. In this approach, the client has to authenticate itself to the LDAP server by the way of entering a password and DN that is transferred in a clear text over the network. On the other end, the server compares the DN and password with the entries in the directory. And grants access if the password matches. Moreover, the passwords in clear text format can’t guarantee confidentiality; hence, may result in password disclosure to unauthorized parties.
SASL (Simple Authentication and Security Layer)
This framework has been added to LDAP V3 which adds an additional authentication method to connection-oriented protocols. This mechanism specifies a challenge & response protocol where the client and server exchange some data to ensure authentication and establish the security layer upon which the subsequent communication will be carried out. With SASL, LDAP protocol can support any sort of authentication approved upon by an LDAP client and an LDAP server.
Yes, LDAP itself usually requires a lower level DB store.
I suggest you get your hands dirty here:
If you just install OpenLDAP &
play with it... http://www.openldap.org/doc/admin22/install.html
...you will be forced to consider the dependencies.
One of which is, in this case, SleepyCat.
Have fun.
For more fun, here is a good philosophical discussion on the taxonomy:
http://archive.oreilly.com/pub/post/ldap_is_not_a_database.html
LDAP is basically a protocol to access a directory. Directory here basically refers to a directory having information of the users present in the organisation. Examples of directory include Microsoft's Active Directory (AD) and Oracle's Internet Directory (OID). The directory basically are used for implementing the single sign on feature for the organisation by centralising user authentication and authorisation. For more details refer the below links:
http://searchmobilecomputing.techtarget.com/definition/LDAP
https://eagledatagistics.com/what-is-enterprise-user-security-eus/