You can specify the token consumer on the application level.
The token consumer information is used on the consumer side to incorporate
the security token.
Before you begin
You need to understand that the keystore/alias information
that you provide for the generator, and the keystore/alias information
that you provide for the consumer are used for different purposes.
The main difference applies to the Alias for an X.509 callback handler.
When
used in association with an encryption consumer, the alias supplied
for the consumer is used to retrieve the private key to decrypt the
message. A password is required. When associated with a signature
consumer, the alias supplied for the consumer is used strictly to
retrieve the public key that is used to resolve an X.509 certificate
that is not passed in the SOAP security header as a BinarySecurityToken.
A password is not required.
About this task
Complete the following steps to configure the token consumer
on the application level.
Procedure
- Locate the token consumer panel in the administrative console.
- Click .
- Under Modules, click .
- Under Web Services Security Properties you can access
the token consumer for the following bindings:
- For the request consumer (receiver) binding, click Web
services: Server security bindings. Under Request consumer
(receiver) binding, click Edit custom.
- For the response consumer (receiver) binding, click Web
services: Client security bindings. Under Response consumer
(receiver) binding, click Edit custom.
- Under Required properties, click Token consumer.
- Click New to create a token consumer
configuration, click Delete to delete an existing
configuration, or click the name of an existing token consumer configuration
to edit its settings. If you are creating a new configuration,
enter a unique name in the Token consumer name field.
For example, you might specify con_signtcon.
- Specify a class name in the Token consumer class
name field. The Java Authentication and Authorization Service
(JAAS) Login Module implementation is used to validate (authenticate)
the security token on the consumer side.
The
token consumer class name for the request consumer and the response
consumer must be similar to the token generator class name for the
request generator and the response generator. For example, if your
application requires a user name token consumer, you can specify the
com.ibm.wsspi.wssecurity.token.UsernameTokenGenerator class name on
the Token generator panel for application level and the com.ibm.wsspi.wssecurity.token.UsernameTokenConsumer
class name in this field.
- Optional: Select a part reference in the Part
reference field. The part reference indicates
the name of the security token that is defined in the deployment descriptor.
For example, if you receive a username token in your request message,
you might want to reference the token in the username token consumer.
Important: On the application level, if you do not specify a
security token in your deployment descriptor, the Part
reference field is not displayed. If you define a security
token called user_tcon in your deployment descriptor, user_tcon is
displayed as an option in the Part reference field.
- Optional: In the certificate path section of
the panel, select a certificate store type and indicate the trust
anchor and certificate store name, if necessary. These
options and fields are necessary when you specify com.ibm.wsspi.wssecurity.token.X509TokenConsumer
as the token consumer class name. The names of the trust anchor and
the collection certificate store are created in the certificate path
under your token consumer.
Restriction: The com.ibm.wsspi.wssecurity.token.TokenConsumingComponent interface
is not used with JAX-WS web services. If you are using JAX-RPC web
services, this interface is still valid.
You can select one
of the following options:
- None
- If you select this option, the certificate path is not specified.
- Trust any
- If you select this option, any certificate is trusted. When the
received token is consumed, the Application Server does not validate
the certificate path.
- Dedicated signing information
- If you select this option, you can select a trust anchor and a
certificate store configuration. When you select the trust anchor
or the certificate store of a trusted certificate, you must configure
the trust anchor and the certificate store before setting the certificate
path.
- Trust anchor
- A trust anchor specifies a list of key store configurations that
contain trusted root certificates. These configurations are used to
validate the certificate path of incoming X.509-formatted security
tokens. Keystore objects within trust anchors contain trusted root
certificates that are used by the CertPath API to validate the trustworthiness
of a certificate chain. You must create the keystore file using the keytool
utility. The keytool utility is available using the QShell Interpreter.
You
can configure trust anchors for the application level by completing
the following steps:
- Click .
- Under Related Items, click EJB Modules or .
- Access the token consumer from the following bindings:
- For the request consumer (receiver) binding, click Web
services: Server security bindings. Under Request consumer
(receiver) binding, click Edit custom.
- For the response consumer (receiver) binding, click Web
services: Client security bindings. Under Response consumer
(receiver) binding, click Edit custom.
- Under Additional properties, click Trust anchors.
- Collection certificate store
- A collection certificate store includes a list of untrusted, intermediary
certificates and certificate revocation lists (CRLs). The collection
certificate store is used to validate the certificate path of the
incoming X.509-formatted security tokens. You can configure the collection
certificate store for the application level by completing the following
steps:
- Click .
- Under Related Items, click EJB Modules or .
- Access the token consumer from the following bindings:
- For the request consumer (receiver) binding, click Web
services: Server security bindings. Under Request consumer
(receiver) binding, click Edit custom.
- For the response consumer (receiver) binding, click Web
services: Client security bindings. Under Response consumer
(receiver) binding, click Edit custom.
- Under Additional properties, click Collection certificate
store.
- Optional: Specify a trusted ID evaluator. The trusted ID evaluator is used to determine whether to trust
the received ID. You can select one of the following options:
- None
- If you select this option, the trusted ID evaluator is not specified.
- Existing evaluator definition
- If you select this option, you can select one of the configured
trusted ID evaluators. For example, you can select the SampleTrustedIDEvaluator,
which is provided by WebSphere® Application Server as
an example.
- Binding evaluator definition
- If you select this option, you can configure a new trusted ID
evaluator by specifying a trusted ID evaluator name and class name.
- Trusted ID evaluator name
- Specifies the name that is used by the application binding to
refer to a trusted identity (ID) evaluator that is defined in the
default bindings.
- Trusted ID evaluator class name
- Species the class name of the trusted ID evaluator. The specified
trusted ID evaluator class name must implement the com.ibm.wsspi.wssecurity.id.TrustedIDEvaluator
interface. The default TrustedIDEvaluator class is com.ibm.wsspi.wssecurity.id.TrustedIDEvaluatorImpl.
When you use this default TrustedIDEvaluator class, you must specify
the name and value properties for the default trusted ID evaluator
to create the trusted ID list for evaluation. To specify the name
and value properties, complete the following steps:
- Under Additional properties, click .
- Specify the trusted ID evaluator name in the Property field.
You must specify the name in the form, trustedId_n where _n is
an integer from 0 to n.
- Specify the trusted ID in the Value field.
For example:
property name="trustedId_0", value="CN=Bob,O=ACME,C=US"
property name="trustedId_1, value="user1"
If the
distinguished name (DN) is used, the space is removed for comparison.
See the programming model information in the documentation for an
explanation of how to implement the com.ibm.wsspi.wssecurity.id.TrustedIDEvaluator
interface. For more information, see Default implementations of the Web Services Security service provider programming interfaces.
Note: Define
the trusted ID evaluator on the server level instead of the application
level. To define the trusted ID evaluator on the server level, complete
the following steps:
- Click .
- Under Security, click JAX-WS and JAX-RPC security runtime.
Mixed-version environment: In a mixed node cell with a server using
WebSphere Application Server version 6.1 or
earlier, click
Web services: Default bindings for Web Services
Security.
mixv
- Under Additional properties, click Trusted ID evaluators.
- Click New to define a new trusted ID evaluator.
The trusted ID evaluator configuration is available
only for the token consumer on the server-side application level.
- Optional: Select the Verify nonce option. This option indicates whether to verify a nonce in the user
name token if it is specified for the token consumer. Nonce is a unique,
cryptographic number that is embedded in a message to help stop repeat,
unauthorized attacks of user name tokens. The Verify nonce option
is valid only when the incorporated token type is a user name token.
- Optional: Select the Verify timestamp option. This option indicates whether to verify a time stamp in the
user name token. The Verify nonce option is valid only when
the incorporated token type is a user name token.
- Specify the value type local name in the Local
name field. This field specifies the local
name of the value type for the consumed token. For a user name token
and an X.509 certificate security token, WebSphere Application Server provides predefined
local names for the value type.
Table 1. Uniform
Resource Identifier (URI) and Local name combinations. The
local name value indicates the type of consumed token.URI |
Local name |
Description |
A namespace URI is not applicable. |
Specify http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3 as
the local name value. |
Specifies the name of an X.509 certificate
token |
A namespace URI is not applicable. |
Specify http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509PKIPathv1 as
the local name value. |
Specifies the name of the X.509 certificates
in a PKI path |
A namespace URI is not applicable. |
Specify http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#PKCS7 as
the local name value. |
Specifies a list of X509 certificates and
certificate revocation lists (CRL) in a PKCS#7 |
Specify http://www.ibm.com/websphere/appserver/tokentype/5.0.2 as
the URI value. |
Specify LTPA as the local name value. |
Specifies a binary security token that contains
an embedded Lightweight Third Party Authentication (LTPA) token. |
- Optional: Specify the value type URI in the URI field. This entry specifies the namespace URI of the value type for
the consumed token.
Remember: If you specify the token
consumer for a username token or an X.509 certificate security token,
you do not need to specify a value type URI.
If you want
to specify another token, you must specify both the local name and
the URI. For example, if you have an implementation of your own custom
token, you can specify CustomToken in the Local
name field and http://www.ibm.com/custom
- Click OK and Save to
save the configuration.
- Click the name of your token consumer configuration.
- Under Additional properties, click JAAS configuration. The Java Authentication and Authorization
Service (JAAS) configuration specifies the name of the JAAS configuration
that is defined in the JAAS login panel. The JAAS configuration specifies
how the token logs in on the consumer side.
- Select a JAAS configuration from the JAAS configuration
name field. The field specifies the name of
the JAAS system of application login configuration. You
can specify additional JAAS system and application configurations
by clicking Global security. Under Authentication,
click Java Authentication and Authorization Service and
click either or . Do
not remove the predefined system or application login configurations.
However, within these configurations, you can add module class names
and specify the order in which WebSphere Application Server loads each module. WebSphere Application Server provides the following
predefined JAAS configurations:
- ClientContainer
- This selection specifies the login configuration that is used
by the client container applications. The configuration uses the CallbackHandler
application programming interface (API) that is defined in the deployment
descriptor for the client container. To modify this configuration,
see the JAAS configuration panel for application logins.
- WSLogin
- This selection specifies whether all of the applications can use
the WSLogin configuration to perform authentication for the security
run time. To modify this configuration, see the JAAS configuration
panel for application logins.
- DefaultPrincipalMapping
- This selection specifies the login configuration that is used
by Java 2 Connectors (J2C) to map users to principals
that are defined in the J2C authentication data entries. To modify
this configuration, see the JAAS configuration panel for application
logins.
- system.LTPA_WEB
- This selection processes login requests that are used by the web
container such as servlets and JavaServer Pages (JSPs) files. To modify
this configuration, see the JAAS configuration panel for system logins.
- system.RMI_OUTBOUND
- This selection processes RMI requests that are sent outbound to
another server when the com.ibm.CSIOutboundPropagationEnabled property
is true. This property is set in the CSIv2 authentication
panel.
To access the panel, click . Under Authentication, click . To set the com.ibm.CSIOutboundPropagationEnabled property,
select Security attribute propagation. To modify
this JAAS login configuration, see the JAAS - System logins panel.
- system.wssecurity.X509BST
- This selection verifies an X.509 binary security token (BST) by
checking the validity of the certificate and the certificate path.
To modify this configuration, see the JAAS configuration panel for
system logins.
- system.wssecurity.PKCS7
- This selection verifies an X.509 certificate within a PKCS7 object
that might include a certificate chain, a certificate revocation list,
or both. To modify this configuration, see the JAAS configuration
panel for system logins.
- system.wssecurity.PkiPath
- This section verifies an X.509 certificate with a public key infrastructure
(PKI) path. To modify this configuration, see the JAAS configuration
panel for system logins.
- system.wssecurity.UsernameToken
- This selection verifies the basic authentication (user name and
password) data. To modify this configuration, see the JAAS configuration
panel for system logins.
- system.wssecurity.IDAssertionUsernameToken
- This selection supports the use of identity assertion in Versions
6 and later applications to map a user name to a WebSphere Application Server credential principal.
To modify this configuration, see the JAAS configuration panel for
system logins.
- system.WSS_INBOUND
- This selection specifies the login configuration for inbound or
consumer requests for security token propagation using Web Services
Security. To modify this configuration, see the JAAS configuration
panel for system logins.
- system.WSS_OUTBOUND
- This selection specifies the login configuration for outbound
or generator requests for security token propagation using Web Services
Security. To modify this configuration, see the JAAS configuration
panel for system logins.
- None
- With this selection, you do not specify a JAAS login configuration.
- Click OK and then click Save to
save the configuration.
Results
You have configured the token consumer for the application
level.
What to do next
You must specify a similar token generator configuration
for the application level.