Skip to main content

Multiple SAML assertions in SOAP request

51 replies [Last post]
markus_franke
Offline
Joined: 2007-10-10

According to Shyam's post http://forums.java.net/jive/thread.jspa?messageID=227078&#227078 it should be possible to request one SAML assertion via sp:IssuedToken in sp:ProtectionToken in sp:SymmetricBinding and an additional one via sp:SignedSupportingTokens.

In a first stept I tried to request a UsernameToken. The resulting WSDL is similar to the policy referenced in WS-SecurityPolicy, chapter "C.2.1 Policy". The test runs well: on client side the usernameHandler was invoked, and the request contains a wsse:UsernameToken.

Thus I assumed the actual mechnism is available.

In the next step I added a sp:IssuedToken assertion (with the same sp:RequestSecurityTokenTemplate as the sp:IssuedToken in sp:SymmetricBinding uses) and rerun the test. In the log I saw a lot of additional RST / RSTR stuff (additional means: additional to the usual RST / RSTR stuff necessary requesting the SAML assertion for the sp:ProtectionToken).

The resulting request contains (as above) the wsse:UsernameToken and the SAML assertion requested by sp:ProtectionToken. But it did not contain the additional SAML assertion.

Furthermore the Web service blames me "Could not find Reference #uuid_9bf2047f-4c15-410a-a1b2-8b2da2d1cb2f under Signature with ID_1". It seems that on client side the SAML assertion was included in the signature computation, but it is not injected into the actual request. Note that the ds:Signature contains the reference to the wsse:UsernameToken and wsse:UsernameToken is present in the request.

I am using nightly build 2007-10-11 on client side and build 2007-09-04 on server side.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
shyam_rao
Offline
Joined: 2006-05-05

I am not able to reproduce this problem.

I tried with similar scenario (service wsdl has) :
1) Issued SAML assertion
2) Another SAML as supporting token

I have put the getSAMLAssertion method from ( http://weblogs.java.net/blog/kumarjayanti/archive/2007/12/accessing_the_... ) into my service code. Here, Subject.getPublicCredentials() returns two XMLStreamReader for two SAML tokens in the request message. But, Subject.getPublicCredentials() doesn't contain any entry of type "Assertion".

markus_franke
Offline
Joined: 2007-10-10

> I am not able to reproduce this problem.
>
> I tried with similar scenario (service wsdl has) :
> 1) Issued SAML assertion
> 2) Another SAML as supporting token

Sorry, that's really embarrassing for me: we injected the Assertion object ourselves because in recent WSIT versions the assertion was only accessible via

messageContext.get("incoming_saml_assertion");

I assume now is the right time to remove this code.

markus_franke
Offline
Joined: 2007-10-10

> You can overcome this issue by using
> sp:SupportingTokens/../sp:SamlToken policy instead of
> sp:SignedSupportingTokens/../sp:SamlToken in your
> service wsdl to include 2nd signed SAML Token
>
> We already have a bug filed for this issue :
> https://wsit.dev.java.net/issues/show_bug.cgi?id=728

Yippieyeah, it seems to work! Thanks for the hint according the SignedSupportingTokens / SupportingTokens.

The logging shows that all assertions are sent. In fact I am using 1 sp:IssuedToken and 2 sp:SAMLToken.

Now I have to fix (i.e. remove the UsernameToken.password hack) my deployment. I inform when everthing is working (and also when not ;-) )

Thanks for your patience.

shyam_rao
Offline
Joined: 2006-05-05

You can overcome this issue by using sp:SupportingTokens/../sp:SamlToken policy instead of sp:SignedSupportingTokens/../sp:SamlToken in your service wsdl to include 2nd signed SAML Token

We already have a bug filed for this issue : https://wsit.dev.java.net/issues/show_bug.cgi?id=728

kumarjayanti
Offline
Joined: 2003-12-10

Changing to SupportingTokens should be OK for your usecase because your SAML assertion is already a Signed assertion.

We normally sign a Sender-Vouches SAML Assertion (which does not contain any signature) to bind it to the message.

markus_franke
Offline
Joined: 2007-10-10

> Hi,
>
> As a first step to get this working can you add the
> self-signed cert to the Server Truststore then you
> should see this scenario passing.
>
> But as a more general case where the SAML assertion
> just has an RSA PublicKey we will see how to get
> around this problem.

I just tried it with the certificate instead of the public key, i.e.

assertion.sign(certificate, privateKey);

instead of

assertion.sign(certificate.getPublicKey(), privateKey);

but this results in a NPE deep in WSIT. How coulds this be?

com.sun.xml.wss.saml.SAMLException: com.sun.xml.wss.saml.SAMLException: java.lang.NullPointerException
at com.sun.xml.wss.saml.assertion.saml11.jaxb20.Assertion.sign(Assertion.java:192)
at com.siemens.medstage.ecr.security.sample.efaclient.callback.GuarantorAssertionCallbackHandler.getAssertion(GuarantorAssertionCallbackHandler.java:183)
...
Caused by: com.sun.xml.wss.saml.SAMLException: java.lang.NullPointerException
at com.sun.xml.wss.saml.assertion.saml11.jaxb20.Assertion.sign(Assertion.java:360)
at com.sun.xml.wss.saml.assertion.saml11.jaxb20.Assertion.sign(Assertion.java:188)
... 78 more
Caused by: java.lang.NullPointerException
at com.sun.xml.messaging.saaj.soap.impl.ElementImpl.addTextNode(ElementImpl.java:431)
at com.sun.xml.wss.core.ReferenceElement.addTextNode(ReferenceElement.java:120)
at com.sun.xml.wss.core.reference.KeyIdentifier.setReferenceValue(KeyIdentifier.java:136)
at com.sun.xml.wss.saml.assertion.saml11.jaxb20.Assertion.sign(Assertion.java:320)
... 79 more

>
> Do you think it is a good idea for an STS to issue
> a SAML assertion which only has a public key ?. The
> Relying Party will have no way to ascertain the
> validity-period of such an assertion.

This SAML assertion is not issued by an STS. It is self-issued be the client invoking the STS and is currently for transporting additional attributes.

>
> Thanks.

markus_franke
Offline
Joined: 2007-10-10

> I just tried it with the certificate instead of the
> public key, i.e.
>
> assertion.sign(certificate, privateKey);
>
> instead of
>
> assertion.sign(certificate.getPublicKey(),
> privateKey);
>
> but this results in a NPE deep in WSIT. How coulds
> this be?
>
> t
> com.sun.xml.wss.saml.assertion.saml11.jaxb20.Assertion
> .sign(Assertion.java:360)
> at
> t
> com.sun.xml.wss.saml.assertion.saml11.jaxb20.Assertion
> .sign(Assertion.java:188)
> ... 78 more
> Caused by: java.lang.NullPointerException
> at
> t
> com.sun.xml.messaging.saaj.soap.impl.ElementImpl.addTe
> xtNode(ElementImpl.java:431)
> at
> t
> com.sun.xml.wss.core.ReferenceElement.addTextNode(Refe
> renceElement.java:120)
> at
> t
> com.sun.xml.wss.core.reference.KeyIdentifier.setRefere
> nceValue(KeyIdentifier.java:136)
> at
> t
> com.sun.xml.wss.saml.assertion.saml11.jaxb20.Assertion
> .sign(Assertion.java:320)
> ... 79 more
>

Could it be that the certificate must contain a SubjectKeyIdentifier extension? My certificate does not.

shyam_rao
Offline
Joined: 2006-05-05

> Could it be that the certificate must contain a
> SubjectKeyIdentifier extension? My certificate does
> not.

Its not like that. If you used assertion.sign(certificate, privateKey); then X509Certificate will be included as X509Data under KeyInfo, when SKI is not present in the certificate.

I guess, in your case getSubjectKeyIdentifier(certificate) might be returning empty string instead of returning null when SKI is not present.

Can you check whether you certificate is returning emtpy byte array or null for "SUBJECT KEY IDENTIFIER OID".
byte[] subjectKeyIdentifier = cert.getExtensionValue("2.5.29.14");

Can you send me your certificate for debugging this issue ?

Message was edited by: shyam_rao

markus_franke
Offline
Joined: 2007-10-10

> Can you check whether you certificate is returning
> emtpy byte array or null for "SUBJECT KEY IDENTIFIER
> OID".
> byte[] subjectKeyIdentifier =
> cert.getExtensionValue("2.5.29.14");

Returns null.

>
> Can you send me your certificate for debugging this
> issue ?

Certificate is attached. toString() output is below:

[
[
Version: V3
Subject: EMAILADDRESS=ukg.med4@rhoen-klinikum.de, O=Rhoen-Klinikum.de, OU=Universitaetsklinikum Giessen, CN=UKG Medizinische Klinik 4
Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5

Key: Sun RSA public key, 1016 bits
modulus: 524134399115159304170285294247306550734000147933561874008040516637596548945637456644248837002435510594276794188305780319168636606043233363961178582728260824403765991834994530658050008895039790035965230970367796822243736360833928310610495307310072301642309754764749316729612217975185192434788357308324962499
public exponent: 65537
Validity: [From: Fri Nov 16 14:32:08 CET 2007,
To: Mon Dec 31 02:01:01 CET 2040]
Issuer: O=Rhoen-Klinikum.de, CN=Rhoen-Klinikum AG Demo-CA
SerialNumber: [ 473d9bd8]

Certificate Extensions: 2
[1]: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
DigitalSignature
]

[2]: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
CA:false
PathLen: undefined
]

]
Algorithm: [SHA1withRSA]
Signature:
0000: 55 64 3A 64 47 57 91 A6 3D 95 BD CA E2 2B 0C 8F Ud:dGW..=....+..
0010: A5 40 8F C1 61 AE 26 2E 3C AB 9E 7F E8 FD 69 BB .@..a.&.<.....i.
0020: 60 6E 36 99 62 7B 78 88 78 4C F4 1A 82 64 24 1A `n6.b.x.xL...d$.
0030: 94 F7 4F 5D 08 2B 5E AE 2D 90 64 65 82 B4 6A A3 ..O].+^.-.de..j.
0040: 4E 9B F2 C4 58 87 53 93 FC 77 5A CC D9 0C 5A BF N...X.S..wZ...Z.
0050: 46 A4 6D C2 80 CB 32 F1 A5 E7 F3 8D 50 92 FA C9 F.m...2.....P...
0060: 5F 05 F8 E0 FC 12 0F EF 6D E9 D6 37 11 0B 20 83 _.......m..7.. .
0070: 6E 2A 7A C2 D0 C5 CE AA A3 8B 31 04 42 29 FF n*z.......1.B).

]

shyam_rao
Offline
Joined: 2006-05-05

> > Can you check whether you certificate is returning
> > emtpy byte array or null for "SUBJECT KEY
> IDENTIFIER
> > OID".
> > byte[] subjectKeyIdentifier =
> > cert.getExtensionValue("2.5.29.14");
>
> Returns null.
>

It should work.

Sorry, i didn't ask you for pfx file instead of certificate in my previous post.

Can you attach the pfx file here, so as i can import (certificate/private-key) pair it into my keystore and debug it.

Or, you can attach your keystore here.

markus_franke
Offline
Joined: 2007-10-10

> Sorry, i didn't ask you for pfx file instead of
> certificate in my previous post.
>
> Can you attach the pfx file here, so as i can import
> (certificate/private-key) pair it into my keystore
> and debug it.
>
> Or, you can attach your keystore here.

No problem. JKS attached. Password is "changeit".

Thanks.

shyam_rao
Offline
Joined: 2006-05-05

Its working fine for me on client side. I used certificate of key entry of alias "ecr_client" for Saml Signature from your keystore eCR_Client_keystore.jks.

The only issue i see there, this certificate is not a self-signed, so validation of certificate gets failed on server. As issuer of this certificate is not present in the truststore.

markus_franke
Offline
Joined: 2007-10-10

> Its working fine for me on client side. I used
> certificate of key entry of alias "ecr_client" for
> Saml Signature from your keystore
> eCR_Client_keystore.jks.

Yes, it works. I was lost in a "various WSIT versions and logfiles tohuwabohu".
>
> The only issue i see there, this certificate is not a
> self-signed, so validation of certificate gets failed
> on server. As issuer of this certificate is not
> present in the truststore.

I am not sure if I got you right. Now I am presenting an assertion signed via assertion.sign(certificate, privateKey); The certificate is CA signed and the server side trusts this CA. But the server throws an exception (using WSIT 2008-01-10):

21.01.2008 12:19:34 com.sun.xml.wss.impl.misc.DefaultSecurityEnvironmentImpl getCertificate
SCHWERWIEGEND: WSS0221: Unable to locate matching certificate for [B@1c96492 using Callback Handler.
21.01.2008 12:19:34 com.sun.xml.ws.security.opt.impl.incoming.KeySelectorImpl resolveKeyIdentifier
SCHWERWIEGEND: WSS1377: An Execption occured while trying to resolve KeyInfo
com.sun.xml.wss.XWSSecurityException: No Matching public key for HQAUF4n00OG6GVe+3eUt2Jeanz4= subject key identifier found
at com.sun.xml.wss.impl.misc.DefaultSecurityEnvironmentImpl.getCertificate(DefaultSecurityEnvironmentImpl.java:617)
at com.sun.xml.ws.security.opt.impl.incoming.KeySelectorImpl.resolveKeyIdentifier(KeySelectorImpl.java:635)
at com.sun.xml.ws.security.opt.impl.incoming.processor.SecurityTokenProcessor.processKeyIdentifier(SecurityTokenProcessor.java:378)
at com.sun.xml.ws.security.opt.impl.incoming.processor.SecurityTokenProcessor.resolveReference(SecurityTokenProcessor.java:120)
at com.sun.xml.ws.security.opt.impl.incoming.processor.KeyInfoProcessor.processKeyInfo(KeyInfoProcessor.java:127)
at com.sun.xml.ws.security.opt.impl.incoming.processor.KeyInfoProcessor.getKey(KeyInfoProcessor.java:113)
at com.sun.xml.ws.security.opt.impl.incoming.Signature.process(Signature.java:274)
at com.sun.xml.ws.security.opt.impl.incoming.Signature.process(Signature.java:346)
at com.sun.xml.ws.security.opt.impl.incoming.SAMLAssertion.process(SAMLAssertion.java:206)
at com.sun.xml.ws.security.opt.impl.incoming.SAMLAssertion.(SAMLAssertion.java:102)
at com.sun.xml.ws.security.opt.impl.incoming.SecurityRecipient.handleSecurityHeader(SecurityRecipient.java:417)

The server side logging (attached) shows that the certificate is included in the headers as a , thus the server side should be able to find it.

Adding the certificate itself to the truststore helps, but this is not what I want to do.

shyam_rao
Offline
Joined: 2006-05-05

> The server side logging (attached) shows that the
> certificate is included in the headers as a
> , thus the server side
> should be able to find it.

This Certificate is not the one used for signing SAML. It is included, because your security policy must have IncludeToken="Always" or "AlwaysToRecipient" in the serve wsdl.

>
> Adding the certificate itself to the truststore
> helps, but this is not what I want to do.

Here, certificate is referenced by SubjectKeyIdentifier for SAML Signature, so this certificate has to be in server truststrore.

Here is the way, you can include X509Certificate directly under KeyInfo :

1) assertion.sign(certificate, privateKey) : here certificate may or may not be included depending on the SKI presence.
2) assertion.sign(certificate, privateKey, alwaysIncludeCert) : alwaysIncludeCert is a boolean value, which tells you to include certificate or not (if SKI is present in the certificate and if you do want to include certificate, then alwaysIncludeCert=true will do this job). Here certificate may or may not have SKI

Note : You need to use latest wsit nightly

shyam_rao
Offline
Joined: 2006-05-05

I have fixed it. Can you try with today's wsit nightly build from here : https://jax-ws.dev.java.net/servlets/ProjectDocumentList?folderID=5472&e...

rkuhli
Offline
Joined: 2008-01-08

Hi,

how can I retieve the saml assertion with SV confirmation method? The HOK assertion is still accessible via
javax.xml.ws.handler.MessageContext.get(com.sun.xml.wss.impl.MessageConstants.INCOMING_SAML_ASSERTION);

Thanks.

shyam_rao
Offline
Joined: 2006-05-05

Look at this blog for "Accessing the SAML Assertion in the WebService" :
http://weblogs.java.net/blog/kumarjayanti/archive/2007/12/accessing_the_...

markus_franke
Offline
Joined: 2007-10-10

> Look at this blog for "Accessing the SAML Assertion
> in the WebService" :
> http://weblogs.java.net/blog/kumarjayanti/archive/2007
> /12/accessing_the_s.html

Following this instructions I found 3 public credentials in the subject:
- 1 Assertion
- 2 XMLStreamReader
whereas the Assertion instance contains the HOK SAML assertion. I did not decode them but I assume that the 2 XMLStreamReader objects contain the SV and (again) the HOK assertion. Is this correct?

But my actual questions are the following:
a) So far as I see all SAML assertions in the SOAP message are validated, i.e. assertion signature validation and certificate validation is done, right?
b) Since a) implies the SV assertion to be parsed could it not be provided as an Assertion object to the Web service endpoint implementation rather than as an XMLStreamReader object?

Thanks.

kumarjayanti
Offline
Joined: 2003-12-10

Not sure what is happening.

Can you tell me how many IssuedToken + SAML Tokens put together were there in your WSDL Policy ?.

SV assertions do not contain any signature/cert so there is no default validation done by WSIT for them.

Signatures of HOK assertions are verified.

It is not clear which of your assertions is resulting in "Assertion". Can you send the relevant policy .

markus_franke
Offline
Joined: 2007-10-10

> Not sure what is happening.
>
> Can you tell me how many IssuedToken + SAML Tokens
> put together were there in your WSDL Policy ?.
>

The WSDL requests 2 assertions. One HOK assertion cointaining AttributeStatements issued by an STS





http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1
http://schemas.xmlsoap.org/ws/2005/02/trust/SymmetricKey
256







and one SV assertion containing XAMLPolicyStatements



sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient">


http://localhost:8080/accessprovider/xacmlpolicystmt







> SV assertions do not contain any signature/cert so
> there is no default validation done by WSIT for them.
>

Both SAML assertions are signed by the issuer and thus they contain signatures and the certificate of the assertion issuer.

>
> Signatures of HOK assertions are verified.
>
> It is not clear which of your assertions is resulting
> in "Assertion". Can you send the relevant policy .

Subject.getPublicCredentials() returns
- XMLStreamReader containing the AttributeStatement assertion (HOK)
- XMLStreamReader containing the XAMLPolicyStatement assertion (SV)
- com.sun.xml.wss.saml.assertion.saml11.jaxb20.Assertion containing the AttributeStatement assertion (HOK)

Thus the AttributeStatement assertion is provided twice, the XAMLPolicyStatement assertion only once. But experiments showed that also sp:SupportingTokens assertions seem to be validated by the WSIT server side stack, but only the XMLStreamReader version is provided to the Web service endpoint implementation but not the com.sun.xml.wss.saml.assertion.saml11.jaxb20.Assertion version.

kumarjayanti
Offline
Joined: 2003-12-10

Thanks for the info. Looks like it is an issue. The intent was to only supply XMLStreamReader for both the cases. And we actually avoid converting an XMLStreamReader into an Assertion (for performance reasons) and let end-users do it on an as needed basis.

Will check and get back.

markus_franke
Offline
Joined: 2007-10-10

> And we actually avoid converting an
> XMLStreamReader into an Assertion (for performance
> reasons) and let end-users do it on an as needed
> basis.

That's the point I do not understand. All SAML assertions seem to be validated (i.e. validation of signature of SAML assertion as well as path validation of certificate used for issuing the SAML assertion). So the Assertion object must be present in WSIT stack. So why not providing this representation also to the endpoint?

kumarjayanti
Offline
Joined: 2003-12-10

For performance reasons, the Signature Verification happens in a Streaming Fashion by default and so we do not convert to an Assertion for the purpose of validation.

markus_franke
Offline
Joined: 2007-10-10

> Right.. The Fault is being thrown from WSIT server
> security component. Not sure what is wrong with the
> RST request.

I have this problem when using FCS 1.0 on client side as well the mentionend nightly builds on client side. Maybe the SOAPFault will provide some more information.

> I have made the fix for the IllegalArgument. You
> should be able to try tomorrow. I still have to
> commit the fixed XWSS jars into WSIT, will do it
> early morning India Time tomorrow.

Thanks.

markus_franke
Offline
Joined: 2007-10-10

With build 2008-01-08 I get following failure message, without any stacktrace on the console:




http://www.w3.org/2005/08/addressing/anonymous
http://www.w3.org/2005/08/addressing/fault
uuid:19249a20-616f-41e0-8568-6666e19b0aeb
uuid:c43f00dd-495b-4f15-88b8-9c584c2e37a5




S:Sender

wsse:InvalidSecurityToken



javax.xml.ws.soap.SOAPFaultException







































On client side I used WSIT FCS 1.0. Since I did not change any keystores / truststore I do not understand the subcode "wsse:InvalidSecurityToken".

kumarjayanti
Offline
Joined: 2003-12-10

Hi,

Sorry to see that you are still having problems. In this case there should be a log in the Server log file about what has caused the fault.

The wsse:InvalidSecurityToken FaultCode indicates there was a validation failure on the server. If you want to know the details (look in the server log) or you can get the details in the message by setting the following VM Property on the Server Side :

-Dcom.sun.xml.wss.debug=FaultDetail

This will cause the details of the Fault to appear in the Message recieved by the client.

Let us know if this helps. We are keen to get your scenario to work.

Thanks.

markus_franke
Offline
Joined: 2007-10-10

When validating the SAML assertion I receive a NPE because a null certificate is provided to the validate method. But: the (self-signed) SAML assertion does not contain a certificate, but only a RSA public key (the assertion is attached).

java.lang.NullPointerException
at com.sun.xml.wss.impl.misc.DefaultCallbackHandler$X509CertificateValidatorImpl.validate(DefaultCallbackHandler.java:1393)
at com.sun.xml.wss.impl.callback.CertificateValidationCallback.getResult(CertificateValidationCallback.java:58)
at com.sun.xml.wss.impl.misc.DefaultSecurityEnvironmentImpl.validateCertificate(DefaultSecurityEnvironmentImpl.java:677)
at com.sun.xml.ws.security.opt.impl.incoming.processor.KeyInfoProcessor.processKeyInfo(KeyInfoProcessor.java:149)
at com.sun.xml.ws.security.opt.impl.incoming.processor.KeyInfoProcessor.getKey(KeyInfoProcessor.java:113)
at com.sun.xml.ws.security.opt.impl.incoming.Signature.process(Signature.java:274)
at com.sun.xml.ws.security.opt.impl.incoming.Signature.process(Signature.java:346)
at com.sun.xml.ws.security.opt.impl.incoming.SAMLAssertion.process(SAMLAssertion.java:206)
at com.sun.xml.ws.security.opt.impl.incoming.SAMLAssertion.<init>(SAMLAssertion.java:102)
at com.sun.xml.ws.security.opt.impl.incoming.SecurityRecipient.handleSecurityHeader(SecurityRecipient.java:417)
at com.sun.xml.ws.security.opt.impl.incoming.SecurityRecipient.cacheHeaders(SecurityRecipient.java:252)
at com.sun.xml.ws.security.opt.impl.incoming.SecurityRecipient.validateMessage(SecurityRecipient.java:198)
at com.sun.xml.wss.jaxws.impl.SecurityPipeBase.verifyInboundMessage(SecurityPipeBase.java:445)
at com.sun.xml.wss.jaxws.impl.SecurityServerPipe.process(SecurityServerPipe.java:187)
at com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:115)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:595)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:554)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:539)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:436)
at com.sun.xml.ws.server.WSEndpointImpl$2.process(WSEndpointImpl.java:243)
at com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:444)
at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:244)
at com.sun.xml.ws.transport.http.servlet.ServletAdapter.handle(ServletAdapter.java:135)
at com.sun.xml.ws.transport.http.servlet.WSServletDelegate.doGet(WSServletDelegate.java:129)
at com.sun.xml.ws.transport.http.servlet.WSServletDelegate.doPost(WSServletDelegate.java:160)
at com.sun.xml.ws.transport.http.servlet.WSServlet.doPost(WSServlet.java:75)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)

kumarjayanti
Offline
Joined: 2003-12-10

Hi,

As a first step to get this working can you add the self-signed cert to the Server Truststore then you should see this scenario passing.

But as a more general case where the SAML assertion just has an RSA PublicKey we will see how to get around this problem.

Do you think it is a good idea for an STS to issue a SAML assertion which only has a public key ?. The Relying Party will have no way to ascertain the validity-period of such an assertion.

Thanks.

kumarjayanti
Offline
Joined: 2003-12-10

Or maybe i am wrong. The Assertion can have its own Condition statement indicating the validity period ...

Thanks.

markus_franke
Offline
Joined: 2007-10-10

OK, let's get back to the actual problem: sending multiple (SAML) assertions

The WSDL requests
a) a SAML assertion (containing attribute statements) requested via sp:ProtectionToken/../sp:IssuedToken
b) an additional SAML assertion (containing authorization statements) requested via SAMLToken sp:SignedSupportingToken/../sp:SamlToken

With these settings I encounter following stacktrace on client side (using build 2008-01-17):

21.01.2008 22:07:49 com.sun.xml.ws.security.opt.impl.dsig.SignatureProcessor sign
SCHWERWIEGEND: WSS1701: Sign operation failed.
java.lang.ArrayIndexOutOfBoundsException: 20
at com.sun.xml.wss.impl.c14n.StAXC14nCanonicalizerImpl.writeStartElement(StAXC14nCanonicalizerImpl.java:360)
at com.sun.xml.wss.impl.c14n.StAXEXC14nCanonicalizerImpl.writeStartElement(StAXEXC14nCanonicalizerImpl.java:94)
at com.sun.xml.ws.security.opt.impl.dsig.StAXSTRTransformWriter.writeStartElement(StAXSTRTransformWriter.java:338)
at com.sun.xml.ws.security.opt.impl.util.DOMUtil.writeTagWithAttributes(DOMUtil.java:140)
at com.sun.xml.ws.security.opt.impl.util.DOMUtil.serializeNode(DOMUtil.java:103)
at com.sun.xml.ws.security.opt.impl.util.DOMUtil.serializeNode(DOMUtil.java:125)
at com.sun.xml.ws.security.opt.impl.util.DOMUtil.serializeNode(DOMUtil.java:125)
at com.sun.xml.ws.security.opt.impl.util.DOMUtil.serializeNode(DOMUtil.java:125)
at com.sun.xml.ws.security.opt.impl.message.GSHeaderElement.writeTo(GSHeaderElement.java:135)
at com.sun.xml.ws.security.opt.impl.message.GSHeaderElement.writeTo(GSHeaderElement.java:210)
at com.sun.xml.ws.security.opt.impl.crypto.SSEData.write(SSEData.java:87)
at com.sun.xml.ws.security.opt.impl.dsig.StAXSTRTransformWriter.write(StAXSTRTransformWriter.java:396)
at com.sun.xml.ws.security.opt.crypto.dsig.Exc14nCanonicalizer.transform(Exc14nCanonicalizer.java:139)
at com.sun.xml.ws.security.opt.crypto.dsig.Transform.transform(Transform.java:160)
at com.sun.xml.ws.security.opt.crypto.dsig.Reference.transform(Reference.java:169)
at com.sun.xml.ws.security.opt.crypto.dsig.Reference.digest(Reference.java:110)
at com.sun.xml.ws.security.opt.crypto.dsig.Signature.sign(Signature.java:200)
at com.sun.xml.ws.security.opt.impl.dsig.SignatureProcessor.sign(SignatureProcessor.java:105)
at com.sun.xml.wss.impl.filter.SignatureFilter.sign(SignatureFilter.java:521)
at com.sun.xml.wss.impl.filter.SignatureFilter.process(SignatureFilter.java:483)
at com.sun.xml.wss.impl.HarnessUtil.processWSSPolicy(HarnessUtil.java:79)
at com.sun.xml.wss.impl.HarnessUtil.processDeep(HarnessUtil.java:249)
at com.sun.xml.wss.impl.SecurityAnnotator.processMessagePolicy(SecurityAnnotator.java:172)
at com.sun.xml.wss.impl.SecurityAnnotator.secureMessage(SecurityAnnotator.java:133)
at com.sun.xml.wss.jaxws.impl.SecurityPipeBase.secureOutboundMessage(SecurityPipeBase.java:392)
...

My first thought was that the SAML assertion is not properly encoded, e.g. has namespace issues. Thus I tried modified the SAMLCallback to use the STS issued SAML assertion also for the sp:SAMLToken assertion (this assertion seems to be acceptable for the WSIT stack), but this had the same effect.

Note that requesting a UsernameToken instead the second SAML assertion works.

So what could be the reason for this stacktrace: namespace issues, deficiently generate SAML assertion, ... ?

Thanks.

shyam_rao
Offline
Joined: 2006-05-05

> My first thought was that the SAML assertion is not
> properly encoded, e.g. has namespace issues. Thus I
> tried modified the SAMLCallback to use the STS issued
> SAML assertion also for the sp:SAMLToken assertion
> (this assertion seems to be acceptable for the WSIT
> stack), but this had the same effect.
>
> Note that requesting a UsernameToken instead the
> second SAML assertion works.
>
> So what could be the reason for this stacktrace:
> namespace issues, deficiently generate SAML
> assertion, ... ?

I tried to reproduce it with service wsdl have :
a) a SAML assertion requested via sp:SymmetricBinding/sp:ProtectionToken/../sp:IssuedToken
b) an additional SV SAML assertion (containing attribute statements) requested via SAMLToken sp:SignedSupportingToken/../sp:SamlToken from SamlCallbackHandler

Its working fine for me.

Is it possible for you to attach complete reproducible project here for debugging ? Otherwise, you can only attach your service & sts wsdl here.

Message was edited by: shyam_rao

markus_franke
Offline
Joined: 2007-10-10

Today I found some time to test the fix for this issue. But with build 2007-12-14 and 2008-01-06 I encountered following problems:

a) With recent WSIT implementations my Eclipse XML editor formatted WSDL worked without failures, but now formattings like

http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1

cause java.net.URISyntaxException: Illegal character in scheme name at index 0:
http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1

Replacing it http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1 works.

Is this intentionally?

b) But my main problem is the following: When sending the RST to my identity provider the WSIT stack throws following exception:

com.sun.xml.wss.impl.XWSSecurityRuntimeException: java.lang.IllegalArgumentException: reasonText argument for createFault was passed NULL
at com.sun.xml.ws.security.opt.impl.util.SOAPUtil.getSOAPFault(SOAPUtil.java:137)
at com.sun.xml.ws.security.opt.impl.util.SOAPUtil.getSOAPFaultException(SOAPUtil.java:159)
at com.sun.xml.wss.jaxws.impl.SecurityServerPipe.process(SecurityServerPipe.java:191)
at com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:115)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:595)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:554)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:539)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:436)
at com.sun.xml.ws.server.WSEndpointImpl$2.process(WSEndpointImpl.java:243)
at com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:444)
at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:244)
at com.sun.xml.ws.transport.http.servlet.ServletAdapter.handle(ServletAdapter.java:135)
at com.sun.xml.ws.transport.http.servlet.WSServletDelegate.doGet(WSServletDelegate.java:129)
at com.sun.xml.ws.transport.http.servlet.WSServletDelegate.doPost(WSServletDelegate.java:160)
at com.sun.xml.ws.transport.http.servlet.WSServlet.doPost(WSServlet.java:75)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.IllegalArgumentException: reasonText argument for createFault was passed NULL
at com.sun.xml.messaging.saaj.soap.ver1_2.SOAPFactory1_2Impl.createFault(SOAPFactory1_2Impl.java:90)
at com.sun.xml.ws.security.opt.impl.util.SOAPUtil.getSOAPFault(SOAPUtil.java:131)
... 30 more

With FCS 1.0 it is working. Server log file is attached (created with Tomcat 5.5.25 and WSIT build 2008-01-06).

Any ideas?

kumarjayanti
Offline
Joined: 2003-12-10

Hi,

Problem (a) could appear if what you are doing is copy-paste from your elipse editor into something else (Just guessing). The error seems to indicate there were some extra characters.

For Problem (b), i will fix the current error immediately now :
-----------------------
Caused by: java.lang.IllegalArgumentException: reasonText argument for createFault was passed NULL.
----------------------
This seems to be a regression caused due to some recent changes i did for throwing proper WSS spec defined faults.

However what it means is that the Server (STS) was trying to throw a FAULT for some reason after processing the incoming request. Do you see any other stack trace in the Server Logs.

Thanks.

markus_franke
Offline
Joined: 2007-10-10

Hi.

No, there arent't any stacktraces besides the mentioned one (except the typical "javax.xml.stream.XMLStreamException: XMLStreamReader not positioned at a document or element" exception because the client tries to do the MEX with path /sts first and tries after that /sts/mex).

The STS is completely handcrafted, i.e. implementing invoke(Source), and logging shows that the invoke() method is not invoked at all. Thus I assume the WSIT server side stack is throwing this fault.

Thanks.

kumarjayanti
Offline
Joined: 2003-12-10

Right.. The Fault is being thrown from WSIT server security component. Not sure what is wrong with the RST request.

I have made the fix for the IllegalArgument. You should be able to try tomorrow. I still have to commit the fixed XWSS jars into WSIT, will do it early morning India Time tomorrow.

Nirmal Singh

Hi,

Please unsubscribe my email id from metro@javadesktop.org emails?

Regards,
Nirmal

metro@javadesktop.org wrote: Right.. The Fault is being thrown from WSIT server security component. Not sure what is wrong with the RST request.

I have made the fix for the IllegalArgument. You should be able to try tomorrow. I still have to commit the fixed XWSS jars into WSIT, will do it early morning India Time tomorrow.
[Message sent by forum member 'kumarjayanti' (kumarjayanti)]

http://forums.java.net/jive/thread.jspa?messageID=252524

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@metro.dev.java.net
For additional commands, e-mail: users-help@metro.dev.java.net

---------------------------------
Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.
[att1.html]

Farrukh Najmi

For a while now I am getting emails where sender is identified as
metro@javadesktop.org

Can someone explain what is the metro@javadesktop.org list? I never
subscribed to it. Why am I getting its mail.
Also what does metro have with the desktop?

I am guessing that someone has made some mistake with a mailing list
configuration somewhere.

Can someone from Metro team please post an explanation. Thanks.

Nirmal Singh wrote:
> Hi,
>
> Please unsubscribe my email id from metro@javadesktop.org emails?
>
> Regards,
> Nirmal
>
> */metro@javadesktop.org/* wrote:
>
> Right.. The Fault is being thrown from WSIT server security
> component. Not sure what is wrong with the RST request.
>
> I have made the fix for the IllegalArgument. You should be able to
> try tomorrow. I still have to commit the fixed XWSS jars into
> WSIT, will do it early morning India Time tomorrow.
> [Message sent by forum member 'kumarjayanti' (kumarjayanti)]
>
> http://forums.java.net/jive/thread.jspa?messageID=252524
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@metro.dev.java.net
> For additional commands, e-mail: users-help@metro.dev.java.net
>
>
> ------------------------------------------------------------------------
> Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try
> it now.
>

--
Regards,
Farrukh Najmi

Web: http://www.wellfleetsoftware.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@metro.dev.java.net
For additional commands, e-mail: users-help@metro.dev.java.net

Arun Gupta

Hi Farrukh,

This is the standard email id used after users@metro list and Metro
Forum posts are cross-linked to each other.

So all emails from metro@javadesktop.org are originally posted @ Metro
forum. If you respond to the email, then the thread will be
automatically updated on the forum as well. Similarly, if somebody
responds on the forum then another email will be sent to the users list.

This allow users to post their queries on either Metro Forum or users
list and get double the visibility.

HTH,
-Arun

Farrukh Najmi wrote:
> For a while now I am getting emails where sender is identified as
> metro@javadesktop.org
>
> Can someone explain what is the metro@javadesktop.org list? I never
> subscribed to it. Why am I getting its mail.
> Also what does metro have with the desktop?
>
> I am guessing that someone has made some mistake with a mailing list
> configuration somewhere.
>
> Can someone from Metro team please post an explanation. Thanks.
>
> Nirmal Singh wrote:
>> Hi,
>>
>> Please unsubscribe my email id from metro@javadesktop.org emails?
>>
>> Regards,
>> Nirmal
>>
>> */metro@javadesktop.org/* wrote:
>>
>> Right.. The Fault is being thrown from WSIT server security
>> component. Not sure what is wrong with the RST request.
>>
>> I have made the fix for the IllegalArgument. You should be able to
>> try tomorrow. I still have to commit the fixed XWSS jars into
>> WSIT, will do it early morning India Time tomorrow.
>> [Message sent by forum member 'kumarjayanti' (kumarjayanti)]
>>
>> http://forums.java.net/jive/thread.jspa?messageID=252524
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@metro.dev.java.net
>> For additional commands, e-mail: users-help@metro.dev.java.net
>>
>>
>> ------------------------------------------------------------------------
>> Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try
>> it now.
>>
>
>
>
>

--
Application Platform, Sun Microsystems, Inc.
Blog: http://blogs.sun.com/arungupta

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@metro.dev.java.net
For additional commands, e-mail: users-help@metro.dev.java.net

shyam_rao
Offline
Joined: 2006-05-05

> According to Shyam's post
> http://forums.java.net/jive/thread.jspa?messageID=2270
> 78𷜆 it should be possible to request one SAML
> assertion via sp:IssuedToken in sp:ProtectionToken in
> sp:SymmetricBinding and an additional one via
> sp:SignedSupportingTokens.

In this forum post, the user's requirement for implementing the STS was :

"STS will issue a new SAML token for service provider on the basis of incoming SAML tokens in the request message"

And, the way you can introduce more than one SAML token(lets say 2) in the request (client to STS ) by using two SignedSupportingTokens or one EndorsingSupportingToken and one SignedSupportingToken in the STS wsdl, depending on the SAML token contains a key or not.

>
> In a first stept I tried to request a UsernameToken.
> The resulting WSDL is similar to the policy
> referenced in WS-SecurityPolicy, chapter "C.2.1
> Policy". The test runs well: on client side the
> usernameHandler was invoked, and the request contains
> a wsse:UsernameToken.
>
> Thus I assumed the actual mechnism is available.
>
> In the next step I added a sp:IssuedToken assertion
> (with the same sp:RequestSecurityTokenTemplate as the
> sp:IssuedToken in sp:SymmetricBinding uses) and rerun
> the test. In the log I saw a lot of additional RST /
> RSTR stuff (additional means: additional to the usual
> RST / RSTR stuff necessary requesting the SAML
> assertion for the sp:ProtectionToken).
>
> The resulting request contains (as above) the
> wsse:UsernameToken and the SAML assertion requested
> by sp:ProtectionToken. But it did not contain the
> additional SAML assertion.

Have you implemented the SamlCallbackHandler on the client side and added this class reference in the client configuration file ?

Can you attach your STS wsdl and service wsdl here ? Also attach output message log.

You can also have a look at the STS sample(netbeans project) of the TechTip(http://blogs.sun.com/enterprisetechtips/entry/supporting_tokens_and_issu...). Here you can see, client is sending a SAML token to sts(you can find the SamlCallbackHandler implementation here), and sts populates the issuedToken for service provider with the information provided in the saml token of the request message.

markus_franke
Offline
Joined: 2007-10-10

> Have you implemented the SamlCallbackHandler on the
> client side and added this class reference in the
> client configuration file ?

No, why do I have to implement it? I am using also an IssuedToken for the SignedSupportingTokens, thus I assume retrieving and injecting the SAML assertion is automatically done by the WSIt client side stack, i.e. doing RST / RSTR with an STS and then putting it into the request.

>
> Can you attach your STS wsdl and service wsdl here ?
> Also attach output message log.

STS issuing the SAML assertion (AttributeStatement) requested by ProtectionToken and STS issuing the SAML assertion (AuthnStatement) are more or less standard STSes.

WSDL and log are attached. The WSDL is name sts.wsdl since the first version of the Web service was a real STS. But things change over time ... Nevertheless this Web service is issueing SAML assertion.

jdg6688
Offline
Joined: 2005-11-02

The WSDL is confusing:

Let's first get your use case clarified before we can do anything:

In order to access the STS (STS1) as specified by your STS wsdl, you need to
1. get an issued SAML token from another STS (STS2): http://localhost:8080/dirxaccess-fep-efa-attributeprovider/sts
2. username/password
3. aother issued SAML token from
yet another STS (STS3): http://localhost:8080/dirxaccess-fep-efa-identityprovider/sts

right?

If yes, the way you specified in your WSDL is not going to work.

Also are the three tokens (saml token from STS1, saml token from STS2 and the username.password represent the same user?

Dependin on your answers, I can suggest you some solutions to your problem?

Thanks!

jdg6688
Offline
Joined: 2005-11-02

> The WSDL is confusing:
>
> Let's first get your use case clarified before we can
> do anything:
>
> In order to access the STS (STS1) as specified by
> your STS wsdl, you need to
> 1. get an issued SAML token from another STS (STS2):
> http://localhost:8080/dirxaccess-fep-efa-attributeprov
> ider/sts
> 2. username/password
> 3. aother issued SAML token from
> yet another STS (STS3):
> http://localhost:8080/dirxaccess-fep-efa-identityprovi
> der/sts
>
> right?
>
> If yes, the way you specified in your WSDL is not
> going to work.
>
> Also are the three tokens (saml token from STS1, saml
> token from STS2 and the username.password represent
> the same user?
Oops, I mean saml token from STS2, saml token from STS3 and the usename/password pair.

>
> Dependin on your answers, I can suggest you some
> solutions to your problem?
>
> Thanks!

markus_franke
Offline
Joined: 2007-10-10

Yes, that is correct.

But the UsernameToken was only introduced for testing purposes, it is actually not required. Required are only the SAML assertions from STS2 and from STS3. Both represent the same user.

By the way: when invoking afterwards the next Web service the SAML assertion from STS2 (attributeprovider) and from STS1 should be presented.

jdg6688
Offline
Joined: 2005-11-02

Ok.

You need some extra effort to make this work:

1. The STS1 wsdl specify you need an issued token from STS3 as ProtectionToken and
a EndorsingSupportingToken with a SAMLToken assertion.

2. You need to have a separate call to STS2 to get the SAML assertion of AttributeStatement type. STS2 is an AttributeProvider. We have STS client API for STS call.

3. Cache the SAML assertion get from STS2 in certain place.

4. Write a SAMLCallbackHandler to get the SAML assertion in 2 and for use with
the call to STS1.

5. The next Web service sepcifies to use the issuedToken from STS1 as well as
a SAML token. Theis token will be obtained again using the SAMLCallbackHandler in 4.

markus_franke
Offline
Joined: 2007-10-10

> 2. You need to have a separate call to STS2 to get
> the SAML assertion of AttributeStatement type. STS2
> is an AttributeProvider. We have STS client API for
> STS call.
>
Can you please give me a link to the STS client API?

jdg6688
Offline
Joined: 2005-11-02

String stsEndpoint = "http://localhost:8080/jaxws-sts/SecurityTokenService";
String stsMexAddress = "http://localhost:8080/jaxws-sts/SecurityTokenService/mex";
STSIssuedTokenConfiguration config = new DefaultSTSIssuedTokenConfiguration(
stsEndpoint, stsMexAddress);
IssuedTokenManager manager = IssuedTokenManager.getInstance();
String appliesTo = "http://localhost:8080/jaxws-fs/FinancialService";
IssuedTokenContext ctx = manager.createIssuedTokenContext(config, appliesTo);
manager.getIssuedToken(ctx);

Token issuedToken = ctx.getSecurityToken();
byte[] proofKey = ctx.getProofKey();

markus_franke
Offline
Joined: 2007-10-10

Thanks for your hint. But I tried another way without invoking the client STS calls explicitly.

So far as I see it is not possible to register callback handlers that are invoked on client side when an sp:IssuedToken is requested, only callbacks for sp:SamlToken are supported. Thus whenever an sp:IssuedToken is request an RST / RSTR exchange is executed. (And I do not have a chance to cache the SAML assertion in a SAML callback handler.)

So I modified the settings a little bit. In the old WSDL I tried to request 2 SAML assertions each via sp:IssuedToken. Now I switched to IssuedToken + SamlToken.

Lets describe the scenario with real service names:

The target service (= AccessProvider) requires following assertions:
a) SAML assertion (containing attribute statements) requested via sp:ProtectionToken/../sp:IssuedToken and issued by AttributeProvider
b) SAML assertion (containing authorizatation statements) requested via SAMLToken sp:SignedSupportingToken/../sp:SamlToken and issued by AdmissionProvider

Theoretically everything works. But I encountered following problems with the nightly build 2007-10-25:

a) According the server logfile both SAML assertions are sent as desired. But I encountered a NullPointerException on server side:

java.lang.NullPointerException
at com.sun.xml.wss.impl.misc.SecurityUtil.initInferredIssuedTokenContext(SecurityUtil.java:419)
at com.sun.xml.ws.security.opt.impl.incoming.KeySelectorImpl.resolveKeyIdentifier(KeySelectorImpl.java:768)
at com.sun.xml.ws.security.opt.impl.incoming.processor.SecurityTokenProcessor.processKeyIdentifier(SecurityTokenProcessor.java:378)
at com.sun.xml.ws.security.opt.impl.incoming.processor.SecurityTokenProcessor.resolveReference(SecurityTokenProcessor.java:120)

Complete stacktrace is in log-server.txt.

It seems that the sp:SignedSupportingToken/../sp:SamlToken overrides the sp:IssuedToken in some kind of context store and thus the access to the derived key causes a NPE.

b) When the SAML assertion requested by sp:SamlToken contains a XACMLAuthzDecisionStatement I encounter a signature failure on client side because

SCHWERWIEGEND: WSS1701: Sign operation failed.
java.lang.ArrayIndexOutOfBoundsException: 20
at com.sun.xml.wss.impl.c14n.StAXC14nCanonicalizerImpl.writeStartElement(StAXC14nCanonicalizerImpl.java:360)
at com.sun.xml.wss.impl.c14n.StAXEXC14nCanonicalizerImpl.writeStartElement(StAXEXC14nCanonicalizerImpl.java:94)

Complete stacktrace is in log-client.txt.

kumarjayanti
Offline
Joined: 2003-12-10

Hi,

You may have hit an issue. I will get back on this.

Thanks.

markus_franke
Offline
Joined: 2007-10-10

Hi.

Did you make any progess with that issue? If you want I can continue analysing the issue next week to nail it down a little bit.

Thanks

jdg6688
Offline
Joined: 2005-11-02

Please file a bug for this. Thanks!

https://wsit.dev.java.net/servlets/ProjectIssues