Configure a Ticket Protected Gateway

In this procedure, you will learn how to configure Kaazing WebSocket Gateway as a Ticket Protected Gateway to accept a Kerberos service ticket from a browser client.

Before You Begin

This procedure is part of Checklist: Configure Kerberos V5 Network Authentication:

  1. Configuring Kerberos V5 Network Authentication Overview
  2. Configure a Ticket Protected Gateway
  3. Configure a Ticket Granting Gateway

To Configure a Ticket Protected Gateway

  1. Ensure that your environment is configured for Kerberos and note down the required values for the Kerberos login-module.
  2. Configure the client browsers, which is typically done on the intranet (refer to the browser's documentation, such as Mozilla Firefox or Microsoft Internet Explorer, for help on configuration).
  3. In the Gateway configuration, create a service entry for kerberos5.proxy, which signals the Gateway to communicate with the Kerberos Key Distribution Center in your environment.
  4. Set the http-challenge-scheme element (in the authentication element in security) to use Application Negotiate or Negotiate, which allows the client (Application Negotiate) or the browser (Negotiate) to respond to SPNEGO challenges.
  5. Add a kerberos5 login-module element. See the Krb5LoginModule documentation for information on configuring the options. Note that the principal option must point to the HTTP service that is being authenticated, and must always use the form: HTTP/<serverName>@<kerberosDomainName>. For example, if the service accept tag value is ws://gateway.example.com/protocol, the principal tag should be set to HTTP/gateway.example.com@KDC.DOMAIN.COM. This allows a client application using the Kaazing WebSocket Gateway KerberosChallengeHandler API to obtain a ticket for the same SPN (Service Principal Name) and the Kerberos Login Module can validate this ticket.

    You can choose to instruct the client application to obtain a ticket for a different SPN by setting that SPN on the KerberosChallengeHandler with a call to the setServiceName() method; however, you must ensure that this SPN matches the SPN configured in the login module.

  6. Add a gss login-module element after the kerberos5 login-module element. This element requires no options but must follow the kerberos5 login-module element, as the gss login-module element uses the credentials obtained by the kerberos5 login-module element to verify the service ticket presented by the client.

    The following example shows the Application Negotiate http-challenge-scheme element, a principal element using the correct format, and a gss login-module:

    <security>
    	<realm>
    		<name>demo</demo>
    		<authentication>
    			<http-challenge-scheme>Application Negotiate</http-challenge-scheme>
    			<login-modules>
    				<login-module>
    					<type>kerberos5</type>
    					<success>required</success>
    					<options>
    						<useKeyTab>true</useKeyTab>
    						<keyTab>/etc/krb5.keytab</keyTab>
    						<principal>HTTP/localhost@LOCAL.NETWORK</principal>
    						<isInitiator>false</isInitiator>
    						<doNotPrompt>true</doNotPrompt>
    						<storeKey>true</storeKey>
    					</options>
    				</login-module>
    
    				<login-module>
    					<type>gss</type>
    					<success>required</success>
    				</login-module>
    			</login-modules>
    		</authentication>
    	</realm>
    </security>
    

Notes

  • If you choose to use Application Negotiate, you must also configure your client to handle the SPNEGO-based Kerberos authentication mechanism. For more information, see How does Kerberos SPNEGO GSS-API work?.
  • After you configure the Gateway, ensure your clients are also configured for Kerberos. For information on creating Kaazing WebSocket Gateway client Kerberos challenge handlers, see the Howto documentation for developers.
  • The session element has been deprecated. For more information, see the Session Reference documentation.

Next Steps

Configure a Ticket Granting Gateway

See Also

TOP