eclipse-ee4j / eclipse-ee4j/metro-wsit
Negative test:No Exception/SOAP fault when there is a mismatch in the Token Reference mechanism in the client's request and the service's endpoint policy
- Dominant language
- Java
- Stars
- 6
- Forks
- 21
- Avg merge
- 10h 2m
- Merged PRs (30d)
- 1
Description
Setup:
Glassfish v2 build 33 promoted
WSIT build 1677
Attachments:
1)test case zip
2)server log snip
Description:
Client is built with a localized wsdl that has SymmetricBinding with X509Token.
The X509Token assertion has an sp:RequireKeyIdentifierReference assertion and
the endpoint policy has a corresponding Wss10/MustSupportRefkeyIdentifier
assertion. The client's request is meant to have token reference via keyidentifier.
The server is built with a different wsdl in which the X509Token assertion does
not have a RequireKeyIdentifierReference assertion , meaning DirectReference
mechanism for token reference is to be used.
The server is expected to throw a fault/exception because of a mismatch in the
way the token is referenced in the message.However this is not the observed
behavior.No soap fault/exception is thrown.
#### Environment
Operating System: All
Platform: All
#### Affected Versions
[current]
Source: [https://github.com/javaee/metro-wsit/issues/371](https://github.com/javaee/metro-wsit/issues/371)
Author: glassfishrobot
Contributor guide
Research direction
Start with the attached test case zip and server log snippet, using the GlassFish v2 build 33 and WSIT build 1677 setup. Compare the localized client WSDL's RequireKeyIdentifierReference and Wss10/MustSupportRefkeyIdentifier assertions with the server WSDL's X509Token policy. Done means the server reports a SOAP fault or exception for the token-reference mismatch.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- api, security
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100