Security concerns when an LtpaToken(2) is constructed outside of the Authenticating cell.

Problem

Some stack products like Datapower and WebSeal will create their own LtpaToken(2). They pass the token on subsequent Web requests to backend Application Servers where it is used to authorize access to protected resources. Inside the LtpaToken is information used to reconstruct a WSCredential for authentication/authorization. Specifically the accessId of the user is found in the LtpaToken. This accessId is a realm name and DN of the user. The DN must exactly match the DN as defined in in the backend Application Servers security realm. When there is not an exact match you may see the following trace messages followed by the exception. 11109 [3/23/12 9:34:14:930 EET] 00000040 wsMapDefaultI 3 accessId is user:myLDAP.com:389/uid=myID1, ou=people, dc=myCompany 11110 [3/23/12 9:34:14:930 EET] 00000040 wsMapDefaultI 3 ssoToken principal is user:myLDAP.com:389/uid=myID1,ou=people,dc=myCompany 11111 [3/23/12 9:34:14:930 EET] 00000040 wsMapDefaultI 3 Principal and accessId don't match so creating a new default SSO token. Unable to deserialize the Subjects in this Context, cause: com.ibm.websphere.security.WSSecurityException: Failed to deserialize Context. 11169 [3/23/12 9:34:14:940 EET] 00000040 ExceptionUtil E CNTR0020E: EJB threw an unexpected (non-declared) exception during invocation of method "myEJBMethod" on bean "BeanId(MyApp#MyEJB.jar#Module, null)". Exception data: javax.xml.ws.WebServiceException: java.io.IOException: Unable to deserialize the Subjects in this Context In the above case the accessId did not match the ssoToken, as defined in the LtpaToken(2) due to spaces embedded in the accessId. It might be argued that since in this case the UserRegistry is an LDAP server, that as per LDAP RFC 4514, the spaces should be ignored and this considered an exact match. The reason why this RFC can not be applied to this situation is: 1. Security code treats both the accessId and ssoToken as a text string. 2. This text string was obtain from one of several supported UserRegistries including custom UserRegistries. Their is no guarentee that the UserRegistry is an LDAP server. 3. Because there is no guarentee that the UserRegistry is an LDAP server, applying this LDAP RFC would not be the right thing to do. In summary, it is critical that 3rd parties that create and provide LtpaToken(2) for authentication understand and match the DN as it will be returned from the backend WAS security realm.