Hi Joel,

The problem here is that the endpoint is requiring a "PublicKey" KeyType,
yet the received (Sender Vouches) assertion does not contain a PublicKey.
What I would suggest here is that you remove the KeyType from the policy of
the WSDL, but set up your (STS) clients to send a PublicKey KeyType to the
STS via configuration (configure the "keyType" property of the STSClient).
Would this work for you?

Colm.


On Fri, Feb 21, 2014 at 12:40 AM, bimjoeipa <[email protected]
> wrote:

> Hi Colm,
>
>
> coheigea wrote
> > I don't think your change
> > to the IssuedTokenPolicyValidator should be necessary. The
> > SamlAssertionWrapper in WSS4J now tries to parse the Subject KeyInfo for
> > the non-HolderOfKey case. So there should be a SubjectKeyInfo there ready
> > for validation, for the sender-vouches case. Could you debug into the
> code
> > here and let me know why it is not working?
>
> I debugged through the code and found that Subject KeyInfo is not set
> because the element is simply not in the Assertion.
>
> As far as I'm aware Sender Vouches doesn't contain a Subject KeyInfo, that
> is only for Holder of Key right? Because there is no X.509 certificate
> associated with the Subject.
>
> This  IBM Link
> <
> http://pic.dhe.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=%2Fcom.ibm.websphere.express.doc%2Finfo%2Fexp%2Fae%2Fcwbs_samltokenprofilespec.html
> >
> shows different examples of SAML Subject Confirmations, and Holder of Key
> is
> the only one that has a KeyInfo element, both bearer and sender vouches
> don't.
>
> So in the IssuedTokenPolicyValidator I still think it's only valid to check
> for a Subject KeyInfo in the Holder of Key case.  This would probably apply
> to SymmetricKey too I'm guessing.
>
> I've managed to work around the problem to some degree by simply not
> specifying a KeyType in the WS-Policy, which means that it defaults to
> SymmetricKey, but doesn't actually validate it. However this caused
> problems
> with our STS because it doesn't actually support SymmetricKey, I did manage
> to patch it, so that it doesn't explode, but it's not an ideal solution.
>
> Thanks,
>
> Joel
>
>
>
> --
> View this message in context:
> http://cxf.547215.n5.nabble.com/CXF-Service-can-t-process-PublicKey-SAML-Sender-Vouches-IssuedToken-in-WS-Policy-tp5739904p5740280.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>



-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

Reply via email to