Skip to main content

Interoperability issue between WSIT M5 and CardSpace

43 replies [Last post]
rebelanger
Offline
Joined: 2006-08-24
Points: 0

Hi,

I'm currently working on a WS-Trust STS project using WSIT to produce security tokens for the CardSpace technology.

This works fine with the Milestone 2 version but after having upgraded to Milestone 5 it seems that the signature of the SOAP body generated by WSIT cannot be verified by the CardSpace Identity Selector. Here is the error message it has dumped into the Event Viewer log:

There was a failure making a WS-Trust exchange with an external application. Could not retrieve token from identity provider.

Inner Exception: The signature verification failed. Please see inner exception for fault details.
Inner Exception: Digest verification failed for Reference '#5006'.

Additional Information:
Microsoft.InfoCards.TrustExchangeException: Could not retrieve token from identity provider. ---> System.ServiceModel.Security.MessageSecurityException: The signature verification failed. Please see inner exception for fault details. ---> System.Security.Cryptography.CryptographicException: Digest verification failed for Reference '#5006'.
at System.IdentityModel.Reference.EnsureDigestValidityIfIdMatches(String id, Object resolvedXmlSource)
at System.IdentityModel.StandardSignedInfo.EnsureDigestValidityIfIdMatches(String id, Object resolvedXmlSource)
at System.ServiceModel.Security.WSSecurityOneDotZeroReceiveSecurityHeader.EnsureDigestValidityIfIdMatches(SignedInfo signedInfo, String id, XmlDictionaryReader reader, Boolean doSoapAttributeChecks, MessagePartSpecification signatureParts, MessageHeaderInfo info, Boolean checkForTokensAtHeaders)
--- End of inner exception stack trace ---

Server stack trace:
at System.ServiceModel.Security.WSSecurityOneDotZeroReceiveSecurityHeader.EnsureDigestValidityIfIdMatches(SignedInfo signedInfo, String id, XmlDictionaryReader reader, Boolean doSoapAttributeChecks, MessagePartSpecification signatureParts, MessageHeaderInfo info, Boolean checkForTokensAtHeaders)
at System.ServiceModel.Security.WSSecurityOneDotZeroReceiveSecurityHeader.ExecuteMessageProtectionPass(Boolean hasAtLeastOneSupportingTokenExpectedToBeSigned)
at System.ServiceModel.Security.ReceiveSecurityHeader.Process(TimeSpan timeout)
at System.ServiceModel.Security.MessageSecurityProtocol.ProcessSecurityHeader(ReceiveSecurityHeader securityHeader, Message& message, SecurityToken requiredSigningToken, TimeSpan timeout, SecurityProtocolCorrelationState[] correlationStates)
at System.ServiceModel.Security.SymmetricSecurityProtocol.VerifyIncomingMessageCore(Message& message, String actor, TimeSpan timeout, SecurityProtocolCorrelationState[] correlationStates)
at System.ServiceModel.Security.MessageSecurityProtocol.VerifyIncomingMessage(Message& message, TimeSpan timeout, SecurityProtocolCorrelationState[] correlationStates)
at System.ServiceModel.Channels.SecurityChannelFactory`1.SecurityRequestChannel.ProcessReply(Message reply, SecurityProtocolCorrelationState correlationState, TimeSpan timeout)
at System.ServiceModel.Channels.SecurityChannelFactory`1.SecurityRequestChannel.Request(Message message, TimeSpan timeout)
at System.ServiceModel.Dispatcher.RequestChannelBinder.Request(Message message, TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs)
at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)

Exception rethrown at [0]:
at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
at Microsoft.InfoCards.RemoteTokenFactory.ISts.ProcessRequestSecurityToken(Message rstMessage)
at Microsoft.InfoCards.RemoteTokenFactory.ProduceToken(InfoCard card, TokenCreationParameter parameter, TokenFactoryCredential credential, InfoCardPolicy policy, Boolean discloseOptional)
--- End of inner exception stack trace ---

I've performed the test in the following environment onto which are running both the CardSpace Identity Selector and the implemented STS :

- Microsoft Windows Server 2003 R2, Enterprise Edition, Service Pack 1
- Apache Tomcat 5.5.20
- JRE 1.5.0_09
- WSIT M5

Did you performed such interoperability test between WSIT M5 and Microsoft WCF ?

Do you have any hint for me ?

Thanks.

Message was edited by: rebelanger

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
rebelanger
Offline
Joined: 2006-08-24
Points: 0

> Finally I got sometime to install CardSpace and debug
> the issue. Here are some tips:
>
> 1. Enable SOAP 1.2 binding for STS MEX endpoint so
> that you have
>
> > name="sts_mex"
> implementation="com.sun.xml.ws.mex.server.MEXEndpoint"
>
>
> inding="http://www.w3.org/2003/05/soap/bindings/HTTP/"
>
> url-pattern="/sts/mex" />
> sun-jaxws.xml file for the STS.
>
> 2. There is a issue for our MEX endpoint for adding
> addressing Action header to the MEX response message.
> I will check in a fix/workaround for this.
>
> 3. A fix for the signature issue will be also check
> in tomorrow.
>
> Then WSIT based STS should work with Cardspace.
>
> Hopefully this is not too late for you.
>
> Regards,

No it's not too late: yesterday we have officially kicked off the development tasks for this interoperability event using our current implementation that uses the old WSIT package (M2) as a baseline. But we still want to upgrade to the latest WSIT release very soon.

So please let me know as soon the fixes will be available.

Thanks a lot !

jdg6688
Offline
Joined: 2005-11-02
Points: 0

I checked in the fixes. Please try out.

Good Luck!

rebelanger
Offline
Joined: 2006-08-24
Points: 0

> I checked in the fixes. Please try out.
>
> Good Luck!

All right. Thanks.

I'm going to test it today and give you feedback soon.

rebelanger
Offline
Joined: 2006-08-24
Points: 0

Hi !

Great news ! I have made a test with the latest WSIT code base which includes your fixes and I don't get the MEX communication error anymore !

Also, the Metadata Exchange Endpoint Url I had to specify in my managed info card is the STS endpoint URL itself (e.g. http://..../sts) and not the MEXEndpoint one (e.g. http://..../sts/mex).

Now I get the signature error that I had originally (rf. first posts on this thread). I guess this is related to a malformed RequestedDisplayToken element contained in the RSTR. I also guess the namespace attribute specified for that element is incorrect and that could explain the XMLStreamException I get in the Tomcat log.

I have made the test with and without the DisableStreamingSecurity element in the STS WSDL and get the same result except for the Event Viewer message which is different :

- w/o DisableStreamingSecurity :

Inner Exception: Digest verification failed for Reference '#_5007'.

- w/ DisableStreamingSecurity :

Inner Exception: Digest verification failed for Reference '#XWSSGID-1192629289859-1038532327'.

Any hint ? Do you think my guessing is correct ?

Many thanks.

rebelanger
Offline
Joined: 2006-08-24
Points: 0

> Hi !
>
> Great news ! I have made a test with the latest WSIT
> code base which includes your fixes and I don't get
> the MEX communication error anymore !
>
> Also, the Metadata Exchange Endpoint Url I had to
> specify in my managed info card is the STS endpoint
> URL itself (e.g. http://..../sts) and not the
> MEXEndpoint one (e.g. http://..../sts/mex).
>
> Now I get the signature error that I had originally
> (rf. first posts on this thread). I guess this is
> related to a malformed RequestedDisplayToken element
> contained in the RSTR. I also guess the namespace
> attribute specified for that element is incorrect and
> that could explain the XMLStreamException I get in
> the Tomcat log.
>
> I have made the test with and without the
> DisableStreamingSecurity element in the STS WSDL and
> get the same result except for the Event Viewer
> message which is different :
>
> - w/o DisableStreamingSecurity :
>
> Inner Exception: Digest verification failed for
> Reference '#_5007'.
>
> - w/ DisableStreamingSecurity :
>
> Inner Exception: Digest verification failed for
> Reference '#XWSSGID-1192629289859-1038532327'.
>
>
> Any hint ? Do you think my guessing is correct ?
>
> Many thanks.

Hi !

Because we didn't have enough time to complete the migration of our product to the latest WSIT codebase we have decided to go to the CardSpace interoperability event with the old WSIT version (around M2 release) which worked well.

Thank you very much for your support. We will continue our migration effort because it is still a major target for our current development iteration.

Thanks again, support from your team is really great !

I'm going to put this thread as "aswered".

BTW This event is currently being held in Barcelona : http://catalyst.burtongroup.com/EU07/

Message was edited by: rebelanger

jdg6688
Offline
Joined: 2005-11-02
Points: 0

Finally I got sometime to install CardSpace and debug the issue. Here are some tips:

1. Enable SOAP 1.2 binding for STS MEX endpoint so that you have

name="sts_mex"
implementation="com.sun.xml.ws.mex.server.MEXEndpoint"
binding="http://www.w3.org/2003/05/soap/bindings/HTTP/"
url-pattern="/sts/mex" />

in the sun-jaxws.xml file for the STS.

2. There is a issue for our MEX endpoint for adding addressing Action header to the MEX response message. I will check in a fix/workaround for this.

3. A fix for the signature issue will be also check in tomorrow.

Then WSIT based STS should work with Cardspace.

Hopefully this is not too late for you.

Regards,

jdg6688
Offline
Joined: 2005-11-02
Points: 0

>
> 1. Enable SOAP 1.2 binding for STS MEX endpoint so
> that you have
>
> > name="sts_mex"
> implementation="com.sun.xml.ws.mex.server.MEXEndpoint"
>
>
> inding="http://www.w3.org/2003/05/soap/bindings/HTTP/"
>
> url-pattern="/sts/mex" />
> sun-jaxws.xml file for the STS.

I see you got this before.
>
> 2. There is a issue for our MEX endpoint for adding
> addressing Action header to the MEX response message.
> I will check in a fix/workaround for this.

This is the reason that CardSpace can't process the MEX response and the fail message you get.

Thanks!

>
> 3. A fix for the signature issue will be also check
> in tomorrow.
>
> Then WSIT based STS should work with Cardspace.
>
> Hopefully this is not too late for you.
>
> Regards,

jdg6688
Offline
Joined: 2005-11-02
Points: 0

Hi rebelanger ,

In your sts.wsdl, you set up use message level security in stead of https binding.
But your endpoint use https. This causes you trouble.

With your sts.wsdl, you should use
http://my-server.acme.com:????/wstrust-sts/sts/ as endpoint and
http://my-server.acme.com:????/wstrust-sts/sts/mex
as MEX address.

rebelanger
Offline
Joined: 2006-08-24
Points: 0

> Hi rebelanger ,
>
> In your sts.wsdl, you set up use message level
> security in stead of https binding.
> But your endpoint use https. This causes you
> trouble.
>
> With your sts.wsdl, you should use
> http://my-server.acme.com:????/wstrust-sts/sts/ as
> endpoint and
> http://my-server.acme.com:????/wstrust-sts/sts/mex
> as MEX address.

Can you point me out where exactly in the WSDL I should made some changes then ?

I have reviewed it and cannot find what is the misconfiguration exactly.

Thanks for your support !

jdg6688
Offline
Joined: 2005-11-02
Points: 0

In the service part of your sts.wsdl,





https://my-server.acme.com:9443/wstrust-sts/sts



MIIDhzC.......





Can you change the address to http://my-server.acme.com:
/wstrust-sts/sts?

And then use http://my-server.acme.com:
/wstrust-sts/sts
and http://my-server.acme.com:
/wstrust-sts/sts/mex as STS endpoint and STS MEX address with CarSelector to see if it works. Although I am not sure this was the problem.

rebelanger
Offline
Joined: 2006-08-24
Points: 0

> In the service part of your sts.wsdl,
>
>
> > binding="tns:ISecurityTokenService_Binding"
> name="ISecurityTokenService_Port">
> > location="https://my-server.acme.com:9443/wstrust-sts/
> sts"/>
>
> https://my-server.acme.com:9443/wstrust
> -sts/sts

> > xmlns="http://schemas.xmlsoap.org/ws/2006/02/addressin
> gidentity">
>
>
> MIIDhzC.......
>

>

>
>

>
>

>
> Can you change the address to
> http://my-server.acme.com:
> for-http>/wstrust-sts/sts?
>
> And then use http://my-server.acme.com:
> for-http>/wstrust-sts/sts
> and http://my-server.acme.com:
> for-http>/wstrust-sts/sts/mex as STS endpoint and STS
> MEX address with CarSelector to see if it works.
> Although I am not sure this was the problem.

Oh yes ! I see ! I didn't notice that you asked me for only changing from https to http !

But I have the feeling that CardSpace requires an https connection to both endpoints.

I'll try this anyway and will let you know. Thanks.

jdg6688
Offline
Joined: 2005-11-02
Points: 0

>
> But I have the feeling that CardSpace requires an
> https connection to both endpoints.

In this case, everything is secured in the message level with what specified in sts.wsdl, no reason to require https. I checked the CardSpace interop-profile-guide document, no requirement of https comes up there. The example is in http form.
>
> I'll try this anyway and will let you know. Thanks.
Please let us now. Otherwise, I don't see anything wrong on other side.

I remebered you encounter the exactly same issue a year ago when you start using WSIT with CardSpace. How did you get that resolved?

Regards

rebelanger
Offline
Joined: 2006-08-24
Points: 0

> >
> > But I have the feeling that CardSpace requires an
> > https connection to both endpoints.
>
> In this case, everything is secured in the message
> level with what specified in sts.wsdl, no reason to
> require https. I checked the CardSpace
> interop-profile-guide document, no requirement of
> https comes up there. The example is in http form.
> >
> > I'll try this anyway and will let you know.
> Thanks.
> Please let us now. Otherwise, I don't see anything
> wrong on other side.

Sorry for the late answer, I was on vacation in last days...

I have made a test using non-SSL connection to the STS but unfortunately the CardSpace Identity Selector complains about it when I try to import my new info card containing http url to the STS and MEX endpoints :

-----------------
The data present in a card could not be validated. The card is not valid. Verify that there is valid metadata in the EndPointReference element and that the URI scheme is HTTPS.
-----------------

This message was sent into the Event Viewer log from a CardSpace 3.0.0.0 source.

So it seems that we absolutely need an https connection to the STS.

>
> I remebered you encounter the exactly same issue a
> year ago when you start using WSIT with CardSpace.
> How did you get that resolved?

We always used https connections to the STS to make the things work with CardSpace Identity Selector.

>
> Regards

Do you have any idea why it's impossible for the CardSpace Identity Selector to connect thru https to the WS-Trust STS using the latest WSIT release ?

Is there any newer version of WFC which doesn't requires absolutely an https connection to the STS ?

Thanks again. I'm sure we're going to resolve this issue.

Message was edited by: rebelanger

jdg6688
Offline
Joined: 2005-11-02
Points: 0

> I have made a test using non-SSL connection to the
> STS but unfortunately the CardSpace Identity Selector
> complains about it when I try to import my new info
> card containing http url to the STS and MEX endpoints
> :
>
> -----------------
> The data present in a card could not be validated.
> The card is not valid. Verify that there is valid
> metadata in the EndPointReference element and that
> the URI scheme is HTTPS.
> ----------------
>
> This message was sent into the Event Viewer log from
> a CardSpace 3.0.0.0 source.
>
> So it seems that we absolutely need an https
> connection to the STS.

Ok. My understanding is that they need to secure the MEX messages using https and to secure the RST/RSTR using whatever specified in the STS WSDL.

>
> >
> > I remebered you encounter the exactly same issue a
> > year ago when you start using WSIT with CardSpace.
> > How did you get that resolved?
>
> We always used https connections to the STS to make
> the things work with CardSpace Identity Selector.
>
> >
> > Regards
>
> Do you have any idea why it's impossible for the
> CardSpace Identity Selector to connect thru https to
> the WS-Trust STS using the latest WSIT release ?
>
> Is there any newer version of WFC which doesn't
> requires absolutely an https connection to the STS ?
>
> Thanks again. I'm sure we're going to resolve this
> issue.

I will do some investigation and will let you know.

Thanks!

>
> Message was edited by: rebelanger

rebelanger
Offline
Joined: 2006-08-24
Points: 0

> Ok. My understanding is that they need to secure the
> MEX messages using https and to secure the RST/RSTR
> using whatever specified in the STS WSDL.
>
...
>
> I will do some investigation and will let you know.
>
> Thanks!
>

Hi,

Did you have time to take a look at this issue recently ?

We will participate in a CardSpace interoperability showcase in a few weeks and I would have liked to use the latest WSIT release instead of the old M2 release.

Thanks again !

jdg6688
Offline
Joined: 2005-11-02
Points: 0

I am looking into this. I will get back to you by next Monday if not earlier.

Thanks!

hofsass
Offline
Joined: 2003-06-25
Points: 0

Hi, I'm the MEX guy for WSIT. I can't tell whether the STS MEX endpoint is sending an error response, a successful response with bogus infomration, or if there is a problem with the primary STS endpoints themselves. If you could capture the MEX response from your STS implementation, it would be very helpful.

Probably the easiest way to do that would be to set JAVA_OPTS environment variable for the Tomcat instance that runs your STS.

set (or export) JAVA_OPTS=-Dcom.sun.xml.ws.transport.http.HttpAdapter.dump=true

This will dump the SOAP messages inbound and outbound that JAX-WS sees. If you could post the STS MEX response that would be great.

thanks,
Ken

rebelanger
Offline
Joined: 2006-08-24
Points: 0

> Hi, I'm the MEX guy for WSIT. I can't tell whether
> the STS MEX endpoint is sending an error response, a
> successful response with bogus infomration, or if
> there is a problem with the primary STS endpoints
> themselves. If you could capture the MEX response
> from your STS implementation, it would be very
> helpful.
>
> Probably the easiest way to do that would be to set
> JAVA_OPTS environment variable for the Tomcat
> instance that runs your STS.
>
> set (or export)
> JAVA_OPTS=-Dcom.sun.xml.ws.transport.http.HttpAdapter.
> dump=true
>
> This will dump the SOAP messages inbound and outbound
> that JAX-WS sees. If you could post the STS MEX
> response that would be great.
>
> thanks,
> Ken

You will find attached to this post the Tomcat stdout log.

The WS-MEX exchange seems successful. My problem seems to occur when the CardSpace Identity Selector is trying to reach the STS endpoint afterward.

Do you have any idea about what is going on ?

Thanks.

rebelanger
Offline
Joined: 2006-08-24
Points: 0

> > Here is my current status :
> >
> > - Our STS produces a response with a
> > RequestSecurityTokenResponse element which contains
> a
> > RequestedDisplayToken sub-element that is a WS
> > Identity primitive;
> >
> > - Since this is not a standard WS-Trust element I
> > have specified a namespace for this
> > RequestedDisplayToken;
> >
> > - Here is an example of such element :
> >
> > > >
> xmlns:wsid="http://schemas.xmlsoap.org/ws/2005/05/iden
>
> > tity">
> >
> > > >
> Uri="http://schemas.xmlsoap.org/ws/2005/05/identity/c
> > aims/emailaddress">
> > Email
> > address

> >
> >
> wsid:DisplayValue>john.doe@acme.com >
> > >
> >

> > sid:DisplayToken>
> >
> >
> > - With this response the CardSpace Identity
> Selector
> > failed to verify the signature of the SOAP body;
> >
> > - When I remove any namespace specification from
> the
> > RequestedDisplayToken element and its
> sub-elements,
> > the signature verification succeeds.
> >
> > - However, when I click on the Retrieve button of
> the
> > Identity Selector to get the content of the
> > DisplayToken no value is displayed => here I think
> > this is because the Identity Selector is unable to
> > find a RequestedDisplayToken defined in a WS
> Identity
> > namespace (since no namespace is defined for the
> > RequestedDisplayToken contained in the RSTR).
> >
> > - The problem here is if I specify a namespace the
> > signature verification fails, if I don't specify a
> > namespace the signature verification succeeds but
> I'm
> > unable to retrieve the content of the
> DisplayToken.
> >
> > - With WSIT Milestone 2 I didn't get that kind of
> > problem but with the latest WSIT build I do.
> >
> > - Do you have some hints concerning this issue ?
>
> We updated the XML security handling since M2 using
> streaming xml processing (optimized path as we
> call).
> The policy assertion is used to disable this to use
> the "old way" to do the XML security.
>
> You should probably first try with the suggested
> policy assertion to make sure it is working so that
> we will know that it could be a potential issue for
> the optimized path.
>
> Thanks!
>
> Jiandong

Hi,

I'm back to trying to fix this issue now.

I've tried it again but with DisableStreamingSecurity policy assertion in the WSDL of our STS but still get an invalid signature verification.

I've noticed that once the RSTR is marshalled into an XML document, the contains an empty xmlns attribute, e.g.

I suspect that maybe the signature generation made by the WSIT vs. signature verification performed by the CardSpace Identity Selector doesn't deal the same way with this empty namespace attribute.

Right now, I'm trying to get rid of this empty attribute on the STS side that avoid it during signature generartion.

Do you have any hints for me concerning this issue ?

By the way, we are now using the binary version of WSIT from 2008-01-17.

Many thanks.

Message was edited by: rebelanger

Message was edited by: rebelanger

Message was edited by: rebelanger

jdg6688
Offline
Joined: 2005-11-02
Points: 0

Hi,

The empty xmlns is fine.

The relevant issue is filed here:

https://wsit.dev.java.net/issues/show_bug.cgi?id=738

We will try to get it fixed as soon as possible.

Thanks!

jdg6688
Offline
Joined: 2005-11-02
Points: 0

In the mean time,
if you create your display token related elements use JAXB in stead of DOM,
you may get through the issue.

Regards,

rebelanger
Offline
Joined: 2006-08-24
Points: 0

> Hi,
>
> The empty xmlns is fine.
>
> The relevant issue is filed here:
>
> https://wsit.dev.java.net/issues/show_bug.cgi?id=738
>
> We will try to get it fixed as soon as possible.
>
> Thanks!
>
> In the mean time,
> if you create your display token related elements use
> JAXB in stead of DOM,
> you may get through the issue.
>
> Regards,

All right. Thanks for the hint !

I'll try it and let you know.

rebelanger
Offline
Joined: 2006-08-24
Points: 0

For now we don't specify any xml:lang attribute in the DisplayToken element and this resolves the signature verification issue we had.

So, we don't have any blocking issues anymore concerning the interoperability of our STS implemented using the WSIT version from 2008-01-17 with the CardSpace technology.

Thanks a lot for your great support !

jdg6688
Offline
Joined: 2005-11-02
Points: 0

Just curious,
is this xml:lang a required attribute for the DisplayToken in the Infor Card spec.

Does the CardSpace accept the RSTR without it?

Thanks!

rebelanger
Offline
Joined: 2006-08-24
Points: 0

> Just curious,
> is this xml:lang a required attribute for the
> DisplayToken in the Infor Card spec.
>
> Does the CardSpace accept the RSTR without it?
>
> Thanks!

As per the InfoCard_rc1.xsd schema it seems this attribute is not required in the DisplayToken element.

According to our tests, the CardSpace Identity Selector accept such DisplayToken because it displayed the user attributes when using the "Retrieve" button.

Regards.

jdg6688
Offline
Joined: 2005-11-02
Points: 0

> > Just curious,
> > is this xml:lang a required attribute for the
> > DisplayToken in the Infor Card spec.
> >
> > Does the CardSpace accept the RSTR without it?
> >
> > Thanks!
>
> As per the InfoCard_rc1.xsd schema it seems this
> attribute is not required in the DisplayToken
> element.
>
> According to our tests, the CardSpace Identity
> Selector accept such DisplayToken because it
> displayed the user attributes when using the
> "Retrieve" button.
>
Good to know. The spec says this attribute is required.
We now have the support for OASIS WS-SX standard versions of WS-Trust in WSIT as EA features.
It should be interesting to try out with Cardspace on top of .Net 3.5:

http://blogs.sun.com/trustjdg/entry/oasis_ws_sx_support_in

Thanks!

jdg6688
Offline
Joined: 2005-11-02
Points: 0

> Thanks for your feedback.
>
> I didn't try your suggested policy assertion yet
> because I have made some progression here (but I keep
> it in mind and I shall use it if others things go
> wrong).
>
> Here is my current status :
>
> - Our STS produces a response with a
> RequestSecurityTokenResponse element which contains a
> RequestedDisplayToken sub-element that is a WS
> Identity primitive;
>
> - Since this is not a standard WS-Trust element I
> have specified a namespace for this
> RequestedDisplayToken;
>
> - Here is an example of such element :
>
> > xmlns:wsid="http://schemas.xmlsoap.org/ws/2005/05/iden
> tity">
>
> > Uri="http://schemas.xmlsoap.org/ws/2005/05/identity/c
> aims/emailaddress">
> Email
> address

>
> wsid:DisplayValue>john.doe@acme.com > >
>
> sid:DisplayToken>
>
>
> - With this response the CardSpace Identity Selector
> failed to verify the signature of the SOAP body;
>
> - When I remove any namespace specification from the
> RequestedDisplayToken element and its sub-elements,
> the signature verification succeeds.
>
> - However, when I click on the Retrieve button of the
> Identity Selector to get the content of the
> DisplayToken no value is displayed => here I think
> this is because the Identity Selector is unable to
> find a RequestedDisplayToken defined in a WS Identity
> namespace (since no namespace is defined for the
> RequestedDisplayToken contained in the RSTR).
>
> - The problem here is if I specify a namespace the
> signature verification fails, if I don't specify a
> namespace the signature verification succeeds but I'm
> unable to retrieve the content of the DisplayToken.
>
> - With WSIT Milestone 2 I didn't get that kind of
> problem but with the latest WSIT build I do.
>
> - Do you have some hints concerning this issue ?

We updated the XML security handling since M2 using streaming xml processing (optimized path as we call).
The policy assertion is used to disable this to use the "old way" to do the XML security.

You should probably first try with the suggested policy assertion to make sure it is working so that we will know that it could be a potential issue for the optimized path.

Thanks!

Jiandong

kumarjayanti
Offline
Joined: 2003-12-10
Points: 0

Hi,

As jiandong said, it could be a possible bug in our streaming security implementation. However can you elaborate the process of Removing Namespaces (which causes the signature verification to pass). How do you remove the namespaces from an incoming message ?.

Can you send us the Signature Block (or better still the entire Message) so we can take a look at it. Which Canonicalization algo is being used by the Signature etc.

Thanks.

rebelanger
Offline
Joined: 2006-08-24
Points: 0

Hi,

I'm sorry. My latest tests were wrong. Using Milestone 6 release did not resolve the issue I have.

Don't really know the version of WFC (I think its 2.0) but windows\system32\inforcardcpl.cpl has version 3.0.4506.30 (hope this helps).

In summary my problem is :

- the STS issue a valid security token supported by CardSpace;
- however the CardSpace Identity Selector fails to verify the XML signature of the token.

Do you have some other hints for me ?

Thanks a lot.

Message was edited by: rebelanger

jdg6688
Offline
Joined: 2005-11-02
Points: 0

Not sure what is going on? Can you snd detailed fault information on the client side?

Can you also try with the following policy assertion in STS WSDL to see it works:

You can put it above the assertion.

rebelanger
Offline
Joined: 2006-08-24
Points: 0

Thanks for your feedback.

I didn't try your suggested policy assertion yet because I have made some progression here (but I keep it in mind and I shall use it if others things go wrong).

Here is my current status :

- Our STS produces a response with a RequestSecurityTokenResponse element which contains a RequestedDisplayToken sub-element that is a WS Identity primitive;

- Since this is not a standard WS-Trust element I have specified a namespace for this RequestedDisplayToken;

- Here is an example of such element :




Email address
john.doe@acme.com


- With this response the CardSpace Identity Selector failed to verify the signature of the SOAP body;

- When I remove any namespace specification from the RequestedDisplayToken element and its sub-elements, the signature verification succeeds.

- However, when I click on the Retrieve button of the Identity Selector to get the content of the DisplayToken no value is displayed => here I think this is because the Identity Selector is unable to find a RequestedDisplayToken defined in a WS Identity namespace (since no namespace is defined for the RequestedDisplayToken contained in the RSTR).

- The problem here is if I specify a namespace the signature verification fails, if I don't specify a namespace the signature verification succeeds but I'm unable to retrieve the content of the DisplayToken.

- With WSIT Milestone 2 I didn't get that kind of problem but with the latest WSIT build I do.

- Do you have some hints concerning this issue ?

Furthermore there is another issue that I have successfully worked around but I would like to solve it in a cleaner way.

- For my test I have issued an information card with a STS endpoint URL and a WS-MEX endpoint URL which are the same.

- When I select this info card in the Identity Selector and submit the username/password , an initial WS-MEX request is sent to the MEX endpoint URL but the Identity Selector is complaining about an "no suitable endpoint found" (looking at the Event Viewer log);

- I noticed (looking at the WSIT debugging log) that our STS (a home made STS as a JAXWS web service, almost like the original WSIT STS) is trying to process this request;

- When I issue another info card but appending "?wsdl" to the MEX endpoint URL the Identity Selector don't complain anymore but the STS is still trying to process the MEX request;

- With WSIT Milestone 2 this was not happening but with the latest WSIT build it is.

- Do you know what's going on ? Should not be the WSIT engine which process this MEX request transparently ?

Thank you very much for your help.

jdg6688
Offline
Joined: 2005-11-02
Points: 0

Look like you build a managed identity provider for CardSpace with WSIT. Interesting work. Would like to hear more about it.

I will answer your second question first and will get back to your first question later.

> Furthermore there is another issue that I have
> successfully worked around but I would like to solve
> it in a cleaner way.
>
> - For my test I have issued an information card with
> a STS endpoint URL and a WS-MEX endpoint URL which
> are the same.
>
> - When I select this info card in the Identity
> Selector and submit the username/password , an
> initial WS-MEX request is sent to the MEX endpoint
> URL but the Identity Selector is complaining about an
> "no suitable endpoint found" (looking at the Event
> Viewer log);
>
> - I noticed (looking at the WSIT debugging log) that
> our STS (a home made STS as a JAXWS web service,
> almost like the original WSIT STS) is trying to
> process this request;
>
> - When I issue another info card but appending
> "?wsdl" to the MEX endpoint URL the Identity Selector
> don't complain anymore but the STS is still trying to
> process the MEX request;
>
> - With WSIT Milestone 2 this was not happening but
> with the latest WSIT build it is.
>
> - Do you know what's going on ? Should not be the
> WSIT engine which process this MEX request
> transparently ?

After M2, we implemented the MEX as a seperate endpoint. You need to enable it
explicitly.

Here is your web.xml for STS should look like:


sts
sts

com.sun.xml.ws.transport.http.servlet.WSServletContextListener
sts
sts
JAX-WS endpoint - sts
com.sun.xml.ws.transport.http.servlet.WSServlet
1


sts
/sts


sts
/sts/mex


60

Here is the sun-jaxws.xml should look like:

xmlns="http://java.sun.com/xml/ns/jax-ws/ri/runtime"
version="2.0">

name="sts"
interface="simple.sts.ISecurityTokenService"
implementation="simple.sts.STSImpl"
wsdl="WEB-INF/wsdl/sts.wsdl"
service="{http://tempuri.org/}SecurityTokenService"
port="{http://tempuri.org/}ISecurityTokenService_Port"
binding="http://www.w3.org/2003/05/soap/bindings/HTTP/"
url-pattern="/sts" />

name="sts_mex"
implementation="com.sun.xml.ws.mex.server.MEXEndpoint"
url-pattern="/sts/mex" />

Thanks!

rebelanger
Offline
Joined: 2006-08-24
Points: 0

Thanks for your quick reply !

I have configured the MEX endpoint as you have suggested, issue a new info card with the appropriate MEX endpoint URL and perform the test again.

After submitting the username/password the CardSpace Identity failed in sending the MEX request. Here is the error send by the Identity Selector into the Event Viewer log :

---------------------------
There was a failure making a WS-Trust exchange with an external application. No suitable endpoints were found for the service at address https://my-server.acme.com:9443/wstrust-sts/sts.

Additional Information:
at System.Environment.GetStackTrace(Exception e, Boolean needFileInfo)
at System.Environment.get_StackTrace()
at Microsoft.InfoCards.Diagnostics.InfoCardTrace.BuildMessage(InfoCardBaseException ie)
at Microsoft.InfoCards.Diagnostics.InfoCardTrace.TraceAndLogException(Exception e)
at Microsoft.InfoCards.Diagnostics.InfoCardTrace.ThrowHelperError(Exception e)
at Microsoft.InfoCards.RemoteTokenFactory.DoMexExchange(TokenCreationParameter param, IWebProxy proxy)
at Microsoft.InfoCards.RemoteTokenFactory.ProduceToken(InfoCard card, TokenCreationParameter parameter, TokenFactoryCredential credential, InfoCardPolicy policy, Boolean discloseOptional)
at Microsoft.InfoCards.TokenFactoryBase.CreateToken(InfoCard infoCard, TokenFactoryCredential credential, InfoCardPolicy policy, Boolean discloseOptional)
at Microsoft.InfoCards.GetTokenRequest.CreateSecurityToken(TokenFactoryCredential credential, Boolean discloseOptional)
at Microsoft.InfoCards.BeginCreateSecurityTokenRequest.AsyncExecute(AsyncParams asyncParam)
at Microsoft.InfoCards.UIAgentAsyncBeginRequest.AsyncEntry(Object state)
at System.ServiceModel.Diagnostics.Utility.WaitThunk.UnhandledExceptionFrame(Object state)
at System.Threading._ThreadPoolWaitCallback.WaitCallback_Context(Object state)
at System.Threading.ExecutionContext.runTryCode(Object userData)
at System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode code, CleanupCode backoutCode, Object userData)
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback(Object state)
------------------------

I assume that this is when the MEX request is sent because I don't see any WSIT debugging message dumped into the Tomcat stdout log but instead an exception returned by the WSServlet :

-----------------------
07.09.2007 15:55:14 com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit handle
FATAL: Unsupported Content-Type: application/soap+xml; charset=utf-8 Supported ones are: [text/xml]
com.sun.xml.ws.server.UnsupportedMediaException: Unsupported Content-Type: application/soap+xml; charset=utf-8 Supported ones are: [text/xml]
at com.sun.xml.ws.encoding.StreamSOAPCodec.decode(StreamSOAPCodec.java:291)
at com.sun.xml.ws.encoding.StreamSOAPCodec.decode(StreamSOAPCodec.java:128)
at com.sun.xml.ws.encoding.SOAPBindingCodec.decode(SOAPBindingCodec.java:294)
at com.sun.xml.ws.transport.http.HttpAdapter.decodePacket(HttpAdapter.java:276)
at com.sun.xml.ws.transport.http.HttpAdapter.access$500(HttpAdapter.java:93)
at com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:432)
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:595)
-----------------------

Is this because the MEXEndpoint is only able to process incoming MEX requests of content type "text/xml" ? However it seems that the Windows CardSpace Identity Selector is sending only requests of content-type "application/soap+xml".

Could it be the cause of this problem ?

Thanks.

Message was edited by: rebelanger

Message was edited by: rebelanger

rebelanger
Offline
Joined: 2006-08-24
Points: 0

> -----------------------
> 07.09.2007 15:55:14
> com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit
> handle
> FATAL: Unsupported Content-Type:
> application/soap+xml; charset=utf-8 Supported ones
> are: [text/xml]
> com.sun.xml.ws.server.UnsupportedMediaException:
> Unsupported Content-Type: application/soap+xml;
> charset=utf-8 Supported ones are: [text/xml]

I have resolved this problem by setting the transport binding of the MEXEndpoint to

binding="http://www.w3.org/2003/05/soap/bindings/HTTP/"

in sun-jaxws.xml file.

Now this problem is gone and the MEX handshake is performed. However I got another error from the CardSpace Identity Selector, here is the extract from the Event Viewer log :

-------------------------
There was a failure making a WS-Trust exchange with an external application. No suitable endpoints were found for the service at address https://my-server.acme.com:9443/wstrust-sts/sts.
-------------------------

When I look into the Tomcat stdout log I only see MEX request and response processed by WSIT, no RST has been received, as if my STS endpoint was unreachable.

Do you have any idea ?

Thanks.

jdg6688
Offline
Joined: 2005-11-02
Points: 0

You hit an issue here. The WSDL obtained through the MEX call with http mex endpoint
has the endpoint of the STS in the http form. That is why you got an error with no sutiable
endponts found. I will get back to you about this.

No such issue if message security instead of https is used.

rebelanger
Offline
Joined: 2006-08-24
Points: 0

> You hit an issue here. The WSDL obtained through the
> MEX call with http mex endpoint
> has the endpoint of the STS in the http form. That is
> why you got an error with no sutiable
> endponts found. I will get back to you about this.
>
> No such issue if message security instead of https is
> used.

All right thanks, I'll be waiting for your feedback then.

Meanwhile, can you give more details about your statement above ? Thanks.

rebelanger
Offline
Joined: 2006-08-24
Points: 0

> We updated the XML security handling since M2 using streaming xml processing (optimized path as we call).
> The policy assertion is used to disable this to use the "old way" to do the XML security.
>
> You should probably first try with the suggested policy assertion to make sure it is working so that we will know that it could be a potential issue for the optimized path.
>
> Thanks!
>
> Jiandong
>
>
>
> Hi,
>
> As jiandong said, it could be a possible bug in our streaming security implementation. However can you elaborate the process of Removing Namespaces (which causes the signature verification to pass). How do you remove the namespaces from an incoming message ?.
>
> Can you send us the Signature Block (or better still the entire Message) so we can take a look at it. Which Canonicalization algo is being used by the Signature etc.
>
> Thanks.
>

As soon as I will resolve my current issue with the last "no suitable endpoint" error I got, I will test the signature verification again with disabled "optimized path" (as you suggested) and give you a reply to your posts quoted above.

Please take a look at my previous post and if you have any idea about my current issue please let me know.

Thanks for your help, it's really appreciated !

jdg6688
Offline
Joined: 2005-11-02
Points: 0

Can you try with the https for the MEX address
https://my-server.acme.com:9443/wstrust-sts/sts/mex?

You can get the WSDL for the STS with https endpoint there.

Not sure if WCF/CardSpace support MEX call with https.

Please let us know if it works.

Thanks!

rebelanger
Offline
Joined: 2006-08-24
Points: 0

> Can you try with the https for the MEX address
> https://my-server.acme.com:9443/wstrust-sts/sts/mex?
>
> You can get the WSDL for the STS with https endpoint there.
>
> Not sure if WCF/CardSpace support MEX call with https.
>
> Please let us know if it works.
>
> Thanks!

When pointing my web browser to "https://my-server.acme.com:9443/wstrust-sts/sts/mex" I got the following displayed in a web page :

--------------------------------
Web Services
Endpoint Information

Service Name: {http://tempuri.org/}SecurityTokenService
Port Name: {http://tempuri.org/}ISecurityTokenService_Port
Address: https://my-server.acme.com:9443/wstrust-sts/sts/mex
WSDL: https://my-server.acme.com:9443/wstrust-sts/sts/mex?wsdl
Implementation class: MyWebService

Service Name:
Port Name:
Address: https://my-server.acme.com:9443/wstrust-sts/sts/mex
WSDL: https://my-server.acme.com:9443/wstrust-sts/sts/mex?wsdl
Implementation class: com.sun.xml.ws.mex.server.MEXEndpoint
--------------------------------

Here is the content of sun-jaxws.xml :

--------------------------------
xmlns="http://java.sun.com/xml/ns/jax-ws/ri/runtime"
version="2.0">

name="sts"
interface="MyStsWebService"
implementation="MyStsWebService"
wsdl="WEB-INF/wsdl/sts.wsdl"
service="{http://tempuri.org/}SecurityTokenService"
port="{http://tempuri.org/}ISecurityTokenService_Port"
binding="http://www.w3.org/2003/05/soap/bindings/HTTP/"
url-pattern="/sts" />

name="sts_mex"
implementation="com.sun.xml.ws.mex.server.MEXEndpoint"
binding="http://www.w3.org/2003/05/soap/bindings/HTTP/"
url-pattern="/sts/mex" />

--------------------------------

Here is the content of sts.wsdl :

--------------------------------






























































































































































https://my-server.acme.com:9443/wstrust-sts/sts



MIIDhzC.......







--------------------------------

The info card I used have "https://my-server.acme.com:9443/wstrust-sts/sts" as the EndpointReference and "https://my-server.acme.com:9443/wstrust-sts/sts/mex" as MetadataReference.

The CardSpace Identity Selector send the following error message in the EventViewer log :

--------------------------------
There was a failure making a WS-Trust exchange with an external application. No suitable endpoints were found for the service at address https://my-server.acme.com:9443/wstrust-sts/sts.
--------------------------------

Into the Tomcat stdout log file I notice that the WS-MEX request is processed by WSIT ! The request is received and the WSDL is return as a response.

So finally it doesn't seems to be a problem about the Card Space Identity Selector contacting the MEXExpoint but rather a problem contacting the STS endpoint itself.

Hope this is helpful for you in helping me to resolve that problem.

Otherwise we would need to fallback to the old Milestone 2 release which worked fine. However I would have loved to upgrade to the latest WSIT release before we participate in a CardSpace interoperability show case in a few weeks.

Thanks.

Message was edited by: rebelanger

Message was edited by: rebelanger

jdg6688
Offline
Joined: 2005-11-02
Points: 0

The MEX request and response come up correctly.

However we see:

>There was a failure making a WS-Trust exchange with an external application. No >suitable endpoints were found for the service at address >https://my-server.acme.example:9443/dirxaccess-fep-wstrust-sts/sts.

This enpoint the client try to access, which has extra dirxaccess-fep, is different from one for the STS. This shoule be a problem on the Identity selector side.

Did you also use https://... as MEX address with M2 before?

rebelanger
Offline
Joined: 2006-08-24
Points: 0

> The MEX request and response come up correctly.
>
> However we see:
>
> >There was a failure making a WS-Trust exchange with
> an external application. No >suitable endpoints were
> found for the service at address
> >https://my-server.acme.example:9443/dirxaccess-fep-ws
> trust-sts/sts.
>
> This enpoint the client try to access, which has
> extra dirxaccess-fep, is different from one for the
> STS. This shoule be a problem on the Identity
> selector side.
>

Oops.. this was an old message from the EventViewer because this was the old naming of my STS endpoint. Here is the latest EventViewer entry I got instead :

------------------------
There was a failure making a WS-Trust exchange with an external application.
No suitable endpoints were found for the service at address
https://my-server.acme.com:9443/wstrust-sts/sts.
------------------------

Sorry for the confusion.

> Did you also use https://... as MEX address with M2
> before?

Yes it worked fine over https with WSIT M2, in reality it was a version of WSIT between M1 and M2 taken from the java.net CVS repository on 2006-09-18 (almost a year ago).

But here the issue doesn't seem to be related to the exchange with the MEXEndpoint (as it is successful) but rather when the Identity Selector try to reach the STS endpoint.

jdg6688
Offline
Joined: 2005-11-02
Points: 0

> Hi,
>
> I'm currently working on a WS-Trust STS project using
> WSIT to produce security tokens for the CardSpace
> technology.

>
> This works fine with the Milestone 2 version but
> after having upgraded to Milestone 5 it seems that
> the signature of the SOAP body generated by WSIT
> cannot be verified by the CardSpace Identity
> Selector. Here is the error message it has dumped
> into the Event Viewer log:
>
> [i]There was a failure making a WS-Trust exchange
> with an external application. Could not retrieve
> token from id
> Did you performed such interoperability test between
> WSIT M5 and Microsoft WCF ?
Yes, we do.

See the release notes for M5
https://wsit.dev.java.net/source/browse/*checkout*/wsit/wsit/status-note...

Also see the blog of Harold Carr about the latest MS plugfest results:

http://weblogs.java.net/blog/haroldcarr/archive/2007/07/index.html

>
> Do you have any hint for me ?

Can you try with the Milestone 6 (RC1) release of WSIT?

What is the version of WCF you are using?

Thanks!

>
> Thanks.
>
> Message was edited by: rebelanger

rebelanger
Offline
Joined: 2006-08-24
Points: 0

Hi,

The problem seems to be fixed with M6. Thanks a lot !