Set SPNEGO web authentication filters using the admin console

The SPNEGO filter values control different aspects of SPNEGO. We can specify different filter values for each appserver by using the admin console.

 

1. In the admin console, click...
   Security | Global security

2. Under Authentication, expand Web and SIP Security and then click SPNEGO Web authentication.

3. Under SPNEGO filters, select an existing host name to edit or click New.

4. Enter a WAS host name if creating a new filter. This is the host name in the Kerberos service principal name (SPN) used by SPNEGO to establish a Kerberos secure context.

5. Enter a Kerberos realm name. In most cases, the realm is the domain name in uppercase letters. For example, a machine with the domain name of test.mpls.setgetweb.com would usually have a Kerberos realm name of AUSTIN.IBM.COM

6. Enter a filter criteria in the Filter criteria field.

   The filter criteria is the filtering parameter used by the Java class used by SPNEGO. It defines arbitrary criteria that is meaningful to the implementation class used.

   Read about Enable and configuring SPNEGO Web authentication for more information about the filter criteria.

7. In the Filter class field, enter the name of the Java class used by SPNEGO to select which HTTP requests are subject to SPNEGO authentication. If we do not specify this parameter, the default filter class, com.ibm.ws.security.spnego.HTTPHeaderFilter, is used.

8. In the SPNEGO not supported error page URL field optionally enter the URL of a resource that contains the content which SPNEGO includes in the HTTP response that is displayed by the (browser) client application if it does not support SPNEGO authentication. This property can specify a Web (http://) or a file (file: //) resource.

9. In the NTLM token received error page URL field optionally specify the URL of a resource that contains the content which SPNEGO includes in the HTTP response, which is displayed by the (browser) client application. The (browser) client application displays this HTTP response when the browser client sends a NT LAN manager (NTLM) token instead of the expected SPNEGO token during the challenge-response handshake.

   This property can specify a Web (http://) or a file (file: //) resource.

10. Select Trim Kerberos realm from principal name to specify whether SPNEGO should remove the suffix of the principal user name, starting from the @ that precedes the Kerberos realm name. If this option is selected, the suffix of the principal user name is removed. If this attribute is not selected, the suffix of the principal name is retained. The default is for this option to be selected.

11. Select Enable delegation of Kerberos credentials to indicate whether the Kerberos delegated credentials should be stored by SPNEGO. This option also enables an application to retrieve the stored credentials and to propagate them to other applications downstream for additional SPNEGO authentication.

    If this option is enabled (which it is by default), the GSSCredential is not serializable and cannot be propagated to the downstream server.The client Kerberos delegation credential is extracted and the KRBAuthnToken base is created. The KRBAuthnToken contains the client Kerberos delegation and can be propagated to a downstream server.

    To propagate the KRBAuthnToken to a downstream server, the client Ticket Granting Ticket (TGT) must contain addressless and forwardable options. If a client TGT is addressed the downstream server does not have a client GSS delegation credential after it is propagated.

    We can extract the client delegation GSSCredential from the KRBAuthnToken by using the KRBAuthnToken.getGSSCredential() method.

12. Click OK.

 

Results

we have modified existing or created new SPNEGO filter values for the appserver.

 

Related tasks

Set Kerberos as the authentication mechanism

 

Related

CSIv2 inbound communications settings
CSIv2 outbound communications settings
SPNEGO Web authentication filter commands