Code review request: 7110803: SASL service for multiple hostnames

[Sean Mullan]

Hi Max,

Looks good. A few minor comments:

* SaslServerFactory

64: typo: s/to. or null/to, or null/

* Sasl

124: it would be helpful to mention the methods that the serverName argument is
referring to.

* GssKrb5Server.java

76: s/Will/will

--Sean

On 10/17/12 11:14 PM, Weijun Wang wrote:
> Hi All
> 
> Please take a look at
> 
>     http://cr.openjdk.java.net/~weijun/7110803/webrev.00/
> 
> 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.
> 
> The RFE allows serverName to be set to null in Sasl.createSaslServer() 
> and thus creates an unbound SASL server. This will be useful if the 
> server can accept multiple server names (think of virtual hosts in an 
> Apache HTTP server) or the name is configured in the underlying 
> mechanism. It also provides a new negotiated property called 
> BOUND_SERVER_NAME so that an unbound server has a chance to see its 
> bound name after the auth exchange is completed.
> 
> This patch includes the API change and trivial changes for some 
> mechanisms. The patch for the GSSAPI mechanism is a little more 
> complicated and will be addressed in a sub-bug.
> 
> Thanks
> Max
>