|One-way trust||Users from Site A can use Site B. Users from Site B cannot access Site A.|
|Two-way trust||Users from Site A can use Site B, and vice versa.|
|Trusted site||The site that does the authentication.|
|Trusting site||The site that allows access to users from a trusted domain.|
|Transitive Trust||If Site A trusts Site B, and Site B trusts Site C, then Site A will automatically trust Site C. Conceptually this is like creating a chain of trust.|
|Intransitive Trust||If Site A trusts Site B, and Site B trusts Site C, then Site A will not automatically trust Site C.|
Varying levels of interoperability are possible:
Seamlessly logging in with OpenID requires automatic (unverified) redirection between domains.
An example of this is Opera. If you turn off 3rd party cookies (by setting the global to "Accept only cookies from the site I visit"), you can't log in with OpenID because the server script you submit to automatically (without your interaction to approve it) redirects you to the OpenID server and the OpenID server does the same to get you back.
But, you get lucky in Firefox, IE and Safari with their corresponding blocking of 3rd party cookies because they violate RFC2965 in multiple situations.
Having to use OpenID in this case does a disservice to more compliant clients.
As a workaround, in Opera, besides accepting all cookeis, you can goto tools -> preferences -> advanced -> Network and turn off Automatic Redirection. Then, you'll be able to verify and click each link you're redirected to and the cookies won't be rejected because the transactions are verified.
It should also work if you keep Automatic Redirection on and both servers generate a page with a link for you to click on so you can verify the transaction. But, there can't be any automatic redirects anywhere.
Logging in with just a username and password where you're only dealing with first party cookies would be much better in this case.
OpenID is still cool though and I guess Opera just needs an option to allow unverifiable transactions between SO and your OpenID server so that you can use "Accept only cookies from the sit
|Name||Ease of use||Security||Remembers information||Multiple profiles||Anti-phishing measures||Password protected|
LDAP is really just a database-access protocol, with security and distributed-system features built in. I believe RFC 3377 is the most recent relevant standard. Most LDAP directories are used to keep track of people; therefore there is an InternetOrgPerson type which (if I remember rightly) has the following attributes by default:
However, LDAP types are extensible, so you could create a new type to represent employees, inventory, or even projects, or you could extend an existing type. For instance, you might want to add some of the following to InternetOrgPerson (if they're not already there):
It's even possible to use an SQL or legacy-system database as a backend for OpenLDAP with some custom coding, although I'm sure a lot of people who use it don't bother. So that's what's in the directory. You might still ask, "what is it used for?"
Firstly, Windows, Netware, Solaris and Linux can all be told to get their login information from an LDAP directory. This means that (if it works) someone only needs one account in an organization, that their Windows password is automatically the same as their Unix password, etc. It does not mean that they need to use the same home directory on all systems; but home directories can be automatically created by login scripts. NIS+ was a Unix-only way to distribute just the information found in /etc/passwd; LDAP is cross-platform.
Secondly, some E-mail clients (specifically Netscape, its derivatives, and Outlook; I don't have experience to speak for others) can treat an LDAP directory as an extension of the address-book. That sure beats running down the hall and referring to a printed list every time you want to e-mail someone or call them on the phone and only remember their name.
Overall, I would say that I left this book with little new information. People that are just now installing OpenLDAP may find the book beneficial, but I really didn't see any material that stood out. My personal belief is that this "Deploying OpenLDAP" needs to provide far more troubleshooting and example deployment scenarios and less regurgitation of manpages and HOWTOs
Novell eDirectory (formerly NDS) is a technically brilliant tour de force. It's a really amazing package; multimaster replication; multimaster schema changes; extremely efficient over slow links, unbelieveably secure (and has some really sophisicated extensible authentication systems), works on every platform under the sun, the APIs & developer tools are extremely mature, scales like crazy and runs super-fast, and like the previous poster said, it's CHEAP.
Anything else, to me, is a weak imitation--but I guess as long as your directory speaks LDAP all is well. Unless it's Active Directory--which is really just a set of "nested" domains with automated trust relationships. And that part makes it a huge pain in the ass to maintain. (The trick to this is to throw an AD domain into eDirectory and have eDirectory manage the whole thing - it is so flexible it can manage _other directories._)
In many ways eDirectory is far more sophisticated. It is more close to a true X500 directory and it has some very sophisticated tools for data replication and management. The admin console is streets ahead of the old Netscape Java Console for starters and the APIs are very well developed. It is very easy do do operations such as prune and graft on the Novell Directory than on the typical standalone LDAP directories (Open LDAP, SUN ONE) where you have to essentially delete and recreate the entry rather than just modify the base DN.
One key differentiator is replication strategy. eDirectory and Microsoft AD are genuine multi-master directories, you can configure them to accept updates anywhere and the data then replicates among the cloud of replicated servers. Open LDAP and Netscape's LDAP are have pyramid structure replication, you update a master, it updates slaves and these can update further consumer servers. This approach can have some advantages if you want to secure updates and be able to take a consistent snapshot of your data at a particular point in time.
IBM has licensed its enterprise-class LDAP directory server software free of charge for over 5 years now. It's currently under the Tivoli brand, going as the IBM Tivoli Directory Server v6.0.
Not only does it pack all the bells and whistles of other enterprise LDAP directories, such as multimaster and cascaded replication models, but instead of flat files it *includes* IBM DB2 UDB enterprise edition database (also licensed free of charge) for its data storage. I've seen the comparative test results, and nothing touches this solution for performance and scalability.
It runs on just about anything, too...including Linux on non-x86 hardware.
Honestly, I cannot imagine why anyone would want to run a FOSS equivalent Active Directory. After having spent months in setting up a full mixed Windows/Linux environment (OpenLDAP, Kerberos, Samba, the works), I can say that setting up AD is a breeze: for me, it is a prime example where Microsoft took existing technologies (LDAP, DNS, Kerberos) and actually turned it into something useful without the typically associated configuration nightmares. And it works very stable indeed.
And please, cost is not a reason for not going with Active Directory. The cost of a single Windows Server license is absolutely peanuts compared to what *you* cost your employer. The operational costs are what matter in long term and I am pretty confident that Microsoft's AD will do much better than that for the years to come.
The costs for AD/Exchange, etc. pale in comparison to the administrative salary costs associated with supporting an IT infrastructure and the lost productivity costs of down time.
I've found Samba in a Domain environment to be kind of flaky, and while it's useful for accessing the file system on a Linux server (though I prefer scp) there's no way I would look at replacing any Windows file server that had an SLA with a Samba server. The licensing costs for a Windows server (especially virtualized) are negligible.
On the other hand, there's still no great solution for something similar to AD on Linux. NIS+ is old and sucks. Going through the whole LDAP rigmarole only gets you part of the way and requires a hell of a lot of upkeep depending on the server. Winbind against AD isn't bad though again it's flaky and requires way too much work to setup. I supposed there's the tried and true method of rsync-ing passwd, group and shadow files around.
The combo of AD and Group Policy is pretty killer, It would be really nice to see something similar for Linux, or at the very least improved AD integration would be awesome.
Really, you need to add kerberos to the mix, especially the heimdall kerberos implementation is attractive, since it allows you to store its settings inside the ldap tree, providing a true centralised secure single signon enviroment.
Using ldap itself is really not much better than using NIS, aside from the fact that it can contain much more than just the user database.