How SASL mechanisms are installed and selected

SASL mechanism implementations are provided by SASL security providers. Each provider can support one or more SASL mechanisms and is registered with the Java™ Cryptography Architecture (JCA). You specify and order providers in the Java Security Properties file.

By default, from IBM® SDK, Java 2 Technology Edition, Version 5, the IBMSASL provider is automatically registered as a JCA provider. To remove the provider or reorder its priority as a JCA provider, change the following line in the Java Security Properties file ($JAVA_HOME/lib/security/java.security):

security.provider.7=com.ibm.security.sasl.IBMSASL

To add or remove a SASL provider, add or remove the corresponding line in the Security Properties file. For example, to add a SASL provider and specify that its mechanisms are used in preference to the same mechanisms that are implemented by the IBMSASL provider, add a line to the Security Properties file with a lower number, as follows:

security.provider.7=com.example.MyProvider
security.provider.8=com.ibm.security.sasl.IBMSASL

Alternatively, you can programmatically add your own provider by using the java.security.Security class. For example, the following sample code registers the com.example.MyProvider provider to the list of available SASL security providers:

Security.addProvider(new com.example.MyProvider());

For more information about the java.security.Security class, see the Oracle API documentation.

When an application requests a SASL mechanism by supplying one or more mechanism names, the SASL framework looks for registered SASL providers that support that mechanism by searching, in order, the list of registered providers. The providers must then determine whether the requested mechanism matches the selection policy properties and if so, return an implementation for the mechanism.

The selection policy properties specify the security aspects of a mechanism, such as its susceptibility to certain attacks. These security aspects are characteristics of the mechanism definition, rather than its implementation, so all providers should come to the same conclusion about a particular mechanism. For example, the PLAIN mechanism is susceptible to plaintext attacks regardless of how it is implemented. If no selection policy properties are supplied, there are no restrictions on the selected mechanism. By using these properties, an application can ensure that it does not use unsuitable mechanisms that might be deployed in the runtime environment. For example, an application might use the following sample code if it does not want to allow the use of mechanisms susceptible to plaintext attacks.

Map props = new HashMap();
props.put(Sasl.POLICY_NOPLAINTEXT, "true");
SaslClient sc = Sasl.createSaslClient(mechanisms,
    authzid, protocol, serverName, props, callbackHandler);

See the Sasl class for descriptions of the selection policy properties.