The Simple and Protected
GSS-API Negotiation Mechanism
(SPNEGO) filter values control different aspects of SPNEGO. You can
specify different filter values for each application server by using
the administrative console.
Procedure
- In the administrative console,
click Security > Global
security.
- Under Authentication, expand
Web and SIP Security and then
click SPNEGO web authentication.
- Under
SPNEGO filters, select an existing host name to edit
or click New.
- Enter a WebSphere® Application Server 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.
- Enter a Kerberos realm name. In most cases,
the realm is your domain name in uppercase letters. For example, a
machine with the domain name of test.austin.ibm.com would usually
have a Kerberos realm name of AUSTIN.IBM.COM
- Enter
a filter criteria in the Filter criteria field. The
filter criteria is the filtering parameter used by the Java class that is used by SPNEGO. It defines
arbitrary criteria that is meaningful to the implementation class
used.
Read about Enabling and configuring SPNEGO web authentication using the administrative console for
more information about the filter criteria.
- In
the Filter class field, enter the name of the Java class that is used by SPNEGO to select
which HTTP requests are subject to SPNEGO authentication. If
you do not specify this parameter, the default filter class, com.ibm.ws.security.spnego.HTTPHeaderFilter,
is used.
- Optional: In the SPNEGO
not supported error
page URL field you can 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.
- Optional: In the NTLM token received error
page URL field you can 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.
- Optional: 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.
- Optional: 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.
Note: 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.
If you want 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.
You can extract
the client delegation GSSCredential from the KRBAuthnToken by using
the KRBAuthnToken.getGSSCredential() method.
- Click OK.
Results
You
have modified existing or created new SPNEGO filter values
for your application server.