I would like to expose the method used to retrieve the key for signature validation activities in the WSS4J results. The primary objective here is to be able to restrict the mechanisms allowed for retrieving the key in order to meet end-user security profiles as well as to support enforcing initiator/recipient token requirements in WS-SP (specifically the sp:RequireKeyIdentifierReference, sp:RequireIssuerSerialReference, sp:RequireEmbeddedTokenReference, sp:RequireThumbprintReference policy assertions and the sp:IncludeToken attribute). WSS4J is already deep into the WS-S data structures so I would like to determine this information inside of WSS4J rather than digging through the message again at a later time to determine the information that WSS4J can likely already provide.
The key determination is undertaken on lines 225-410 of signature processor in 1.5.x branch (200-361 in trunk). My initial thoughts were to use the keyIdentifier constants (WSConstants.BST_DIRECT_REFERENCE, WSConstants.ISSUER_SERIAL, etc.) used in the signature action as the values; however, I don't think the existing constants are descriptive enough to really convey all of the various key retrieval mechanisms provided in the signature processor. Adding additional constants to describe the additional mechanisms supported in signature processor isn't a huge undertaking, but I am having some issues understanding all of the various mechanisms supported. Here is what I have so far based on the 1.5.x branch line numbers. My questions are provided below by their line numbers. · 225 - Embedded token using KeyInfo as described in WS-S chapter 7.5 · 231 - All other scenarios that involve a STR element o 249 - Scenarios that use STR with a nested Reference element as described in WS-S chapter 7.2. § 257 – This seems duplicative of the later “x instanceof Processor” clauses. Is this here to support ordering of the Security element’s children that do not follow the spec recommendation and the scenario where the token is not actually in the message body? In the case where the tokens are out of order, but included in the message, does this effectively process the token twice (once here and then later when the header is actually encountered as the next child of the Security element)? · 265 – BST in the message that has not been previously processed · 275 – SAML assertion in the message that has not been previously processed · 281 – Encrypted key in the message, as described in WS-S chapter 7.7, that has not been previously processed. Under which usages does this occur? This mechanism is not supported by the signature action so when does it happen? · 284 – A custom token that is not a SC token as this would already have been handled by secRef.getTokenElement(). § 3315 – Derived key from a UT. § 322 - BST in the message. § 324 – Encrypted key in the message. Same questions as above. § 328 – A SC SCT in the message. § 333 – A SC DK in the message. § 342 – A SAML assertion in the message. o 353 – If the STR has the certificate embedded in it under a ds:X509Data element or contains a ds:X509IssuerSerial element from the X509 profile. o 355 – If the STR uses the key identifier mechanism described in WS-S chapter 7.3. § 356 – Key identifier using SHA1 of an encrypted key § 377 – Key identifier pointing to a SAML assertion § 389 – Lookup in crypto using thumbprint, SKI, or actual certificate bytes
