search

javaee / metro-wsit

https://javaee.github.io/metro-wsit/
Other
9 stars 24 forks source link

Metro modifies SAML assertion before appending it to ActAs element in RequestSecurityToken message #1640

Open glassfishrobot opened 13 years ago

glassfishrobot commented 13 years ago

AD FS 2.0 STS .NET service client Java Metro service (TierOneService) Java Metro service (TierTwoService) Glassfish 3.1 with latest Metro promoted b25

SOAP 1.2 across the board

Currently the client can get a token, call the TierOneService and the TierOneService can read the token and create an RST with ActAs. When metro adds the token to the ActAs element in the RST the assertion is modified which then breaks the digest validation of the canonicalized assertion.

I do the following to repro:

Make a call from my client to reproduce the scenario Collect the full RST that AD FS 2.0 receives on the wire Collect the value that AD FS 2.0 does digest validation on Verified that on .NET that this value fails digest validation Verified that on Java that this value fails digest validation

So in my test both Java and .NET agree that the SHA1 digest of the attached canonicalized value is: "HKGhKOF0Eq8T2ZBYi27bY3QxNtU=" While it should be: "YjnmL0e/NNthHQTVcr4DZuFbfXA="

Knowing this I looked more at canonicalization. I grabbed the full assertion from the RST received on the wire at AD FS 2.0 (full-actas-rst-received-on-wire-on-adfs2.xml). I then removed the signature element (assertion-received-by-adfs2-pre-canonicalization.xml). I then canonicalized the contents of this file and computed a SHA1 hash on both platforms. Both yield: "HKGhKOF0Eq8T2ZBYi27bY3QxNtU=" Again, while it should be: "YjnmL0e/NNthHQTVcr4DZuFbfXA="

After discussing this with Jiandong on email he asserted that: "Ok. Look like the SAML assertion is changed (white space removed) when attached to RST. Can you file a bug and we will look into it as soon as possible.

Thanks!

Jiandong"

Environment

Latest Metro promoted build 2.1 b25 running on Glassfish 3.1

Affected Versions

[2.2]

glassfishrobot commented 13 years ago

Reported by jollerbarn

glassfishrobot commented 13 years ago

mmatula said: Assigning to Jiandong.

glassfishrobot commented 12 years ago

gchoi said: Is this issue get fixed now?

glassfishrobot commented 12 years ago

bshrom said: This bug is caused by the way JAXB handles xsd:any DOM content ( see notes on related bug: http://java.net/jira/browse/JAXB-758 )

The same problem exists with OnBehalfOf when SAML Assertion in included.

When incoming SAML Assertion is submitted to OnBehalfOf and uses following format <Assertion xmlns="urn:oasis:names:tc:SAML:2.0:assertion", assertion is modified before it goes on the wire as: <saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion".

I will file a separate bug for OnBehalfOf if necessary.

glassfishrobot commented 12 years ago

cistox said: It is incredible the JAXB 758 bug is still there. The way xsd:Any is handled is wrong. There is no reason to add namespaces from the outer envelope (e.g. WS-Transfer scaffolding) on the xsd:Any content.

Primary European projects are suffering of these bugs, it is very bad that such fixes are not applied due to dependancies from other bugged projects... I am curious to know one of these projects that is relying on such JAXB bugs for its functions. It's a crazy situation.

XML is a nice thing but it's happen is going to be used on real business scenarios... thus digital signatures and other most serious dependancies have to be supported...

glassfishrobot commented 12 years ago

nitkal said: We tried to recreate the issue using a metro sample (ws-trust/delegate) using the Assertion (generated by ADFS) attached in issue 1631. We could not observe the namespaces being modified by Metro. We are trying to analyze this further.

glassfishrobot commented 12 years ago

nitkal said: Also, from a sample JAXB Marshal/Unmarshal test code, it does not appear to be an error in the way JAXB marshalling is done. Needs further investigation

glassfishrobot commented 12 years ago

dkulp said: Might be related to http://java.net/jira/browse/JAXB-909

CXF is seeing the same issue with whitespace being removed for DOM content.

glassfishrobot commented 11 years ago

symonchang said: This is a jaxb issue, instead of WSIT issue.

glassfishrobot commented 13 years ago

Was assigned to symonchang

glassfishrobot commented 7 years ago

This issue was imported from java.net JIRA WSIT-1640