Skip to main content

Forcing a Secure Conversation renewal programmatically

29 replies [Last post]
ernestojpg
Offline
Joined: 2005-10-09

Hi everyone!

I wanted to ask whether it is possible to renew a secure conversation programmatically. The reason is because in my system, the client sends a SAML Token during initialization of the secure conversation, and I would be interested to send a new token occasionally. For this, the client would have to force the renewal of the secure conversation.

Is this possible?

Thanks!

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
ernestojpg
Offline
Joined: 2005-10-09

Ok Shyam,

Then I will send a simplified SAML Token in each call to the Service, and a complete SAML Token (and with a new ID) when there are any new.

Thank you very much for your help! ;)

ernestojpg
Offline
Joined: 2005-10-09

Hi!

I've tested last Metro nightly build again (June 4, 2008 now), and the problem seems to be solved! Thanks Shyam, it works perfectly :D

Now, the last question about that ;)

For optimization reasons, I'm trying to send the SAML token only when it is necessary. In other words, I want to send the SAML token only when there is any new. For this reason, I've configured my SamlCallbackHandler to return a SAML token in the first call, and to returns null on the next calls.

But when my SamlCallbackHandler returns null, a Exception is thrown on this form:

[i]04-jun-2008 20:47:16 com.sun.xml.wss.impl.filter.SignatureFilter process
SEVERE: WSS1418: None of SAML Assertion, SAML AuthorityBinding information was set into the Policy by the CallbackHandler
04-jun-2008 20:47:16 com.sun.xml.wss.jaxws.impl.SecurityPipeBase secureOutboundMessage
SEVERE: WSSPIPE0024: Error in Securing Outbound Message.
com.sun.xml.wss.XWSSecurityException: None of SAML Assertion, SAML AuthorityBinding information was set into the Policy by the CallbackHandler04-jun-2008 20:47:16 com.sun.xml.wss.jaxws.impl.SecurityClientPipe process
SEVERE: WSSPIPE0024: Error in Securing Outbound Message.com.sun.xml.wss.impl.WssSoapFaultException: None of SAML Assertion, SAML AuthorityBinding information was set into the Policy by the CallbackHandler
Caused by: com.sun.xml.wss.XWSSecurityException: None of SAML Assertion, SAML AuthorityBinding information was set into the Policy by the CallbackHandler....
....[/i]

Are there any form to do this, or I must send the same SAML Token on every call to the Service?

Thanks you very much for your help. Regards.

shyam_rao
Offline
Joined: 2006-05-05

> Are there any form to do this, or I must send the same SAML Token on every call to the Service?

client sends request as per the policy defined in the service wsdl. So, SAML token has to be send in every call to service.

ernestojpg
Offline
Joined: 2005-10-09

Hi Shyam!

I've tested last Metro nightly build (June 3, 2008), but the problem still remains. The client is still caching the SAML Tokens :( Any ideas?

Thanks.

ernestojpg
Offline
Joined: 2005-10-09

Thanks shyam!

I will test it this afternoon, and let you know tomorrow.

Regards.

ernestojpg
Offline
Joined: 2005-10-09

It is a standard Java SE client. I can attach complete Client and Server proyects if you want.

Thank you very much.

shyam_rao
Offline
Joined: 2006-05-05

I have fixed an issue (https://wsit.dev.java.net/issues/show_bug.cgi?id=923) today.

Can you try with tomorrow's metro nightly build ?

ernestojpg
Offline
Joined: 2005-10-09

Hi Shyam,

I've tested it with last Metro nightly build. I attach the request-response messages, and a updated WSDL file.

During the SecureConversation stablishment my SamlCallbackHandler is called. In the first call to the Service my SamlCallbackHandler is called again, and a new SAML Token is created. In subsequent calls to the Service my SamlCallbackHandler is not called, and the same SAML Token is passed. Is that a bug?

Thank you too much for your help. Regards.

shyam_rao
Offline
Joined: 2006-05-05

I will double check and get back to you.

BTW, is it a standalone client or JSP/servlet client ?

ernestojpg
Offline
Joined: 2005-10-09

Upps, my WSDL file :)

ernestojpg
Offline
Joined: 2005-10-09

Hi Shyam!

I've added the EndorsingSupportingTokens assertion to my wsit config file (at server side), as you said:

============================================









=============================================

However, when I generete the WSDL file with Netbeans, a diferent fragment of code is generated:

=============================================

















=============================================

Is that normal? I've attached my WSDL file.

The problem is that my SamlCallbackHandler is not called on every call to the Service. It is called only twice: one in the SecureConversation stablishment, and another in the first call to the Service. It look like the SAML Assertion is cached on Client side.

However, with a SV mechanism, my SamlCallbackHandler is called on every call to the Service.

Thanks!

shyam_rao
Offline
Joined: 2006-05-05

> Is that normal? I've attached my WSDL file.

Its not a problem.

> The problem is that my SamlCallbackHandler is not called on every call to the Service.

When you call the service 2nd time, what happens ? Can you paste the request-response message when you call the service 2nd time in the same established session ?

I just developed an servlet client app. for a similar wsdl. And my SamlCallbackHandler is called for every request.

> It is called only twice: one in the SecureConversation stablishment,

Because, SamlToken is defined in SignedSupportingTokens under bootstrap policy.

> and another in the first call to the Service.

Because, SamlToken is defined as EndorsingSupportingTokens for the application message.

> It look like the SAML Assertion is cached on Client side.

No.

> However, with a SV mechanism, my SamlCallbackHandler is called on every call to the Service.

Its very strange. In your wsdl, you have defined SamlToken as EndorsingSupportingTokens for application message, so SamlCallbackHandler has to be called on every application request to service.

ernestojpg
Offline
Joined: 2005-10-09

Thanks Shyam!

I've tested it, and it seems that works fine! The SamlCallbackHandler is called to generate a SAML 'Sender Vouches' Token. I have a question, why a 'Sender Vouches' mechanism is required, instead a 'Holder of Key' mechanism?

I'm going to test it more in depth, and I will let you know.

Thanks!

shyam_rao
Offline
Joined: 2006-05-05

https://wsit-docs.dev.java.net/releases/1.1/ahicu.html#ahidc will give you the exact difference between SV and HOK.

If you want to send your authorization token (i.e.SAML assertion of type HOK), then add EndorsingSupportingTokens assertion instead of SignedSupportingTokens.

ernestojpg
Offline
Joined: 2005-10-09

Thanks Shyam! It sounds good! :)

But, how can the client send a SupportingToken with a SAML authorization on every subsequent call to the Service? (in a Secure Conversation, of course)

Is there any examples (blog, forum, etc) about that?

Tranks!

shyam_rao
Offline
Joined: 2006-05-05

In your service wsdl, add SignedSupportingTokens assertion (with SamlToken element under it) outside of top level SymmetricBinding or AsymmetricBinding element.

snippet of SignedSupportingTokens with SamlToken under it :
============================================









=============================================

ernestojpg
Offline
Joined: 2005-10-09

Hi Shyam!

Your post is great! But I think that nowadays Metro 1.2 only renews the SecureConversationToken when it is expired. I think that Metro should also check the validity of the authorization token submitted by the client. In other words, the 'Secure Session Token Lifetime' should be the most restrictive among the default lifetime and the lifetime of the authorization token submitted by the client.

Regards.

shyam_rao
Offline
Joined: 2006-05-05

> I think that Metro should also check the validity of the authorization token submitted by the client.

We have fixed the validity checking of the conditions statement for protocol messages only(which you have already tested with latest metro nightly).

I think, checking of lifetime(in application message: client to service) of your authorization token should be application specific. You can do this lifetime checking in your service implementation and throw an exception if authorized token is expired.

You can call the following static method to validate the time in Condition statement in your service implementation, whose return type is boolean :
com.sun.xml.wss.saml.util.SAMLUtil.validateTimeInConditionsStatement(Element samlAssertion)

For how to get the SAMLAssertion in your service implementation, see this blog : http://weblogs.java.net/blog/kumarjayanti/archive/2007/12/accessing_the_...

One solution is : keep the expiry time of SecureConversationToken equal(or just greater than) to expiry time of your authorization token.

ernestojpg
Offline
Joined: 2005-10-09

Hi!

> I think, checking of lifetime(in application message: client to service) of your authorization token should be application specific. You can do this lifetime checking in your service implementation and throw an exception if authorized token is expired.

OK, This is not a problem for me.

> One solution is : keep the expiry time of SecureConversationToken equal(or just greater than) to expiry time of your authorization token.

The expiry time of SecureConversationToken is a fixed value that is configured in wsit-client.xml file. Are there any way to change it programmatically? A new client property could be a solution. For example:

[i]((BindingProvider)port).getRequestContext().put(BindingProvider.SECURE_CONVERSATION_LIFETIME, 35000);[/i]

It would also be a solution that the client or the server could force the renewal of the SecureConversationToken programmatically.

Regards.

shyam_rao
Offline
Joined: 2006-05-05

> The expiry time of SecureConversationToken is a fixed value that is configured in
> wsit-client.xml file. Are there any way to change it programmatically?

Currently we don't support any part of secure conversation programmatically with Metro.

> A new client property could be a solution. For example:
>
> [i]((BindingProvider)port).getRequestContext().put(Bin
> dingProvider.SECURE_CONVERSATION_LIFETIME, 35000);[/i]
>
> It would also be a solution that the client or the server could force the renewal of the
> SecureConversationToken programmatically.

The expiry time is cached along with the SCToken on client and server side during protocol message exchange. Unless, this time is expired we cannot force the renewal of this token( it doesn't make any sense also to forcibly renew the token before it expires).

Also, renewal of the token is initiated from the client. So, there are other attributes present along with lifetime element in the wsit-client.xml file (i.e. renewExpiredSCT=true, ) , which tells whether client can send the renewal request or not if SCToken is expired.

If i understood your requirement correctly, then :
- you want to use a authorization token(i.e. SAML assertion) to access the server resources for a limited time.

Solution :
You can establish the SecureConversation session with a x509 certificates and in the application message you can send the SupportingToken (i.e. your authorization token). In this way, the authorization token's renewal doesn't have to be dependent on the session's renewal.

On every client call to service, SamlCallbackHandler will be called and a new Saml assertion will be created. You can cache this SAML assertion on the client side. On every subsequent call to service, you can check in the SamlCallbackHandler itself, whether previously generated SAML assertion is already present in the cache or not. If it is present, then check the expiry of condition statement of the cached SAML assertion on the client side also. If it is expired, then create a new SAML assertion and send it to service. In this way, you can avoid unnecessary message exchange with service for expired authorization token.

ernestojpg
Offline
Joined: 2005-10-09

Well, I've tested the latest Metro nightly build, and now the conditions are verified during the secure conversation stablishment, but not during subsequent client calls to service. In other words, a client with a token with validity for 2 minutes can use the service for hours.

I think that the 'Secure Session Token Lifetime' should be the most restrictive among the default lifetime and the lifetime of the authorization token. What do you think?

Thanks.

shyam_rao
Offline
Joined: 2006-05-05
ernestojpg
Offline
Joined: 2005-10-09

Hi!

Yes, during initialization of the secure conversation, client sends a SAML Token (with a Authorization Decision, or Attribute statements, for example). This token will have a limited life ('NotBefore' and 'NotOnOrAfter' conditions). I've implemented the logic for verify this conditions on the server side. For this reason, the client may need to update the SAML Token (when it expires).

When the secure conversation is automatically renewed, is the client's SamlCallbackHandler called again (to generate a new one), or the original SAML is used?

Thanks!

jdg6688
Offline
Joined: 2005-11-02

Interesting. As mentioned, one need the original client credentials (e.g SAML assertion) to renew the secure conversation context, not a new one, to make sure it is the same client for the session.

Two points:

1. The 'NotBefore' and 'NotOnOrAfter' should be only verified when it is used for authenticating the user. Are you checking these condotions for each
subsequent calls? Not sure you should do this.

> Hi!
>
> Yes, during initialization of the secure
> conversation, client sends a SAML Token (with a
> Authorization Decision, or Attribute statements, for
> example). This token will have a limited life
> ('NotBefore' and 'NotOnOrAfter' conditions). I've
> implemented the logic for verify this conditions on
> the server side. For this reason, the client may need
> to update the SAML Token (when it expires).
>
> When the secure conversation is automatically
> renewed, is the client's SamlCallbackHandler called
> again (to generate a new one), or the original SAML
> is used?
>
> Thanks!

ernestojpg
Offline
Joined: 2005-10-09

> Interesting. As mentioned, one need the original
> client credentials (e.g SAML assertion) to renew the
> secure conversation context, not a new one, to make
> sure it is the same client for the session.

What a pity! It would be interesting that the client's SamlCallbackHandler was called again to generate a new SAML Token.

> Two points:
>
> 1. The 'NotBefore' and 'NotOnOrAfter' should be only
> verified when it is used for authenticating the user.
> Are you checking these condotions for each
> subsequent calls? Not sure you should do this.

Yes, client sends a Holder-of-Key Token with a AuthorizationDecision. On Server side, time conditions are cached, and It checks these conditions for each subsequent calls. Does WSIT automatically check these conditions? What happens when the conditions expire?

Regards.

jdg6688
Offline
Joined: 2005-11-02

> What a pity! It would be interesting that the
> client's SamlCallbackHandler was called again to
> generate a new SAML Token.

You must use the original credential to renew the session as required in the
ws-secureconversation specification. I
>
> Two points:
>
> 1. The 'NotBefore' and 'NotOnOrAfter' should be
> only
> verified when it is used for authenticating the
> user.
> Are you checking these condotions for each
> subsequent calls? Not sure you should do this.
>
> Yes, client sends a Holder-of-Key Token with a
> AuthorizationDecision. On Server side, time
> conditions are cached, and It checks these conditions
> for each subsequent calls. Does WSIT automatically
> check these conditions? What happens when the
> conditions expire?
The SAML assertion is validated upon it is used in the authentication process.
Why you need to check the Conditions for the subsequent calls when the session is established?
>
> Regards.

ernestojpg
Offline
Joined: 2005-10-09

> The SAML assertion is validated upon it is used in
> the authentication process.
> Why you need to check the Conditions for the
> subsequent calls when the session is established?

I've tested it again, and it seems how WSIT doesn't check the 'NotBefore' and 'NotOnOrAfter' conditions. Is that normal?

For this reason I'm checking the conditions on server side (by hand).

jdg6688
Offline
Joined: 2005-11-02

We don't do it in the security layer for performance reason.
If secure conversation is enabled, we do process the the SAML asserion
and cache it with the session context when we create the secure conversation context. We should do the lifetime check of the SAML asseriton
in this process. If not, it is an issue. I will double check and get back.

jdg6688
Offline
Joined: 2005-11-02

Currently you won't be able to do any part of secure conversation programmatically currently with Metro. We only renew the session when it is expired and when it is configured by the user
to renew the session automatically. Even for this, we need to use the original client credentials for the renewing per the ws-secureconversation spec.

Questions:

1. Why you need to send a new token when the secure conversation is still alive? Does this new token carry different or addtional user information (cliams: identity, attributes of the user)?