Thursday Sep 27, 2007
Monday Sep 10, 2007
By treydrake on Sep 10, 2007
- By default the php LDAP module is not loaded. Install it and load it; e.g., "apt-get install php5-ldap"
- The bind attribute is the entry "dn" versus the suggested "uid".
- The login attribute is the entry "uid" versus the suggested "dn".
- If the "auto create users" checkbox is checked on a successful LDAP bind the user will be created within Sugar. This feature works nicely except that givenname isn't pushed to Sugar, hence, you'll need to manually set the user's last name via Sugar admin screens. I'll file a bug...
Friday Jun 29, 2007
By treydrake on Jun 29, 2007
- Intro to OpenDS given at Jazoon '07 by Ludo
- Opends and Web 2.0 podcast featuring the talking heads Don, Brandon, and I
- All things OpenDS given at Capital Area Central Texas UNIX Society by Neil and associated podcast.
- Cool stuff with OpenDS @ Glassfishdays '07 given by Ludo
- Intro to OpenDS slides and related talk given at JavaONE by Don and I
Tuesday Jun 26, 2007
By treydrake on Jun 26, 2007
Authentication: Assertion that the user is who they claim they are; e.g., via username/passwordThe Atom publishing protocol specification recommends that servers implement a mechanism to ensure agents performing write operations are authenticated. Authentication is handled as follows:
- The user agent is prompted for credentials when an agent performs a POST, PUT, DELETE, and in some cases, a GET request
- In the typical case, a username and password or posted using HTTP BASIC
- The username and password are used to perform an LDAP bind that asserts that the user is present in the directory server and the provided password matches
- On success the principal is stored in the Atom server and a client token is sent in response for future client interactions with the server. Nothing new here.
Authorization: What resources can the authenticated user access and what can they do with them.The server leverages the underlying servlet container for coarse grained access control and the directory for fine grained control. All atompub operations are protected using container access control that, in the end, simply requires that the user belong to an administratively defined LDAP group; e.g., "atompubwriters". That is, the container simply checks that the context's principal is a member of the appropriate LDAP group. Fine grain access control is a bit more interesting. In most enterprise applications access controls must be implemented at least twice; 1) the user interface (API or GUI); e.g., locking down fields, screens, modules, etc. and 2) in the database (field, table, etc). Obviously, this is difficult to maintain and when database connection pooling is thrown in the mix correlating the "real" user and the database connection is no longer feasible since the "real" user is lost. OpenDS solves the connection pooling identity problem with the "proxy authorization control" and fine grain access control with access control instructions (ACIs). The proxy auth control enables the developer to create a connection pool with a common user, say "atomproxy", with just enough privileges to connect to the directory. When a connection is taken from the pool the proxy auth control containing the principal name is attached to the connection thus propagating the real user to the directory. The directory server, recognizing that the proxy auth control is present, uses the proxy principal versus the connection principal to determine access rights. Hence, you get the best of both worlds - connection pooling performance and preservation of end user identity. For the most part, ACI's are used to narrow or widen user access to some part of the directory information tree. In the case of the Atom syndication server ACI's are added allowing end users write access beneath their LDAP entry enabling them to add blog entries, media resources (podcasts, pictures), etc. Other ACIs are used to filter content available to anonymous users (unauthenticated searching of the Atom server). By using ACI's versus application specific access control a system adminstrator can reliably set user access permissions in a single place throughout the enterprise - the directory.
Accounting/Auditing: Record of user/resource activity; e.g., who changed what whenAccounting comes free! Out-of-the-box OpenDS provides both access and audit logging. The former captures who and what was modified and the latter the contents of the modification (the specific data changes). Further, OpenDS logging/auditing is extensible, hence custom auditing loggers can be written for domain/application specific purposes.
Wednesday Jun 13, 2007
By treydrake on Jun 13, 2007
Wednesday Jun 06, 2007
Monday Jun 04, 2007
By treydrake on Jun 04, 2007
Friday May 25, 2007
By treydrake on May 25, 2007
- Finally, there's a directory server that is lightweight, very fast (read AND write), and developer friendly - OpenDS
- The APP spec appears to be close to completion
- Facilities for search and user authorization are noticeably absent from the APP spec (that's a good thing)
- DSML (LDAP over XML) is deader than a doornail
- Think "syndicated databases"; i.e., databases queried, edited and generally mangled via feeds. I know I'm not the only one thinking about it (checkout Google GBase and Yahoo Pipes).
Atom, APP, and OpenDS
- Atom is a simple, extensible specification that describes lists of related information. In its simplest form it is no more than a blog feed.
- APP is a web-based protocol for publishing, editing and retrieving web resources; e.g., Atom documents, xhtml, images, podcast episodes, et al. APP relies on tried and true HTTP and ReST interfaces gaining it a distinct advantage over previous attempts. That is, a widely deployed infrastructure, simple to grok, and relatively simple server and client side implementations.
- OpenDS is an open source, 100% Java directory service
Why is an OpenDS based Atom server interesting?
- I have yet to see an Atom/APP implementation application that is identity aware. That is, a server that has intrinsic user knowledge with regards to roles, authorization, authentication mechanisms and user relationships
- Most certainly not file based. Resources posted and fetched are stored in the directory thus enabling synchronization, access control, search, etc.
- Powerful, ReST search based on LDAP Urls
- Built on a scalable architecture. Back-ended by OpenDS, front-ended by Glassfish application server, and written atop Java
What can you do with it?
- "Web 2.0" enable your directory. Atom is easily parsed within a web browser and for that matter any other HTTP agent. Therefore, access to the info rich directory is more accessible to external applications and more easily programmed by the neophyte LDAP developer.
- Centrally secure, replicate, and backup Atom documents;e.g., blogs in the directory
- Re-use existing infrastructure and expertise (directory server) to store next gen web content, again, in a secure, scalable fashion
- Monitor the directory through feeds. A simple search on the OpenDS monitor (/atom/search?q=cn=monitor??sub?) dumps a feed of all significant directory statistics
Where can you get it (and contribute to it!)? Right here, in the first OpenDS sub-project @ http://atom.dev.java.net
Monday May 07, 2007
By treydrake on May 07, 2007
Sunday Apr 22, 2007
By treydrake on Apr 22, 2007
I'm running the demo atop Ubuntu, Java 6, Glassfish V2, and the latest OpenDS download. Ensure you obtain a build dated 4/21/2007 or later.
- Install OpenDS
- Drop in the OpenID schema file. In the case of OpenDS simply drop this file in $opends_home/config and restart OpenDS.
- Download the OpenID application (WAR) and deploy to your application server. Please note the fine print below.
- To get started register a new user by "claiming in ID" via the bundled user interface http://localhost:8080/opendsidp/. Copy the generated claim URL; e.g., http://yourhost/opendsidp/claims/username and go use it. For starters try using your claim at http://jyte.com.
Since this is demoware, I made many assumptions about the environment. Most of these assumptions are configurable though a few currently are not. Also, I've left a few features out. In particular, I've left manually accepting/rejecting trust roots for another day. Please note the following: It is assumed the directory server is on the localhost, listening on port 1389, and may be read by the user cn="directory manager" with the password "password". The base DN is "dc=example,dc=com" and the people base DN is "ou=people,dc=example,dc=com". Additionally, it is required that all OpenID users must belong to the group "openidusers" and that group is located in ou=groups,dc=example,dc=com. The OpenID configuration and authentication tokens (user cookies) are stored in ou=openid, dc=example,dc=com. You do not need to create the groups or openid configuration buckets, they will be created on startup. If your ldap host, port, query user, based dn, or base people dn are different you are free to change the default values by editing the web.xml file located in the WEB-INF directory. The attributes that need changing should be obvious. Confused? Don't be, if you install OpenDS out-of-the-box and accept the default installation configuration you'll be good to go. Good luck!
Tuesday Mar 27, 2007
By treydrake on Mar 27, 2007
To give it a try: 1. Install OpenDS. Note: If you're just kicking the tires import sample people by selecting the "import automatically-generated sample data" radio button. 2. Add OpenDS to your Address Book. Open the preferences panel in the Address Book application and click the LDAP button. Configure connection parameters as shown below. Done! Search the address book: Mac Mail auto-completion:
Monday Mar 26, 2007
By treydrake on Mar 26, 2007
Thursday Mar 22, 2007
By treydrake on Mar 22, 2007
Proposal for a Java LDAP Application Programming InterfaceThe Lightweight Directory Access Protocol (LDAP, as defined in RFC 4510 et al.) provides a standard means of communicating with directory servers. It is commonly used in identity management, authentication/authorization, naming services, user/application configuration, and general data storage. There are a growing number of commercial and open source server implementations, and many enterprises and service providers are significantly increasing the use of LDAP in their web applications, desktop clients, and mission-critical infrastructure. While LDAP innovation and development continues on the server side the same is not true of the client. Java SE and EE clients typically use Java Naming and Directory Interface (JNDI) to communicate with directory servers. This is primarily because JNDI and the accompanying LDAP SPI are embedded within Java SE and is rarely based on the merits of the API itself. JNDI is intended to be a generic interface for accessing very different kinds of data stores, and as such uses an abstract API. As a result, critical LDAP functionality is difficult to access and the developer experience is significantly impaired. For example:
- The abstract nature of JNDI terminology is confusing for the LDAP neophyte. That is, the Java LDAP developer must learn 2 different vocabularies, LDAP and JNDI. For example, the terms "bind" and "unbind" have standard meanings in LDAP which are very different from the way those terms are used in JNDI. In addition, a given JNDI method may result in different LDAP operations based on the arguments provided (e.g., while most variations of the JNDI "search" method will result in LDAP search operations, one usage will result in an LDAP compare operation, which may have different semantics).
- LDAP functionality can be enhanced through the use of elements such as controls, extended operations, and SASL mechanisms, and such extensions are frequently described in new specifications. JNDI does not provide an adequate mechanism for adding client-side support for these elements.
- Standard LDAP idioms are difficult or exposed in a bizarre manner; e.g., failed operation codes must be parsed out of exception messages, search enumerations must be closed.
Thursday Feb 22, 2007
By treydrake on Feb 22, 2007
Universal drivers: No vendor specific database drivers are needed as LDAP specifies a standard wire protocol. That is, any vendor’s LDAP client should be interoperable with any other vendor’s directory server. Therefore, the onerous task of obtaining and managing vendor database drivers is no longer necessary.
LDAP controls: Controls provide a mechanism for both the client and the server to send additional information with a LDAP request. A very useful LDAP control is persistent search (not all servers support the control, but it is a common feature). This control notifies the search requester of a change in the search results. For example, if an application centrally stores configuration information in a directory it needs to be notified if the configuration is changed. This is easily accomplished by running a persistent search on the config data - if a change (add, modify, delete, move) occurs the server will asynchronously notify the client. Checkout controls supported by OpenDS.
URL based searches: Depending on the capabilities of your LDAP client, a standardized URL may be used to execute a search; e.g., ldap://localhost/dc=example,dc=com???(uid=treydrake) returns the entry associated with “treydrake”. With a bit of practice, fine grained entry/attribute retrieval and search criteria is easily expressed on the "web command line". Not quite ReST, but convenient nonetheless.
LDAP schema constructs: I've noted that LDAP schema consists of objectclasses and attributes. A point worth mentioning is that objectclasses are much more flexible than flat RDBMS tables. Specifically, there are 3 types of objectclasses: structural, abstract, and auxiliary. Structural types are concrete classes that represent an LDAP entry. Abstract classes are simply structural parents; i.e., they define attributes for inheritance by more specialized, structural classes. Finally, auxiliary types are supplemental classes that may be associated with structural or abstract classes. To make these concepts concrete consider the typical person example, "inetorgperson" (the LDAP standard defines numerous standard objectclass types, one of which is "inetorgperson"). This type is derived as follows: top -> person -> organizationalPerson -> inetorgPerson. Where top is the parent of all LDAP classes and inetorgperson defines new person attributes and inherits all superior objectclass attributes. Objectclass inheritance is a heck of a lot cleaner than defining numerous tables and linking them together with foreign keys!
Globally unique schema: An interesting aspect of LDAP schema is the identification of objectclasses and attributes as globally unique objects known as OIDs. That is, every attribute and objectclass has both a name and a unique ID. This makes sharing schema objects throughout the enterprise much more precise and traceable as an OID is associated with an authority (a company, standard, etc). For example, I may create an objectclass named "blog" with the OID 220.127.116.11.4.1.26922.1.1. OIDs are also hierarchal; breaking apart the OID, "18.104.22.168.4.1" identifies the object is owned by a private enterprise, "26922" identifies the specific enterprise and the trailing suffix "1.1" is completely defined by the enterprise. An enterprise, having defined a new globally unique object, may then publish a detailed description of the new objectclass for reference by consumers. Clearly, identifying schema elements with collision proof ids versus names is a distinct advantage. Need your own OID namespace? Get one here.
- Blog moved to http://treydrake.wordpress.com
- Integrating OpenDS and SugarCRM
- OpenDS talk rollup
- Filling the Atompub AAA void with an OpenDS backed Atom server
- OpenDS and Atom - enabling Web 2.0 behind the firewall
- SecureTrust acquired
- OpenDS Atom server up to snuff
- Atom and LDAP sitting in a tree...
- Atom, APP, OpenID and OpenDS @ JavaONE
- Our OpenID server's getting some press