|
Replies:
13
-
Last Post:
Jun 12, 2009 11:22 AM
by: jdg6688
|
|
|
|
|
|
|
Workaround for SAML2.0 broken STS attribute provider?
Posted:
Feb 18, 2009 6:22 PM
|
|
|
Hi,
I have a critical need to run my STS attribute provider with SAML2.0, but I am using glassfish v2, jdk 1.6 and netbeans 6.5, all currently use jax-ws 2.1. I cannot change these versions, but need the fix for the STS attribute provider. Which seems only in the Metro 2.0 baseline.
Is there any way I can move the fixed code onto my own 1.4 source code so it will work with glassfish v2?
If I copy the JAX-WS 2.2 jars into glassfish, it will break glassfish and the services I already have there. Won't it?
This is urgent, so any tips for the Metro Gurus I would greatly appreciate.
D
|
|
|
|
|
|
|
Re: Workaround for SAML2.0 broken STS attribute provider?
Posted:
Feb 18, 2009 8:29 PM
in response to: dgovoni
|
|
|
We are looking into this issue.
1. Can you use jdk 1.5?
2. Have you updated the webservices-api.jar in the GF/lib/endorsed directory when you
install Metro 2.0 in GF?
There is a way for making this work for Metro 1.4, using pluggable STSTokenProvider:
1. Have a custom STSTokenProvider, basically use the DefaultSTSTokenProvider in
Metro 2.0 work space as your code base? in createSAML2.0Assertion, It calls a method in WSTrustUtil which is also changed for fixing the isseu with attributes,. You may just take the method in your custom STSTokenProvider.
2. Plugin the custom STSTokenProvider to the STS the same way as adecribed here for custom STSAttributeProvider:
http://blogs.sun.com/trustjdg/entry/create_customer_sts_with_wsit
|
|
|
|
|
|
|
|
|
Re: Workaround for SAML2.0 broken STS attribute provider?
Posted:
Feb 18, 2009 8:56 PM
in response to: jdg6688
|
|
|
Hello Sir,
I don't think I can use jdk1.5, but if STS token provider works with SAML 2.0 in Metro 1.4 and JAX-WS 2.1, then I could possibly do that and create the attributes inside there. Let me investigate your suggestion some more.
First, I will try adding the jax-ws 2.2 jars to glassfish v2 and see if that works, but all the deployed services I think will have to be rebuilt and redeploy using that new jax-ws.
|
|
|
|
|
|
|
|
|
Re: Workaround for SAML2.0 broken STS attribute provider?
Posted:
Feb 18, 2009 9:05 PM
in response to: dgovoni
|
|
|
> 2.1, then I could possibly do that and create the
> attributes inside there.
You don't need to create attributes in the token provider. Just that the fix of the issue is
in the createSAML2.0Assertion method in DefaultSTSAttributeProvider.
You want use that with Metro 1.4, using an customer token provider with the fix.
> Let me investigate your
> suggestion some more.
>
> First, I will try adding the jax-ws 2.2 jars to
> glassfish v2 and see if that works, but all the
> deployed services I think will have to be rebuilt and
> redeploy using that new jax-ws.
|
|
|
|
|
|
|
|
|
Re: Workaround for SAML2.0 broken STS attribute provider?
Posted:
Feb 19, 2009 6:22 AM
in response to: jdg6688
|
|
|
If I use the STS token provider, couldn't I create my entire SAML2.0 token from scratch and supply it to the STS?
I am implementing your brokered STS model across domains. So in the remote STS, is there another provider that can be provided to validate the custom token?
If I use a custom token provider, are the token settings in WSIT configuration ignored?
I will look at the examples now for more information. thank you.
|
|
|
|
|
|
|
|
|
Re: Workaround for SAML2.0 broken STS attribute provider?
Posted:
Feb 19, 2009 6:24 AM
in response to: dgovoni
|
|
|
I forgot to ask, does the custom STSTokenProvider work for Metro 1.4 or is it new to 2.0?
|
|
|
|
|
|
|
|
|
Re: Workaround for SAML2.0 broken STS attribute provider?
Posted:
Feb 19, 2009 6:34 AM
in response to: dgovoni
|
|
|
Ok, I see it works with 1.4.
|
|
|
|
|
|
|
|
|
Re: Workaround for SAML2.0 broken STS attribute provider?
Posted:
Feb 19, 2009 11:51 AM
in response to: dgovoni
|
|
|
> If I use the STS token provider, couldn't I create my
> entire SAML2.0 token from scratch and supply it to
> the STS?
Yes.
>
> I am implementing your brokered STS model across
> domains. So in the remote STS, is there another
> provider that can be provided to validate the custom
> token?
Our default token provider handles token validation. You may of course customize it.
>
> If I use a custom token provider, are the token
> settings in WSIT configuration ignored?
The settings are available there. It is up to your implementation to use them.
>
> I will look at the examples now for more information.
> thank you.
|
|
|
|
|
|
|
|
|
Re: Workaround for SAML2.0 broken STS attribute provider?
Posted:
Feb 19, 2009 3:35 PM
in response to: jdg6688
|
|
|
I see now. It makes sense. The token provider provides validation as well.
I am using Metro 1.4,jdk 6, gf v2
Similar to using a custom STSAttributeProvider I did the same for STSTokenProvider.
I put a file in my STS project META-INF.services/
com.sun.xml.ws.api.security.trust.STSTokenProvider
In that file I put the class name that implements STSTokenProvider.
But it seems the class is not getting called. Is there another switch I need to make?
I put breakpoints inside my custom provider and debugged from netbeans, so it should have breaked I thought.
|
|
|
|
|
|
|
|
|
Re: Workaround for SAML2.0 broken STS attribute provider?
Posted:
Feb 20, 2009 3:03 AM
in response to: dgovoni
|
|
|
I have the same problem and after some debugging and inspection of the source code, I changed the wsdl of the STS from
<tc:Contract>com.sun.xml.ws.security.trust.impl.IssueSamlTokenContractImpl</tc:Contract>
to
<tc:Contract>com.sun.xml.ws.security.trust.impl.WSTrustContractImpl</tc:Contract>
Now, my own implementation of STSTokenProvider is used.
Next step is to get the Metro 2.0 source code to find the bug fix and use it in my implementation of STSTokenProvider.
It's like an adventure game. Does soemone know a good "Hint Book" (aka as documentation)?
|
|
|
|
|
|
|
|
|
Re: Workaround for SAML2.0 broken STS attribute provider?
Posted:
Feb 20, 2009 5:21 AM
in response to: andreasnagel
|
|
|
Hey, great find. Thanks for the tip and congrats on your first post! Hehe.
I will try it, but the part I'm don't understand still is that with the custom STS token provider what about the ws policy header in my STS. Does the custom token have to agree with that? For example, if my STS WSDL says "username with key", does it mean in my custom provider I have to provide a SAML2.0 username with key token too? I assume yes, but Metro will need to enforce that.
|
|
|
|
|
|
|
|
|
Re: Workaround for SAML2.0 broken STS attribute provider?
Posted:
Feb 22, 2009 6:26 AM
in response to: dgovoni
|
|
|
I think using the token provider SPI I can roll the token with attributes there for SAML2.0 tokens, on metro 1.4 since the SAML2.0 attribute provider is not being called. thanks again.
|
|
|
|
|
|
|
|
|
Re: Workaround for SAML2.0 broken STS attribute provider?
Posted:
Jun 12, 2009 5:34 AM
in response to: dgovoni
|
|
|
Hi,
how can we exactly build validator for our costom SAML token? How can we add it on to service side? Does anybody has an example of costom SAML validator?
Does we need service method anotation change (to chain include)?
Thanks.
|
|
|
|
|
java.net RSS
