- Writing an Authentication Plug-in for a Sun· ONE Directory Server
- Deciding Whether to Write a Plug-in
- Types of Plug-ins
- Working in the Plug-in Application Program Interface
- Authentication in the Directory Server
- UNIX Authentication Plug-in
- Testing the Plug-in
- About the Author
- Related Resources
- Ordering Sun Documents
- Accessing Sun Documentation Online
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Types of Plug-ins
The Sun ONE Directory Server documentation categorizes plug-ins based on what they do, or on the kind of extension they provide. Therefore, the directory server recognizes the following types of plug-ins:
Preoperation plug-ins
Postoperation plug-ins
Store and entry fetch plug-ins
Extended-operation plug-ins
Matching-rule plug-ins
Password storage scheme plug-ins
The preoperation plug-in function is called before an LDAP operation is performed. The primary purpose of this plug-in function is to validate data. The postoperation plug-in function is called after an operation has completed. An example could be emailing the system administrator when a user entry has been modified.
Store and entry fetch plug-ins are usually not required. They work on the directory back end, and are used when the system stores or fetches entries from the repository. A good reason to write this type of plug-in is to crypt the data before storing it on a disk.
Extended-operation plug-ins are the most interesting type of plug-in, in my opinion. They are used to write extended operations using the well-known Lightweight Directory Access Protocol (LDAP) v3 compliant method of providing extensions to an LDAP server that is directly accessible by clients.
Matching-rule plug-ins are used to add new matching rules to match attributes. Every matching rule is identified by an object identifier (OID) number, which can be selected later by clients. The following example shows a search performed using the ldapsearch command with a custom matching rule:
$ ldapsearch -D "cn=Directory Manager" -w secret -b "dc=siroe,dc=com" (cn:dn:3.3.11.5:=microsystems)
3.3.11.5 is your matching rule ID, which is your own method of comparing attributes (behind which, of course, is your plug-in).
A specialized kind of plug-in, password storage schema plug-ins are considered a security enhancement. They function primarily by encoding the user password stored in the database and comparing a clear text value exchanged at authentication with the hashed one. The default password storage schema you get from a default installation of the directory server is Salt Salted Secure Hash Algorithm (SSHA).
The directory server allows passwords to be stored in a non-recoverable way. This is accomplished by running users' passwords through a one-way hash algorithm and then storing them on disk in a hashed form. When we need to compare a password presented on a bind request with one we have stored, we just hash the bind password and compare the bytes.
We support several password hash/storage schemes, including clear text, UNIX crypt, SSHA, and SHA1. As previously mentioned, our default algorithm is SSHA. So we can tell how a stored password has been hashed, we add a prefix so the values appear as follows:
userpassword: {crypt}Ihp/oX7K3X.Wg
userpassword: {SSHA}qjYg/Nhf/c2yWoKc4EODS6EBSIQ0fksRdRvlJQ==
userpassword: {SHA}FTuAdV9ulibSiggtXpAQJ3e9lro=
userpassword: secret
For SSHA and SHA1 (labeled as SHA) the bytes after {SSHA} and {SHA} are base64 encoded. Passwords stored in clear text do not get a prefix.
Standard directory binds compare the password provided by the user with the one stored in the user password attribute of the entry the user is trying to bind (if anonymous access in non-enabled mode). Authentication plug-ins, not listed above, are a special type of preoperation plug-in. They are prebind plug-ins that override the default behavior of a standard directory bind.