ws-wss4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Valeri" <dval...@apache.org>
Subject Determining complement of signatureKeyIdentifier in signature processor
Date Tue, 20 Jul 2010 15:15:47 GMT
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 

 

 

 

 

 

 


Mime
View raw message