Previous | Next | Trail Map | Tips for LDAP Users | Security

Callbacks for SASL Mechanisms

A SASL mechanism is always given the authorization id (that specified by the "") environment property. All other input is supplied on-demand, that is, on request of the mechanism.

By default, the LDAP provider supplies the authentication id and credentials by using, respectively, the Context.SECURITY_PRINCIPAL(in the API reference documentation) and Context.SECURITY_CREDENTIALS(in the API reference documentation) environment properties. If a SASL mechanism requires input other than these, or if you prefer to supply the input through a different means, then you can define a callback handler object for the mechanism to use. To do this, you set the "" environment property to the callback handler object, as explained next.

Callback Handler

The LDAP provider uses the the API reference documentation) package from the Java Authentication and Authorization Service. The object contained in the "" environment property must be of type the API reference documentation) . When a SASL mechanism requires input, it invokes the API reference documentation), and supplies the list of callbacks that it needs in order to get that input. A mechanism must use the the API reference documentation) when asking for the authentication id and use the the API reference documentation) when asking for the authentication credentials. To obtain other input, the mechanism will use one of the callbacks defined in the package or any other callback that implements the the API reference documentation) interface.

The callback handler must be able to handle the type of callback requested by a mechanism, so the application that creates/uses the callback handler must have some knowledge about what the mechanism requires. For example, in addition to the NameCallback and PasswordCallback, the Digest-MD5 mechanism requires also callbacks to get the realm. The realm is obtained by using either a the API reference documentation) or the API reference documentation).

Here is an example of a callback handler that handles NameCallback and PasswordCallback by reading the data from Standard Input.

public class SampleCallbackHandler implements CallbackHandler {
    public void handle(Callback[] callbacks) 
	throws, UnsupportedCallbackException {
	    for (int i = 0; i < callbacks.length; i++) {
		if (callbacks[i] instanceof NameCallback) {
		    NameCallback cb = (NameCallback)callbacks[i];

		} else if (callbacks[i] instanceof PasswordCallback) {
		    PasswordCallback cb = (PasswordCallback)callbacks[i];

		    String pw = getInput(cb.getPrompt());
		    char[] passwd = new char[pw.length()];
		    pw.getChars(0, passwd.length, passwd, 0);

		} else {
		    throw new UnsupportedCallbackException(callbacks[i]);

     * A reader from Standard Input. In real world apps, this would
     * typically be a TextComponent or similar widget.
    private String getInput(String prompt) throws IOException {
	BufferedReader in = new BufferedReader(
	    new InputStreamReader(;
	return in.readLine();

CRAM-MD5 by Using a Callback Handler

Here's a modified version of the CRAM-MD5 example that gets its password by using a callback handler instead the Context.SECURITY_PRINCIPAL and Context.SECURITY_CREDENTIALS environment properties. The CRAM-MD5 mechanism needs the authentication id and the password as input. These are supplied by SampleCallbackHandler.
// Set up the environment for creating the initial context
Hashtable env = new Hashtable(11);
env.put(Context.PROVIDER_URL, "ldap://localhost:389/o=JNDITutorial");


// Specify the callback to use for fetching the authentication id/password
env.put("", new SampleCallbackHandler());

// Create the initial context
DirContext ctx = new InitialDirContext(env);

// ... do something useful with ctx

Previous | Next | Trail Map | Tips for LDAP Users | Security