Skip to main content

Can I call two different web services with the same security token?

29 replies [Last post]
bogdancsoregi
Offline
Joined: 2009-01-23
Points: 0

On the server I have three web services:
1. the STS
2. WebService A - needs a security token for accessing
3. WebService B - needs a security token for accessing

On the client I want to do the following (I am using Metro 1.4):

1. Call A.serviceMethod()
2. Call B.serviceMethod()

I want that both calls to use the same security token so that:

When the first call is done there will be a request to the STS after that I will have a token then the service A is called with the token then the service B is called using the same token.

What I managed to do until now is that when the first call is done the STS is called and I have a token then the service A is called using that token but when the second call is done the STS is called again and it issues another token used for the call to service B.

Is it possible to make the second call use the token issued first?

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
vietda
Offline
Joined: 2009-06-06
Points: 0

I have a project to develop a STS SAML token generator. But It is difficult to me at the moment to config metro to work with it.
If possible, you can help us.

Hi,

We have a project to develop STS generator to generate SAML token.

My application include:

1. STS service: HbsSTSService to generate and supply SAML token. I configured my STS service as "STS Issued Token" with Netbean. I use jbossws-metro-3.1.1.GA with Jboss server.
2. Web application "FirstWebApplication" with Webservice that I can call from client to method getSAMLAssertionFromSTS() to ask for generating and get SAML token like in thread "Call STS directly, generate and get SAML token explicitly" last time.
3. A client Servlet call to web webservice get SAML token.

We would like to find someone who have the experience in integreation métro to Jboss for our project.

My company can pay you for yours support.

If someone can help us, please contact me at vietda@yahoo.com

Best regards
DAO Anh Viet
00 33 6 50 31 20 16

bogdancsoregi
Offline
Joined: 2009-01-23
Points: 0

Finally I've managed to call a second web service using the saml assertion issued for a first one.

In my case I have only two web services (A and B), three with the STS. I needed to have the following flow: first the STS service is asked to issue a token (that applies to service A) then the client calls a method of service A with the issued token. Then all other calls are made to service B using the same saml assertion. The reason for this is that the server side is implemented in a strange way: STS can issue tokens that are asked for service A and service B verifies the token using the service A not the STS that's the reason why I need to call a method for service A before calling service B. Unfortunately I can not change anything on the server side because it is provided by another company.

The SSO feature that is planned for Metro 2.0 will support my use case, but until then I need a solution so I've made a not very pretty hack, but it works:
- I have a proxy STS server on the client side
- I have the service B configured with the proxy sts
- the service A is configured with the real STS
- the proxy sts makes a call to a method of service A which triggers the call to the real sts, in this step I've changed the TrustPluginImpl class in such a way that it will put in the context the entropy used when calling the proxy sts
- then I intercept the response from the real STS and return it as the response of the proxy sts in this way the same saml assertion is used for calling both services A and B and also those services will have the same client side entropy.

This solution is only a temporary solution until the SSO feature will be ready.

Thank you Jiandong for your help and I am looking forward to test the SSO implementation after it will be ready.

jdg6688
Offline
Joined: 2005-11-02
Points: 0

>
> This solution is only a temporary solution until the
> SSO feature will be ready.
>
> Thank you Jiandong for your help and I am looking
> forward to test the SSO implementation after it will
> be ready.

This feature is ready with current Metro 2.0 build:

http://blogs.sun.com/trustjdg/entry/token_caching_and_sharing

bogdancsoregi
Offline
Joined: 2009-01-23
Points: 0

Looking at the source code of com.sun.xml.wss.impl.misc.DefaultCallbackHandler.java class I saw that it tries to get a DefaultPrivKeyCert, but I do not know why it needs that?

jdg6688
Offline
Joined: 2005-11-02
Points: 0

Ok.

There is an issue here. Basically, the service ask for SymmetricKey Token type, but directly with SAMLToken HOK, we only support for PublicKey token type so it
looks for the private key of the client to sign the message.
Not sure we have a quick solution here if you can't change the TokenType on the service policy to PublicKey.
How urgent is this for you?
Can you wait for a couple of weeks when the SSO among servcies feature completed?

bogdancsoregi
Offline
Joined: 2009-01-23
Points: 0

Now I see the reason for the exception.

Unfortunately I can not change anything at the server side.

It is quite urgent. At the end of the next week I need to finish it.

Now I am looking in the source code of xwss, wsit and jax-ws to see if I can find a solution for this.

bogdancsoregi
Offline
Joined: 2009-01-23
Points: 0

It seams that the toString() method outputs the element type which is null.

I've made a case to dom element and it contains the right SAML assertion.

bogdancsoregi
Offline
Joined: 2009-01-23
Points: 0

The second question:

2. If I make a request using the IssueTokenManager can I intercept the xml message that is received as an input stream? If I can do that maybe I can use SAMLUtil class to create an valid SAML assertion.

bogdancsoregi
Offline
Joined: 2009-01-23
Points: 0

I have other two questions:

1. using the IssueTokenManager I've got the token object but it seams that the assertion is null: issuedToken.getTokenValue()=[saml:Assertion: null]

Looking at the dump of the message I can see the saml assertion:





username

urn:oasis:names:tc:SAML:1.0:cm:holder-of-key

7+lkdUTtZIMm71DsPUSw4Q==




username












bABdcrA5BUmU+zULEhQQ62i+yWI=


XLg1TD3PF2s42C6yl2AArzTRLGoa82F6yzTGbfWQYiqZlGpR9de0FxfWKzgv0O8eCyaKf6Jjlazc
zEb9TpktrA/TY+p7WZ9hhQ6MdBBx6OUkfOTdG1i2LCyZ1nGGxC2hGlXBrhtXU5TikRHSIqM21oct
oJstE4ARPoeS+MRdy8o=



dVE29ysyFW/iD1la3ddePzM6IWo=



jdg6688
Offline
Joined: 2005-11-02
Points: 0

Not sure what you set to printout in [saml:Assertion: null]; otherwise you won't see saml:Assertion.

Can you just cast issuedToken.getTokenValue() to an DOM element. Then it is the SAML assertion.

bogdancsoregi
Offline
Joined: 2009-01-23
Points: 0

The print was of the: issuedToken.getTokenValue().toString()

bogdancsoregi
Offline
Joined: 2009-01-23
Points: 0

I could not find any put method in STSIssuedTokenConfiguration.

bogdancsoregi
Offline
Joined: 2009-01-23
Points: 0

I've found a way to configure the credentials:
config.getOtherOptions().put(BindingProvider.USERNAME_PROPERTY, "usename");
config.getOtherOptions().put(BindingProvider.PASSWORD_PROPERTY, "password");

jdg6688
Offline
Joined: 2005-11-02
Points: 0

Yes, this is the right one.

bogdancsoregi
Offline
Joined: 2009-01-23
Points: 0

I've managed to call the STS using IssuedTokenManager.

Now I try to configure the SAMLCallbackHandler and I have some questions:

1. Is it possible to use SAML Token policy even if on the server the WSDL states IssuedToken?

2. How do I configure the client to use SAMLToken policy?

jdg6688
Offline
Joined: 2005-11-02
Points: 0

> I've managed to call the STS using
> IssuedTokenManager.
>
> Now I try to configure the SAMLCallbackHandler and I
> have some questions:
>
> 1. Is it possible to use SAML Token policy even if on
> the server the WSDL states IssuedToken?
No. Not now.
>
> 2. How do I configure the client to use SAMLToken
> policy?
You ned to configure the SAMLCallback Handler:



bogdancsoregi
Offline
Joined: 2009-01-23
Points: 0

I've tried to set the callbackHandler like that, but it does not work I get an exception:
"Exception in thread "main" javax.xml.ws.WebServiceException: WST0029:STS location could not be obtained from either IssuedToken or from client configuration for accessing the service http://...".

Is it possible that the cause of the exception is that the server WSDL contains the IssuedToken policy?

Unfortunately the server is implemented by another party and I can not change anything on the server.

jdg6688
Offline
Joined: 2005-11-02
Points: 0

> I've tried to set the callbackHandler like that, but
> it does not work I get an exception:
> "Exception in thread "main"
> javax.xml.ws.WebServiceException: WST0029:STS
> location could not be obtained from either
> IssuedToken or from client configuration for
> accessing the service http://...".
>
> Is it possible that the cause of the exception is
> that the server WSDL contains the IssuedToken
> policy?
>
Yes. That is the reason.

> Unfortunately the server is implemented by another
> party and I can not change anything on the server.

Yiu can probably to have a local copy of the wsdl and create your client against this local wsdl. In the local wsdl, you change IssuedToken to SAMLToken.

bogdancsoregi
Offline
Joined: 2009-01-23
Points: 0

I will try with a local copy.

bogdancsoregi
Offline
Joined: 2009-01-23
Points: 0

I had a look in all the threads that contained information about IssuedTokenManager. I found that the code for using it needs to look something like:

STSIssuedTokenConfiguration config =
new DefaultSTSIssuedTokenConfiguration(
);
IssuedTokenManager manager = IssuedTokenManager.getInstance();
IssuedTokenContext ctx = manager.createIssuedTokenContext(config, applyTo);
manager.getIssuedToken(ctx);
Token issuedToken = ctx.getSecurityToken();

But I can not figure it out how can I give the username and password for the STS, the parameters that noemaly I ggive like this:
((BindingProvider)port).getRequestContext().put(BindingProvider.USERNAME_PROPERTY, "user");
((BindingProvider)port).getRequestContext().put(BindingProvider.PASSWORD_PROPERTY, "password");

Is there any way of providing this when using IssuedTokenManager?

jdg6688
Offline
Joined: 2005-11-02
Points: 0

1. You may use wsit-client.xml for the STS to set up username/password.

2. Progrmatically,

config.put(BindingProvider.USERNAME_PROPERTY, "user");
config.put(BindingProvider.PASSWORD_PROPERTY, "password");

should work.

are you using Http basic authen?

bogdancsoregi
Offline
Joined: 2009-01-23
Points: 0

No, it is not http basic authentication..

The STS needs to receive the credentials in the rstMessage.

Are those properties used for basic authentication?

bogdancsoregi
Offline
Joined: 2009-01-23
Points: 0

Until now I've managed to programaticaly call STS and I have the saml assertion.

I've dowonloaded the service WSDL and replaced the section that contained:










128

http://schemas.xmlsoap.org/ws/2005/02/trust/SymmetricKey


http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1


with:







I have configured the callback handler in wsit-client.xml and in the callback I set the saml assertion obtained from STS.

Now I have the exception:
SEVERE: WSS0237: An Error occurred while populating SAML Policy in Dynamic Policy Callback
com.sun.xml.wss.impl.XWSSecurityRuntimeException: Could not locate KeyStore, check keystore assertion in WSIT configuration

I know that in wsit-cleint.xml I can specify a location for the key store but I do not know what exactly needs to be in that keystore. If I leave the client to call the STS for each webservice call (without the caching mechanism) I do not need that key store and it works.

Message was edited by: bogdancsoregi

jdg6688
Offline
Joined: 2005-11-02
Points: 0

Do you have any where setting keystores in you SAML call back handler implementation class?

bogdancsoregi
Offline
Joined: 2009-01-23
Points: 0

No, I do not have any keystore setting in the handler class. In the handler I am making a call to the STS using IssuedTokenManager and then I set the samlAssertion returned into the handler.

Do I need a keystore and if yest what should it contain?

jdg6688
Offline
Joined: 2005-11-02
Points: 0
bogdancsoregi
Offline
Joined: 2009-01-23
Points: 0

Thanks for the answer.

Is there any workaround for this, until the "SSO among services " feature is implemented?

I was reading something about SAMLCallbacks and I've tired some things but it did not worked.

Also do you have a planned release date for that feature?

jdg6688
Offline
Joined: 2005-11-02
Points: 0

Well, this feature hould be available in the next 3 to 4 weeks and will be in the Metro 2.0 release:
http://wikis.glassfish.org/metro/Wiki.jsp?page=Roadmap

In the mean time you may use SAMLToken policy assertion instead of IssuedToken policy assertion. On the client side you can implement a custom SAMLCallbackHandler where you can use IssuedTokenManager yo call an STS explicitly to obtain the SAML assertion from STS (search for the Metro forum for how IssuedTokenManager is used as a STS client, I posted it for many times. Since you have the control of SAMLCallbackHandler, you may implement it in a way that it can be shared by different clients and issued tokens are cached for each user and shared.

Thanks!

Jiandong

bogdancsoregi
Offline
Joined: 2009-01-23
Points: 0

Thanks again Jiandong,

I will start from your information and try to make the client work with a cached token.