IssuedToken

[metro-3]

Hi,

Is it possible to specify a STS on the service side - using IssuedToken - with the WSDL location rather than specifying the endpoint and metadata endpoint? (Dynamic MEX exchange is no seen as being as desireable quality in the environments I am working)

I have tried omiting the MEX information in IssuedToken assertion but metadata exchange still appears to be attempted. As this can be done with the PreConfiguredSTS on the client side I feel that there should be a way of doing this on the service side but can't figure out what that is. Does anyone know whether this is possible?

Thanks,
Graeme
[Message sent by forum member 'graemejenkinson' (gcjenkinson@...)]

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

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[metro-3]

No. We have to keep the server side with standard or common policy assertions in the wsdl.
[Message sent by forum member 'jdg6688' (jiandong.guo@...)]

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

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[metro-3]

I'm not really sure that I completely understand you answer. If you are saying that the semantics of the IssuedToken assertion don't allow this I am confused as to why not.

When using Metro to secure a service with an STS the IssuedToken assertions Issuer is specified by a WS-Addressing address with accompanying metadata. The <Metadata> element is an extension point to WS-Addressing EndpointReference in which Metro specifies the MEX endpoint (as specified in WS-MetadataExchange). Therefore, I don't understand why the EPR's metadata section can't be used to include the WSDL metadata (as specified in Web Services Addressing 1.0 - Metadata).

My knowledge of WS-Addressing and WS-MetadataExchnage isn't great so I may be missing something. But as I don't see that the IssuedToken assertion should be dependent on the dynamic metadata exchnage I feel like this should work.

thanks,
Graeme
[Message sent by forum member 'graemejenkinson' (gcjenkinson@...)]

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

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[metro-3]

> I'm not really sure that I completely understand your
> answer. If you are saying that the semantics of the
> IssuedToken assertion don't allow this, then I am
> confused as to why not.

Yes, it is allowed in theory. But is is just not supporetd except with Metadata
endpoint.

File an enhancement here https://wsit.dev.java.net/servlets/ProjectIssues
if you feel like you have a strong use case.
[Message sent by forum member 'jdg6688' (jiandong.guo@...)]

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

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[metro-3]

Hi Jiandong,

Thanks for confirming that for me.

At the moment I'm just trying to confirm my understanding so that I can be clear with the stakeholders of my project (also I'm like a dog with a bone with everything so I can't stop until everything is completely clear to me!).

My concern about MEX (in this context) are:

1) Ensuring the confidentiality and integrity of the MEX data as it is passed dynamically. Point-to-point I can see that this can be achieved through HTTPS, but across an organisational boundary this may present problems. I can't see that in my application domain it is a desireable to expose the location and policies of an STS.

2) If the MEX data is passing across a boundary between security domains of different sensitivities then a guard needs to be able to determine dynamically whether this is allowed. This may not be an issue as the guard needs to make a whole host of other decisions. But it's an unkown at the moment so it concerns me (a little).

Thanks again for the support.

Graeme
[Message sent by forum member 'graemejenkinson' (gcjenkinson@...)]

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

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[metro-3]

In theory, you can secure mex messages with message level security.
[Message sent by forum member 'jdg6688' ]

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

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[metro-3]

Hi,

I see. I wasn't aware that the MEX responses could also be secured (I might still have some reservations about doing this for performance reasons).

How about something a little more challenging! I've integrated my brokered trust model with a service created by a colleague. I think that I've done this correctly as I can see the operations being secured. However, occassionally (in fact quite regularly) and with no recognisable pattern the client (a thick Java client) throws an exception:

Caused by: com.sun.xml.wss.XWSSecurityException: Unsupported Header type
        at com.sun.xml.ws.security.opt.impl.message.ETHandler.toData(ETHandler.java:276)

I can't see any reason why this would be happening. The attached log shows the same operation called twice in succession. The first time the message is secured (in this instance I've cut down the signing and encryption of the message for clarity) the second instance fails.

Do you have any idea what might be causing this?
[Message sent by forum member 'graemejenkinson' ]

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

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[metro-3]

Forgot the exception log!
[Message sent by forum member 'graemejenkinson' ]

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

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...