BlobCrypterSecurityTokenCodec tries to use "instanceof" when the parameter is a Proxied object
Review Request #1981 - Created Sept. 20, 2011 and submitted
See the JIRA for a description of the problem: https://issues.apache.org/jira/browse/SHINDIG-1626 This fix is based off a fix Doug Davies implemented with some changes around the parameter checking in BlobCrypterSecurityToken.encodeToken. The check is sufficient because DefaultSecurityTokenCodec creates the correct SecurityTokenCode (Basic or Blob) depending on the container config values of "insecure" or "secure", respectively. We should never get into this code if we're not using a secure configuration; therefore, an authentication mode of SECURITY_TOKEN_URL_PARAMETER implies that we have a BlobCrypterSecurityToken and not some other token, such as Anonymous.
Tested with a sample gadget that utilizes the osapi feature to print the viewer's name in a secure configuration. The security token is encoded properly in the modified code. Any other testing recommendations are welcome. :)
Review request changed
Updated (Sept. 20, 2011, 4:35 p.m.)
In the first patch we were losing some of the data from the token. I've updated this to try to save as much data as possible. This is getting messy, however, because AuthContext's methods have started looking like a SecurityToken. More specifically it's getters now match the BlobCrypterSecurityToken's setters. Is there a better way to do this? Presumably we need the proxy for the SecurityToken object in the first place.
Posted (Sept. 20, 2011, 10:07 p.m.)
Yeah its getting hard to maintain. The only reason we want to cast it to BlobCrypterSecurityToken is to call BlobCrypterSecurityToken.encrypt. I think we should move out the encrypt and decrypt business out from token and delegate it to BlobCrypterSecurityTokenCodec. So BlobCrypterSecurityToken does not contain crypter at all.
Review request changed
Updated (Sept. 21, 2011, 4:28 p.m.)
As promised, a new version that relies on the BlobCrypterSecurityTokenCodec passing in the BlobCrypter to the BlobCrypterSecurityToken. This allows BCSTC to call a static encrypt method on BCST instead of relying on instantiating a BCST itself. We still have the problem of the AuthContext needing to have the appropriate getters. I don't see a way around this.