- 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
Deciding Whether to Write a Plug-in
Depending on what you want it to do, coding a plug-in for the directory server can be a complex task, especially the first time you do it. You'll need a good C developer if you don't have the required expertise with this language. You also need a good test plan before you deliver the plug-in.
Before deciding whether to write a plug-in, ask yourself the following questions:
Do I really need it? Can the directory server somehow meet my needs using standard features?
Can I wait for an upgrade? If the functionality you are looking for is included in the next version of the product, you might want to wait.
Can I support the plug-in, perhaps through an upgrade, in the next version of the directory server?
What impact might the plug-in solution have on the overall architecture?
What impact will the plug-in have on performance and scalability?
Some of these questions cannot be answered in advance. Nevertheless, it is good to consider the problems that might arise when you put your own plug-in in the middle of the directory server core.
In a big single sign on (SSO) project I worked on some time ago, a plug-in was introduced to authenticate users on a remote mainframe service (called a resource access control facility [RACF]), instead of locally through a classic bind. This approach was used because our customer, a big bank, did not want to deliver user passwords for security reasons. Unfortunately, the mainframe authentication service often did not answer in a timely manner, causing the timeout of an application that relied on the directory for authentication. This ended up being the main weakness of the whole architecture. The plug-in probably would have been developed in any case, because of the customer's needs, but some design tricks could have been used to avoid this critical situation.
Generally speaking, introducing a plug-in into an environment is a great responsibility, not just because you are going to extend or even override standard, core-provided functionality, but because you manage the data in place or together with the directory server. If, somehow, you fail to complete a modification in a preoperation plug-in, you will lose the data.