JDK-7110803 : SASL service for multiple hostnames
  • Type: Enhancement
  • Component: security-libs
  • Sub-Component: java.security
  • Affected Version: 8
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2011-11-11
  • Updated: 2017-05-16
  • Resolved: 2012-11-02
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
8 b64Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Sub Tasks
JDK-8001104 :  
In Sasl.createSaslServer() method, the serverName argument is documented as "[t]he non-null fully qualified host name of the server". This means a SASL service must specify the exact hostname it is serving at (say, my.host.com). This is not true any more in today's virtualized world in which a service might be serving clients from different networks by exposing different service names.

Update: the main bug will cover the SASL API change and trivial changes to mechanisms. Further enhancement for the GSSAPI/krb5 mech will be addressed in a sub task.

The What's New section of the release notes links to the Enhancements page of the security guide (docs/technotes/guides/security/enhancements-8.html), which contains a summary of this change.

release note: scope: Java SE text: When creating a SASL server, the server name can be set to null to denote an unbound server, which means a client can request for the service using any server name. After a context is established, the server can retrieve the name as a negotiated property with the key name SASL.BOUND_SERVER_NAME.