Skip to main content

Security Token Configuration in Metro Contd....

Posted by kumarjayanti on July 8, 2009 at 1:17 AM PDT

My previous post Security Token Configuration in Metro has exceeded the maximum limits (even after having used the extended entry) of a post and hence when i added some more details yesterday, i am seeing that the tail end of my post was truncated. So here is what was in the tail end...


    Here is  the complete abstract schema for CallbackHandlerConfiguration and ValidatorConfiguration elements in Metro. I decided to paste the complete configuration here because for these two elements the configuration has been shown in bits and pieces under different tokens (as relevant).

<sc:CallbackHandlerConfiguration wspp:visibility="private" xmlns:sc="{server  or client}"

        timestampTimeout="{Timeout value in Second(s) : This value is used to compute the Expiry time of the WSU:Timestamp being sent in the message, value specified should be greater than zero}"

        useXWSSCallbacks="{Value true indicates use XWSS Callbacks in place of Standard J2SE callbacks for Non-109 App. For 109 Apps a value true indicates passing RuntimePropertiesCallback as an Extra Callback to CallbackHandler}" >

       <sc:CallbackHandler  name="usernameHandler" classname="{a callbackhandler classname that handles}"

        default="{the default username value as a string, to be provided incase classname is  not provided}" />

       <sc:CallbackHandler  name="passwordHandler"  classname="{a callbackhandler  classname that handles}"

        default="{the default password value as a string, to be provided incase classname

        is not provided}"  />

       <sc:CallbackHandler  name="samlHandler"  classname="{a callbackhandler  classname that  handles com.sun.xml.wss.impl.callback.SAMLCallback}"/>

       <sc:CallbackHandler  name="jmacCallbackHandler" classname="{a callbackhandler  classname that  handles all the Standard JSR 196 Callbacks}" />

       <sc:CallbackHandler  name="xwssCallbackHandler"  classname="{a callbackhandler  classname that  handles all the XWSS Callbacks}" />


   <sc:ValidatorConfiguration wspp:visibility="private" xmlns:sc="{server  or client}"

sc:maxClockSkew="{The assumed maximum skew (milliseconds) between the local times of any two systems, runtime defaults used when not specified}"

sc:timestampFreshnessLimit="{The period (milliseconds) for which a Timestamp is considered fresh, runtime defaults used when not specified }

sc:maxNonceAge="{The length of time (milliseconds) a previously received Nonce value in a UsernameToken will be stored, runtime defaults used when not specified}"

sc:revocationEnabled="{If this flag is true, the default certificate revocation checking mechanism of the underlying PKIX service provider will be used. If this flag is false, the default revocation checking mechanism will be disabled (not used).}">

<sc:Validator name= "usernameValidator"  classname={class name of a usernameToken Validator,

    should implement com.sun.xml.wss.impl.callback.PasswordValidationCallback.PasswordValidator }/>

    <sc:Validator  name="timestampValidator" classname ={class name of a Timestamp Validator,

    should implement com.sun.xml.wss.impl.callback.TimestampValidationCallback.TimestampValidator,  a default Timestamp validator from Metro runtime used when not supplied} />

    <sc:Validator  name="certificateValidator" classname ={class name of a certificate Validator,

    should implement com.sun.xml.wss.impl.callback.CertificateValidationCallback.CertificateValidator,

    default Certificate validator from XWSS runtime used when not supplied} />

<sc:Validator name="samlAssertionValidator" classname = {class name of a SAML Assertion Validator, should implement com.sun.xml.wss.impl.callback.SAMLAssertionValidator,

    Partial validation (in the form of verifying enveloped signature) occurs on SAML Assertion within  the WSIT/XWSS 3.0 Runtime even if the validator is not specified} /> ?


 How does Metro Pickup the Certificate to use for Response Encryption

With so many different ways of configuring things one might ask the question how does metro pickup the certificate for response encryption to the client.  So here are the abstract steps that metro uses in that order of preference :

1. if peeralias is specified then use it (not practical in real world apps since a service would have many clients)

2. if a certstore was specified then look for the cert in the certstore using the specified CertSelector

3. if a truststore CertSelector was specified use that to locate the cert

4. if the request contained a certificate use that certificate for the response

5. Pick the first one from the truststore (this was a legacy feature from early metro days and it would work well when your truststore has just one cert that of the client :-), you never need to configure anything then, there is a TODO comment to remove this piece of code and we don't expect metro users to use this option)

On step 4 metro currently has a limitation that only if the Certificate of the client appears as a Binary Security Token in the message then metro tries to use it for response encryption. However this can  be improved since even an indirect reference to the client certificate should also cause metro to make use that certificate for response encryption. The opportunity is rare though because usually the server never stores the certificates of its client inside it's certstore/truststores.


Related Topics >>