Skip to main content

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.
6 replies [Last post]
jollerbarn
Offline
Joined: 2009-05-24

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.
gilbertoribeiro
Offline
Joined: 2011-02-10

Hi,
I'm following the same sample, but I developed a custom STS using WCF and It's working fine..
When I call the java service from .NET the client get the token from STS, but when the java service recieve the token I get an exception:
SEVERE: WSS1713: Signature verification failed due to: Unsupported signature algorithm found
........

SEVERE: WSITPVD0035: Error in Verifying Security in Inbound Message.
com.sun.xml.wss.XWSSecurityException: javax.xml.crypto.dsig.XMLSignatureException: Unsupported signature algorithm found
The STS is encrypting the token using the cert xws-security-server (I export the cert public key from keystore and using It in my custom STS)
Do you have any Idea from how I can solve this problem. Can you share your TierOneService that is configured to use the AD FS 2.0 ?
Sorry if I made some mistake, I'm brasiliam.
Thanks
Gilberto Ribeiro

jollerbarn
Offline
Joined: 2009-05-24

Right, I think I'm approaching the issue here.

Something appears to be fiddling with the token after it's received on the Metro side and before or while it's included in the RST as an ActAs token. I'm attaching two files:

- SamlSecurityTokenFromJava (ad fs 2.0 token on the cable).xml

- SamlSecurityTokenFromJava (as sent from Metro).xml

What I can see is

1) The token sent from AD FS 2.0 validates correctly and the computed digest is the same as the one in the token: "mt+59+zkT4ObwUdEkw+1Y+MT2aaFBNnWkndkXyeOS7U="

2) The token sent via ActAs from the Metro client does not validate against the same digest in the message: "mt+59+zkT4ObwUdEkw+1Y+MT2aaFBNnWkndkXyeOS7U=". Instead, the message from Metro generates this digest: "QtoBVHt5oKPDq2NwFotqHxPjXjPfFlv1bcrxVXjTv8c="

3) 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:

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.

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

jollerbarn
Offline
Joined: 2009-05-24

Hi again,

I have another example attached. The assertions differ in quite a few ways when leaving Metro.

1) There are extra xmlns:ds=http://www.w3.org/2000/09/xmldsig# attributes on DigestMethod and KeyInfo elements

2) Some and KeyInfo elements have changed from open-ended to closed-ended, aka from to

3) When I rectify the modified elements in the sent assertion validation passes without problems

In the meantime I did the following to approach the problem.

1) Wrote out the assertion in memory in Metro before it's applied to the outgoing message via the following code snippet. The assertion that is written out is attached - and it is VALID (aka. not modified).

Token actAsToken = getActAsToken();

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

// Use a Transformer for output

TransformerFactory transformerFactory = TransformerFactory.newInstance();

Transformer transformer = transformerFactory.newTransformer();

// Try to pass it in as a generic token

GenericToken tempToken = new GenericToken(samlAssertion);

Element assertion = (Element)tempToken.getTokenValue();

DOMSource source = new DOMSource(assertion);

File f = new File("c:/output-java.xml");

StreamResult result = new StreamResult(f);

transformer.transform(source, result);

2) However, when receiving the message on the transport layer at AD FS 2.0 the assertion is no longer the same. Either I'm doing something fundamentally wrong here or something sneaky is happening to the token with this operation:

Token actAsToken = getActAsToken();

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

Jiandong: Is there any way of adding the assertion exactly as it was upon input?

Mvh. Jesper Hvid

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

Right, I think I'm approaching the issue here.

Something appears to be fiddling with the token after it's received on the Metro side and before or while it's included in the RST as an ActAs token. I'm attaching two files:

- SamlSecurityTokenFromJava (ad fs 2.0 token on the cable).xml

- SamlSecurityTokenFromJava (as sent from Metro).xml

What I can see is

1) The token sent from AD FS 2.0 validates correctly and the computed digest is the same as the one in the token: "mt+59+zkT4ObwUdEkw+1Y+MT2aaFBNnWkndkXyeOS7U="

2) The token sent via ActAs from the Metro client does not validate against the same digest in the message: "mt+59+zkT4ObwUdEkw+1Y+MT2aaFBNnWkndkXyeOS7U=". Instead, the message from Metro generates this digest: "QtoBVHt5oKPDq2NwFotqHxPjXjPfFlv1bcrxVXjTv8c="

3) 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:

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.

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

jdg6688
Offline
Joined: 2005-11-02

On 2/7/2011 8:07 AM, Jesper Hvid wrote:
>
> 3) 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
>
>
>

jollerbarn
Offline
Joined: 2009-05-24

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

jdg6688
Offline
Joined: 2005-11-02

<OpenEnded></OpenEnded> to <ClosedEnded/> 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.