| The following recapitulates some best practices and pitfalls regarding the use of WS-Security for interoperability. Best Practices Use compatible or certified software component versions. Don't assume the latest version of open source components always work with the existing code base. Use specific encryption and digest algorithms that are proven to work for Java EE .NET interoperable products. Use Triple DES for session key encryption to enable WSE in the app.config for interoperability. <binarySecurityTokenManager valueType= "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"> <sessionKeyAlgorithm name="TripleDES" /> </binarySecurityTokenManager> Use Optimal Asymmetric Encryption Padding (RSAOAEP RSA) as the encryption key algorithm to enable WSE in the app.config file for interoperability. [View full width] <binarySecurityTokenManager valueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1 .0#X509v3"> <keyAlgorithm name="RSAOAEP" /> </binarySecurityTokenManager> Use built-in handlers or security policies wherever possible, instead of rewriting your own security processing logic. If you want to customize your own security processing logic, you may consider extending the existing handlers.
Pitfalls Certificate management on both platforms can be problematic For example, if the digital certificate is expired, the error messages may disguise the problem as being invalid credentials or keys but not the expired certificates. Use of security exception Don't just catch the exception. Make the error message meaningful. For example, the exception "no policy found" can be ambiguous and does not tell what the root cause is.
|