Review Board 1.7.22


BlobCrypterSecurityTokenCodec tries to use "instanceof" when the parameter is a Proxied object

Review Request #1981 - Created Sept. 20, 2011 and submitted

Stanton Sievers
SHINDIG-1626
Reviewers
shindig
hsaputra
shindig
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. 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.
Ship it!
Posted (Sept. 21, 2011, 6:13 p.m.)
+1

LGTM, thanks Stanton.

We have to add the new getter methods to AuthContext, I dont see other way