- 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
Authentication in the Directory Server
Because our plug-in example deals with authentication, this section briefly explains what the directory server offers in this area and explains why standard authentication does not satisfy the needs of our plug-in example.
The three authentication mechanisms available in the Sun ONE Directory Server 5.x are:
User name/password-pair-based authentication (optionally, over LDAP/Secure Socket Layer [SSL])
Certificate-based authentication
Simple authentication security layer (SASL) authentication
User name/password-pair-based authentication is the best-known method of providing user credentials, while the other methods are the strongest authentication methods.
Certificate-based authentication, which is meant to be used with secure LDAP protocol (LDAP on SSL), forces users who want to bind to the server to provide a valid X.509 certificate. The user's personal certificate contains several things, such as the distinguished name (DN) that identifies the user in the directory.
SASL is an authentication method developed to support connection-based application protocols (LDAP is one of these). With this framework in place, authentication becomes more complex; it becomes a negotiation that allows a client to ask for a specific authentication mechanism and, if the server supports it, the authentication process takes place.
To identify which SASL mechanisms are supported by the directory server, query the root directory specific entry (DSE), most likely the default, EXTERNAL and DIGEST-MD5.
In the first section of this article, we cautioned you to develop a plug-in only after thoughtful consideration. Because we do not want to be an exception to this rule, we'll briefly examine the reasons we've decided to write a plug-in to implement our own authentication policy.
Our purpose is to let users of the Solaris™ Operating Environment (Solaris OE) successfully bind to the directory server using the user name/password pair they use (their UNIX user names and passwords), for example, to access the OE using Telnet or FTP. To enable this, we could adjust the contents of the /etc/passwd and /etc/shadow files in the directory server, making the UNIX users directory users, but this has the following disadvantages:
We need to use crypt as the password crypting schema and not the default SSHA
We need to keep the content of the UNIX authentication files and the directory server in sync
The first of these problems can be a headache if there are already users loaded with the default SSHA encoding storage schema. At this point, it seems pretty obvious that we need to extend the basic behavior of the directory server to make it do something similar to the following.
For users in one branch (for example, ou=unix,dc=sun,dc=com), authenticate passwords like UNIX does, using a crypt system call and the /etc/passwd and /etc/shadow databases.
For users in other branches, use a standard directory server bind mechanism. This is exactly what our plug-in is designed to do.