AppliesTo support for STSClient (previously WSTrustClient)

[beve]

Hi guys,

I noticed that there is server-side support for the AppliesTo element but I could not find this in the client. Is this intentional?

For the STSClient you only have the ability to specify a tokenType and it might be nice to have both options?
Perhaps there could be somethings like this:

public Element issueTokenForEndpoint(final String endpointURI) throws WSTrustException
{
 RequestSecurityToken request = new RequestSecurityToken();
 request.setAppliesTo(WSTrustUtil.createAppliesTo(endpointURI));
 return issueToken(request);
}

What do you think? Can I add this?

Thanks,

/Daniel

[sguilhen]

Hi Daniel,

yes, I totally agree with you here. AppliesTo is an important bit of the WS-T spec and the STS supports it, so there is no reason at all for this to be missing in the client side.

As a matter of fact, AppliesTo is a lot more important than specifying the token type, as it identifies the target endpoint and this allows the STS to perform very important work, like encrypting proof keys using the target's public key - something not possible when the target endpoint is unknown.

[beve]

Hi Stefan,

great, then I'll go ahead and add this :)

When reading the WS-Trust spec I noticed that TokenType and AppliesTo are option but one of them 'SHOULD' be specified and this is also verified by the StandardRequestHandler.
How about having the ability to specify both though, would this be a valid option for a client?

One example is for the ESB where we have an action that can be configured with either a TokenType or an EndpointURI. We will need to check that one or the other has been specified and then call the appropriate method. But if there was a method like the following no checks would be needed and it would only be one method call:

public Element issueToken(String endpointURI, String tokenType) throws WSTrustException
{
 if (endpointURI == null && tokenType == null)
 {
 throw new WSTrustException("Either endpointURI or tokenType must be specified");
 }
 RequestSecurityToken request = new RequestSecurityToken();
 setAppliesTo(endpointURI, request);
 setTokenType(tokenType, request);
 return issueToken(request);
}

What do you think, is it worth adding such a convenience method?

Thanks,

/Daniel

[sguilhen]

Hi Daniel,

IIRC, the spec doesn't say that 'ONLY ONE' of them should be specified, so I think we can safely have both the token type and AppliesTo in the request. :)

I'll revisit the request handler code to make sure that AppliesTo is parsed even when the token type is specified. Right now I think that AppliesTo is only parsed if the token type is absent, which is not good since we end up losing important information.

Regarding adding a new method, I don't have anything against it. As a matter of fact, this can be a good thing. Although the very same check is performed in the STS, a client-side validation can prevent us from spending time to create, marshall, and dispatch a request that will fail anyway.

[beve]

Hi Stefan,

IIRC, the spec doesn't say that 'ONLY ONE' of them should be specified, so I think we can safely have both the token type and AppliesTo in the request. :)

You are right. The spec says:

TokenType
If this optional element is not specified in an issue request, it is RECOMMENDED that the optional element <wsp:AppliesTo> be used to indicate the target where this token will be used. That is, either the <wst:TokenType> or the <wsp:AppliesTo> element SHOULD be defined within a request. If both the <wst:TokenType> and <wsp:AppliesTo> elements are defined, the <wsp:AppliesTo> element takes precedence (for the current request only) in case the target scope requires a specific type of token.

I understand this as to mean that a RequestSecurityToken can be valid without a TokenType or an AppliesTo specified.
I'm not sure how that would work and how the lookup of the service provider and token provider could be done with one or the other. Perhaps 'SHOULD' in this case is more strict then I'm interpreting it?

Regarding adding a new method, I don't have anything against it. As a matter of fact, this can be a good thing. Although the very same check is performed in the STS, a client-side validation can prevent us from spending time to create, marshall, and dispatch a request that will fail anyway.

I agree. I'll add this.

Thanks,

/Daniel

[sguilhen]

Hi Daniel,

I understand this as to mean that a RequestSecurityToken can be valid without a TokenType or an AppliesTo specified.
I'm not sure how that would work and how the lookup of the service provider and token provider could be done with one or the other. Perhaps 'SHOULD' in this case is more strict then I'm interpreting it?

No, I think you are interpreting it correctly, otherwise they would have used the word 'MUST'. I interpret the 'SHOULD' as something highly advisable and as such I believe we can require one of the types to be specified in WS-T requests simply because we don't have any other way to find out what token provider should be used to handle the request.

We could use a default provider (specified in the WS-T configuration file) but I don't think this is a good idea because a default provider could cover a potential client-side error. In other words, the client app could be expecting an exception to be thrown if the user forgets to specify the token type or target endpoint but instead gets a 'default' token from the STS.

It is good that you've copied that section of the spec here because it reminded me that AppliesTo has precedence over TokenType and right now the STS doesn't follow this rule. I'll open a Jira and fix this.

[sguilhen]

Actually, the STS respects AppliesTo precedence, so no fix is needed.

[beve]

Hi Stefan,

We could use a default provider (specified in the WS-T configuration file) but I don't think this is a good idea because a default provider could cover a potential client-side error. In other words, the client app could be expecting an exception to be thrown if the user forgets to specify the token type or target endpoint but instead gets a 'default' token from the STS.

This makes perfect sense. Thanks for clearing this up.

Actually, the STS respects AppliesTo precedence, so no fix is needed.

Great :)

Thanks,

/Daniel