SOAP服务从IBM TAM迁移至ISAM的技术问询

Great question—let’s break this down clearly for your scenario:

1. Do you still need the ibm-webservicesclient-bnd.xmi and ibm-webservicesclient-ext.xmi files? #

Yes, absolutely. These files act as the critical "glue" between your high-level WS-Security policies (like requiring SAML tokens) and IBM’s concrete security implementation code in WebSphere. Without them, your frontend app won’t know how to generate, sign, and transmit SAML tokens to the backend service—especially when integrating with ISAM. They’re still necessary for customizing token handling logic in your WebSphere environment.

2. What SAML-related classes replace the LTPA ones? #

You’ll need to swap out your existing LTPA token generator classes with SAML-specific equivalents in the ibm-webservicesclient-bnd.xmi file. The exact class depends on the SAML version you’re using:

For SAML 1.1 Tokens #

Replace any LTPA generator entries with this class:

com.ibm.ws.wssecurity.token.saml.SAMLTokenGenerator

Pair it with the token type property:
http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1

For SAML 2.0 Tokens (Recommended for modern ISAM integrations) #

Use this generator class instead:

com.ibm.ws.wssecurity.token.saml2.SAML20TokenGenerator

With the corresponding token type property:
http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0

Example Snippet in ibm-webservicesclient-bnd.xmi #

Here’s how a typical SAML 2.0 generator configuration might look (replace your existing LTPA section):

<securityTokenGenerators xmi:id="SAML20TokenGenerator_1" tokenGeneratorClass="com.ibm.ws.wssecurity.token.saml2.SAML20TokenGenerator">
  <property name="tokenType" value="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0"/>
  <!-- Optional: Add properties for your ISAM IdP URI, token expiration, etc. -->
  <property name="issuer" value="your-isam-idp-uri"/>
</securityTokenGenerators>

Additional Tips #

• ISAM Trust Configuration: Make sure your WebSphere server trusts ISAM as your SAML Identity Provider (IdP). Import ISAM’s signing certificate into WebSphere’s trust store so the client can validate issued SAML tokens.
• Policy Updates: Don’t forget to update your WS-Security policy (either in the WSDL or attached policy set) to require SAML tokens instead of LTPA. The binding files work hand-in-hand with these policies.
• ibm-webservicesclient-ext.xmi Tweaks: This file can be used to adjust advanced settings like token expiration time, included SAML attributes, or signature algorithms. Check WebSphere’s documentation for SAML-specific properties relevant to your setup.
• Policy Sets Alternative: If you’re on WebSphere 8.5 or later, you could use built-in policy sets (like SAML Bearer Token or SAML Sender Vouches) instead of manually editing XMI files—but if you’re sticking with your existing binding file workflow, the classes above are the right fit.

内容的提问来源于stack exchange，提问作者Kishor