Skip to main content

RE: ActAs from Metro client via AD FS 2.0 STS to Metro service

Please note these java.net forums are being decommissioned and use the new and improved forums at https://community.oracle.com/community/java.
1 reply [Last post]
jdg6688
Offline
Joined: 2005-11-02

to does not affect the
canonicalization of the XML:

See http://www.w3.org/TR/2001/REC-xml-c14n-20010315#XMLCanonicalization,
section 1.1 for requirement of canonicalization, section 3.3 and section
4.6.

Thanks!

Jiandong

*From:* Jesper Hvid [mailto:jh@globeteam.com]
*Sent:* Tuesday, February 08, 2011 3:16 AM
*To:* users@metro.java.net
*Subject:* RE: ActAs from Metro client via AD FS 2.0 STS to Metro service

Hi Jiandong, thanks for your reply,

They are already involved in the process, and of course I'm not trying
to start a political battle here I'm just looking for options J It would
of course be great to this to work across platforms as well. How about
changing tags from to should that
affect canonicalization? Because that's the third modification I'm
detecting. See my other mail for further details.

I have a sneaking suspicion this ends up with parties arguing over an
ambiguous rule in a WS-Security specification of whether or not to
include empty namespaces.

Thanks,

Jesper Hvid

*From:* Jiandong Guo [mailto:jiandong.guo...]
*Sent:* 8. februar 2011 05:46
*To:* users@metro.java.net
*Subject:* Re: ActAs from Metro client via AD FS 2.0 STS to Metro service

On 2/7/2011 8:07 AM, Jesper Hvid wrote:

The actual assertions are different. Upon leaving Metro the assertion
has been augmented with 'xmlns="http://www.w3.org/2000/09/xmldsig#'
attributes on and
elements, example

Original assertion:

>

Assertion sent from Metro:

Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"
>

This should not affect the digest with canonical process.

When I remove the appended 'xmlns="http://www.w3.org/2000/09/xmldsig#'
attributes from the message sent
from Metro the signature validates just fine.

You should check with ADFS folks.

Thanks!

Jianodng

Looking at the code that gets the token from Metro before attaching it
to the RST (with ActAs) is there something I'm doing wrong? As said
before I'm doing the same as in Jiangdong's article:

http://blogs.sun.com/enterprisetechtips/entry/security_token_service_and...

Token actAsToken = getActAsToken();

config.getOtherOptions().put(STSIssuedTokenConfiguration.ACT_AS,
actAsToken);

STSIssuedTokenFeature feature = new
STSIssuedTokenFeature(config);

//IPingService stub =
service.getCustomBindingIPingService(new WebServiceFeature[]{feature});

tiertwoclient.TierTwoService_Service service = new
tiertwoclient.TierTwoService_Service();

tiertwoclient.TierTwoService port =
service.getTierTwoServicePort(new WebServiceFeature[]{feature});

private Token getActAsToken()throws Exception {

return new GenericToken(getSAMLAssertion());

}

private Element getSAMLAssertion() {

Element samlAssertion = null;

try {

Subject subj = SubjectAccessor.getRequesterSubject(context);

Set set = subj.getPublicCredentials();

for (Object obj : set) {

if (obj instanceof XMLStreamReader) {

XMLStreamReader reader = (XMLStreamReader) obj;

//To create a DOM Element representing the Assertion :

samlAssertion = SAMLUtil.createSAMLAssertion(reader);

break;

} else if (obj instanceof Element) {

samlAssertion = (Element) obj;

break;

}

}

} catch (XMLStreamException ex) {

throw new XWSSecurityRuntimeException(ex);

} catch (XWSSecurityException ex) {

throw new XWSSecurityRuntimeException(ex);

}

return samlAssertion;

}

Thanks,

Jesper Hvid

*From:* Jesper Hvid [mailto:jh@globeteam.com]
*Sent:* 7. februar 2011 13:56
*To:* users@metro.java.net
*Subject:* ActAs from Metro client via AD FS 2.0 STS to Metro service

Hi,

I'm following Jiangdong's sample here:

http://blogs.sun.com/enterprisetechtips/entry/security_token_service_and...

(and am already aware of the similar problem described here)

http://social.msdn.microsoft.com/Forums/en/Geneva/thread/adb0eca4-d466-4...

I'm mainly looking for guidance as to how I can configure an ActAs RST
to customize it and try to match the AD FS 2.0 side of things.

My setup is this:

AD FS 2.0 STS

.NET service client

Java Metro service (TierOneService)

Java Metro service (TierTwoService)

Glassfish 3.1 with latest Metro promoted.

SOAP 1.2 is used 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. AD FS
2.0 however doesn't like the form of the RST arguing that:

The Federation Service failed to issue a token as a result of an error
during processing of the WS-Trust request.

Request type: http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Issue

Additional Data

Exception details:

System.Security.Cryptography.CryptographicException: ID6018: Digest
verification failed for reference '#_dc77e538-7f54-4d23-8735-06004f0fb73c'.

I'm very sure that the problems lies directly with ActAs, since I can
get the full chain working by calling normally (without ActAs). Observe
the following code. By using:

tiertwoclient.TierTwoService port = service.getTierTwoServicePort();

it works fine, however by using:

tiertwoclient.TierTwoService port = service.getTierTwoServicePort(new
WebServiceFeature[]{feature});

.. it stops working with the above error. What are my configuration
options with config.getOtherOptions().put(...) that I might try fiddling
with?

What I do in TierOneService:

Token actAsToken = getActAsToken();

config.getOtherOptions().put(STSIssuedTokenConfiguration.ACT_AS,
actAsToken);

STSIssuedTokenFeature feature = new
STSIssuedTokenFeature(config);

//IPingService stub =
service.getCustomBindingIPingService(new WebServiceFeature[]{feature});

tiertwoclient.TierTwoService_Service service = new
tiertwoclient.TierTwoService_Service();

// tiertwoclient.TierTwoService port =
service.getTierTwoServicePort(new WebServiceFeature[]{feature});

tiertwoclient.TierTwoService port =
service.getTierTwoServicePort();

Thanks,

Jesper Hvid

Reply viewing options

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

Hi Jiandong,

Ok, that's good to hear. Is there any way for me to produce a small code sample that computes the digest from an xml string? This way it's much easier for me to get a certain other major player involved :) I have such a code snippet running on the .NET side that consistently generates a wrong digest for the output assertion from Metro.

Mvh. Jesper Hvid

From: Jiandong Guo [mailto:jiandong.guo...]
Sent: 9. februar 2011 00:12
To: users@metro.java.net
Subject: RE: ActAs from Metro client via AD FS 2.0 STS to Metro service

to does not affect the canonicalization of the XML:

From: Jesper Hvid [mailto:jh@globeteam.com]
Sent: Tuesday, February 08, 2011 3:16 AM
To: users@metro.java.net
Subject: RE: ActAs from Metro client via AD FS 2.0 STS to Metro service

Hi Jiandong, thanks for your reply,

They are already involved in the process, and of course I'm not trying to start a political battle here I'm just looking for options :) It would of course be great to this to work across platforms as well. How about changing tags from to should that affect canonicalization? Because that's the third modification I'm detecting. See my other mail for further details.

I have a sneaking suspicion this ends up with parties arguing over an ambiguous rule in a WS-Security specification of whether or not to include empty namespaces.

Thanks,
Jesper Hvid

From: Jiandong Guo [mailto:jiandong.guo...]
Sent: 8. februar 2011 05:46
To: users@metro.java.net
Subject: Re: ActAs from Metro client via AD FS 2.0 STS to Metro service

On 2/7/2011 8:07 AM, Jesper Hvid wrote:

The actual assertions are different. Upon leaving Metro the assertion has been augmented with 'xmlns="http://www.w3.org/2000/09/xmldsig#' attributes on and elements, example

Original assertion:

>

Assertion sent from Metro:

Algorithm="http://www.w3.org/2000/09/xmldsig#sha1">
This should not affect the digest with canonical process.

When I remove the appended 'xmlns="http://www.w3.org/2000/09/xmldsig#' attributes from the message sent from Metro the signature validates just fine.
You should check with ADFS folks.

Thanks!

Jianodng

Looking at the code that gets the token from Metro before attaching it to the RST (with ActAs) is there something I'm doing wrong? As said before I'm doing the same as in Jiangdong's article:
http://blogs.sun.com/enterprisetechtips/entry/security_token_service_and...

Token actAsToken = getActAsToken();
config.getOtherOptions().put(STSIssuedTokenConfiguration.ACT_AS, actAsToken);

STSIssuedTokenFeature feature = new STSIssuedTokenFeature(config);

//IPingService stub = service.getCustomBindingIPingService(new WebServiceFeature[]{feature});

tiertwoclient.TierTwoService_Service service = new tiertwoclient.TierTwoService_Service();
tiertwoclient.TierTwoService port = service.getTierTwoServicePort(new WebServiceFeature[]{feature});

private Token getActAsToken()throws Exception {
return new GenericToken(getSAMLAssertion());
}

private Element getSAMLAssertion() {
Element samlAssertion = null;
try {
Subject subj = SubjectAccessor.getRequesterSubject(context);
Set set = subj.getPublicCredentials();
for (Object obj : set) {
if (obj instanceof XMLStreamReader) {
XMLStreamReader reader = (XMLStreamReader) obj;
//To create a DOM Element representing the Assertion :
samlAssertion = SAMLUtil.createSAMLAssertion(reader);
break;
} else if (obj instanceof Element) {
samlAssertion = (Element) obj;
break;
}
}
} catch (XMLStreamException ex) {
throw new XWSSecurityRuntimeException(ex);
} catch (XWSSecurityException ex) {
throw new XWSSecurityRuntimeException(ex);
}
return samlAssertion;
}

Thanks,
Jesper Hvid

From: Jesper Hvid [mailto:jh@globeteam.com]
Sent: 7. februar 2011 13:56
To: users@metro.java.net
Subject: ActAs from Metro client via AD FS 2.0 STS to Metro service

Hi,

I'm following Jiangdong's sample here:
http://blogs.sun.com/enterprisetechtips/entry/security_token_service_and...

(and am already aware of the similar problem described here)
http://social.msdn.microsoft.com/Forums/en/Geneva/thread/adb0eca4-d466-4...

I'm mainly looking for guidance as to how I can configure an ActAs RST to customize it and try to match the AD FS 2.0 side of things.

My setup is this:

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

SOAP 1.2 is used 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. AD FS 2.0 however doesn't like the form of the RST arguing that:
The Federation Service failed to issue a token as a result of an error during processing of the WS-Trust request.
Request type: http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Issue

Additional Data
Exception details:
System.Security.Cryptography.CryptographicException: ID6018: Digest verification failed for reference '#_dc77e538-7f54-4d23-8735-06004f0fb73c'.

I'm very sure that the problems lies directly with ActAs, since I can get the full chain working by calling normally (without ActAs). Observe the following code. By using:
tiertwoclient.TierTwoService port = service.getTierTwoServicePort();

it works fine, however by using:
tiertwoclient.TierTwoService port = service.getTierTwoServicePort(new WebServiceFeature[]{feature});

.. it stops working with the above error. What are my configuration options with config.getOtherOptions().put(...) that I might try fiddling with?

What I do in TierOneService:

Token actAsToken = getActAsToken();
config.getOtherOptions().put(STSIssuedTokenConfiguration.ACT_AS, actAsToken);
STSIssuedTokenFeature feature = new STSIssuedTokenFeature(config);

//IPingService stub = service.getCustomBindingIPingService(new WebServiceFeature[]{feature});

tiertwoclient.TierTwoService_Service service = new tiertwoclient.TierTwoService_Service();
// tiertwoclient.TierTwoService port = service.getTierTwoServicePort(new WebServiceFeature[]{feature});
tiertwoclient.TierTwoService port = service.getTierTwoServicePort();

Thanks,
Jesper Hvid