RE: Encryption and signing using Security context tokens using WS

From: kiran & Dev (kiranDev_at_discussions.microsoft.com)
Date: 03/15/05 

Date: Tue, 15 Mar 2005 01:29:02 -0800

Thanks Thomas

Yes it is a failure to map to a specific policy
In a webfarm scenario wen i try to run the sample using policy the error is
-------------------------------------
Message: WSE464: No policy could be found for this message.
   at
Microsoft.Web.Services2.Policy.SimplePolicyEnforcer.Enforce(SoapEnvelope m
essage)
   at Microsoft.Web.Services2.Policy.PolicyManager.Enforce(SoapEnvelope
message)

   at
Microsoft.Web.Services2.Policy.PolicyEnforcementOutputFilter.ProcessMessag
e(SoapEnvelope envelope)
   at Microsoft.Web.Services2.Pipeline.ProcessOutputMessage(SoapEnvelope
envelop
e)
   at Microsoft.Web.Services2.OutputStream.Close()
   at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String
methodN
ame, Object[] parameters)
   at SecureConvClient.StockServiceWse.StockQuoteRequest(String[] symbols)
in c:
\program files\microsoft
wse\v2.0\samples\cs\quickstart\secureconvcodeclient\sec
ureconvproxy.cs:line 41

-------------------------

we are using the same concept as Chris Keyser for Managing Security Context
Tokens in a Web Farm.The built-in SecurityContextService keeps track of the
SCTs that it has issued are kept in a database and retrieved.And also we have
x509 certificates installed in both the servers.

http://msdn.microsoft.com/webservices/default.aspx?pull=/library/en-us/dnwebsrv/html/sctinfarm.asp

This works fine for code in webfarm environment.

My policy file at the client side looks like this .
---------------------------------------------
<?xml version="1.0" encoding="utf-8"?>
<!--
This sample is designed to demonstrate WSE features and is not intended
for production use. Code and policy for a production application must be
developed to meet the specific data and security requirements of the
application.
 -->
<policyDocument xmlns="http://schemas.microsoft.com/wse/2003/06/Policy">
  <mappings>
    <!--
        The following section describes the policy requirements for the
        sample service. Note that the fault policy is empty.
        This indicates that no policy is applied to faults for this service
operation.
        -->
//This is the point where to get the SCT service.
   <endpoint
uri="http://server1/SecureConvCodeService/SecureConvService.asmx">
      <defaultOperation>
        <request policy="#Sign-SCT-Encrypt-SCT" />
        <response policy="" />
        <fault policy="" />
      </defaultOperation>
      <operation
requestAction="http://schemas.xmlsoap.org/ws/2004/04/security/trust/RST/SCT">
        <request policy="" />
        <response policy="" />
        <fault policy="" />
      </operation>
    </endpoint>
  </mappings>
  <policies xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing"
xmlns:wse="http://schemas.microsoft.com/wse/2003/06/Policy"
xmlns:wsp="http://schemas.xmlsoap.org/ws/2002/12/policy"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
xmlns:wssp="http://schemas.xmlsoap.org/ws/2002/12/secext"
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
    <!--
        This policy is used for the target Web service. It requires
        the body and addressing headers to be signed with the
        SecureContextToken and the body to be encrypted with token.
        -->
    <!--
        This policy is used for the token issuer service. It requires
        the body and addressing headers to be signed with a
        UsernameToken.
        -->
    <wsp:Policy wsu:Id="Sign-SCT-Encrypt-SCT">
      <!--MessagePredicate is used to require headers. This assertion should
be used along with the Integrity assertion when the presence of the signed
element is required. NOTE: this assertion does not do anything for
enforcement (send-side) policy.-->
      <wsp:MessagePredicate wsp:Usage="wsp:Required"
Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">wsp:Body()
wsp:Header(wsa:To) wsp:Header(wsa:Action) wsp:Header(wsa:MessageID)
wse:Timestamp()</wsp:MessagePredicate>
      <!--The Integrity assertion is used to ensure that the message is
signed with SCT. Many Web services will also use the token for authorization,
such as by using the <wse:Role> claim or specific SCT claims.-->
      <wssp:Integrity wsp:Usage="wsp:Required">
        <wssp:TokenInfo>
          <!--The SecurityToken element within the TokenInfo element
describes which token type must be used for Signing.-->
          <wssp:SecurityToken>
            
<wssp:TokenType>http://schemas.xmlsoap.org/ws/2004/04/security/sc/sct>
            <wssp:Claims>
              <wse:BaseToken>
                <wssp:SecurityToken>
                  
<wssp:TokenType>http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#UsernameToken>
                </wssp:SecurityToken>
              </wse:BaseToken>
              <wse:IssuerToken>
                <wssp:SecurityToken>
                  
<wssp:TokenType>http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3>
                  <wssp:TokenIssuer>DC=com, DC=everest,
CN=EverestCsr</wssp:TokenIssuer>
                  <wssp:Claims>
                    <!--By specifying the SubjectName claim, the policy
system can look for a certificate with this subject name in the certificate
store indicated in the application's configuration, such as LocalMachine or
CurrentUser. The WSE X.509 Certificate Tool is useful for finding the correct
values for this field.-->
                    <wssp:SubjectName MatchType="wssp:Exact">DC=com,
DC=everest, CN=Users, CN=Administrator</wssp:SubjectName>
                    <wssp:X509Extension OID="2.5.29.14"
MatchType="wssp:Exact">0Ue6rBPQiujm0dbW4HptwVcym8w=</wssp:X509Extension>
                  </wssp:Claims>
                </wssp:SecurityToken>
              </wse:IssuerToken>
            </wssp:Claims>
          </wssp:SecurityToken>
        </wssp:TokenInfo>
        <wssp:MessageParts
Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">wsp:Body()
wsp:Header(wsa:Action) wsp:Header(wsa:FaultTo) wsp:Header(wsa:From)
wsp:Header(wsa:MessageID) wsp:Header(wsa:RelatesTo) wsp:Header(wsa:ReplyTo)
wsp:Header(wsa:To) wse:Timestamp()</wssp:MessageParts>
      </wssp:Integrity>
      <!--The Confidentiality assertion is used to ensure that the SOAP Body
is encrypted.-->
      <wssp:Confidentiality wsp:Usage="wsp:Required">
        <wssp:KeyInfo>
          <!--The SecurityToken element within the KeyInfo element describes
which token type must be used for Encryption.-->
          <wssp:SecurityToken>
            
<wssp:TokenType>http://schemas.xmlsoap.org/ws/2004/04/security/sc/sct>
            <wssp:Claims>
              <wse:BaseToken>
                <wssp:SecurityToken>
                  
<wssp:TokenType>http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#UsernameToken>
                </wssp:SecurityToken>
              </wse:BaseToken>
              <wse:IssuerToken>
                <wssp:SecurityToken>
                  
<wssp:TokenType>http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3>
                  <wssp:TokenIssuer>DC=com, DC=everest,
CN=EverestCsr</wssp:TokenIssuer>
                  <wssp:Claims>
                    <!--By specifying the SubjectName claim, the policy
system can look for a certificate with this subject name in the certificate
store indicated in the application's configuration, such as LocalMachine or
CurrentUser. The WSE X.509 Certificate Tool is useful for finding the correct
values for this field.-->
                    <wssp:SubjectName MatchType="wssp:Exact">DC=com,
DC=everest, CN=Users, CN=Administrator</wssp:SubjectName>
                    <wssp:X509Extension OID="2.5.29.14"
MatchType="wssp:Exact">0Ue6rBPQiujm0dbW4HptwVcym8w=</wssp:X509Extension>
                  </wssp:Claims>
                </wssp:SecurityToken>
              </wse:IssuerToken>
            </wssp:Claims>
          </wssp:SecurityToken>
        </wssp:KeyInfo>
        <wssp:MessageParts
Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">wsp:Body()</wssp:MessageParts>
      </wssp:Confidentiality>
    </wsp:Policy>
  </policies>
</policyDocument>
---------------------------------
and my Web.config at the issuer token side looks like this

<?xml version="1.0" encoding="utf-8"?>
<configuration>

  <configSections>
    <section name="microsoft.web.services2"
type="Microsoft.Web.Services2.Configuration.WebServicesConfiguration,
Microsoft.Web.Services2, Version=2.0.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35" />
  </configSections>

  <system.web>
    <webServices>
      <soapExtensionTypes>
        <add type="Microsoft.Web.Services2.WebServicesExtension,
Microsoft.Web.Services2, Version=2.0.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35" priority="1" group="0" />
      </soapExtensionTypes>
    </webServices>
     <!-- DYNAMIC DEBUG COMPILATION
          Set compilation debug="true" to enable ASPX debugging. Otherwise,
setting this value to
          false will improve runtime performance of this application.
          Set compilation debug="true" to insert debugging symbols (.pdb
information)
          into the compiled page. Because this creates a larger file that
executes
          more slowly, you should set this value to true only when debugging
and to
          false at all other times. For more information, refer to the
documentation about
          debugging ASP .NET files.
    -->
    <compilation
         defaultLanguage="c#"
         debug="true"
    />
    
   <!-- <identity impersonate="true" userName="VISUALSOFT-TECH\davindersing"
password="dev1" /> -->
  </system.web>

  <microsoft.web.services2>
    <diagnostics>
        <!--
                Configures the error reporting facility.

                The "enabled" attribute is required for the <detailedErrors>
element, and its default value is false.

                If the enabled attribute is set to true explicitly, WSE will
send back the detailed error information,
                i.e. a full stack trace as well as the information about all
the inner exceptions. If the enabled
                attribute is set to false explicitly, WSE will send back the
custom (friendly) messages, i.e. the top
                level exception message without stack trace and information
about the inner exceptions.

                The detailedErrors section is optional. If it is not
present, for http or https request, the customErrors
                under the system.web section will be used to decide whether
WSE will send back the custom (friendly) message.
                Please refer to the ASP.NET configruation section for
further information. For all the other transports, WSE
                will always send back the custom (friendly) message.
          -->
         <detailedErrors enabled="true" />
         <trace enabled="true"/>
    </diagnostics>
    <security>
      <x509 allowTestRoot="true" allowRevocationUrlRetrieval="false"
verifyTrust="false" />
      <securityTokenManager
type="SecureConvCodeService.CustomUsernameTokenManager,
SecureConvCodeService"
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" qname="wsse:UsernameToken" >
      <replayDetection enabled="false"/>
          </securityTokenManager>

        <!--!!!!!**********
            You should follow best practices for managing sensitive configuraiton
information
           like connection strings and keys in a production environment. Located
here:
           
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/SecNetch08.asp
           and here:
           
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/SecNetch12.asp -->
          
          <securityTokenManager type="SecureConvCodeService.CookieSCTManager,
SecureConvCodeService" xmlns:wssc="http://schemas.xmlsoap.org/ws/2004/04/sc"
qname="wssc:SecurityContextToken">
                <secretKey>9zgyMgCz8K631HYRV+Qj+Q==</secretKey>
           <!--<secretKey>zw04MvaqVuxbhXi7mgJE2QTofmY=</secretKey>-->
            </securityTokenManager>
            
          <securityTokenManager type="SecureConvCodeService.DatabaseSCTManager,
SecureConvCodeService" xmlns:wssc="http://schemas.xmlsoap.org/ws/2004/04/sc"
qname="wssc:SecurityContextToken">
                  <connectionString>
                          Integrated Security=False;database=TokenCache;server=192.168.200.10;
User Id=foo;password=bar;
                </connectionString>
            </securityTokenManager>
   </security>

    <tokenIssuer>
      <!--required for WSE SP1 - will be fixed in subsequent release and
then commented out
          config should be used -->
                  <!-- <autoIssueSecurityContextToken enabled="true"
type="SecureConvCodeService.DistributedCacheSCTService,
SecureConvCodeService" /> -->
 <autoIssueSecurityContextToken enabled="true" />
      <serverToken>
        <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#"
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
          <wsse:SecurityTokenReference>
            <!-- Replace the identifier below with your own certificate Id
in Base64String here
                 The certificate is from the Local Machine store's Personal
folder, and the certificate
                 Id can be retrieved by X509Certificate Tool
                      -->
            <wsse:KeyIdentifier
ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509SubjectKeyIdentifier">0Ue6rBPQiujm0dbW4HptwVcym8w=</wsse:KeyIdentifier>
          </wsse:SecurityTokenReference>
        </KeyInfo>
      </serverToken>
    </tokenIssuer>
      <policy>
      <cache name="policyCache.config" />
    </policy>
  </microsoft.web.services2>
</configuration>
------------------------------------------------

My service side and issuer token policy file looks like this

<?xml version="1.0" encoding="utf-8"?>
<!--
This sample is designed to demonstrate WSE features and is not intended
for production use. Code and policy for a production application must be
developed to meet the specific data and security requirements of the
application.
 -->
<policyDocument xmlns="http://schemas.microsoft.com/wse/2003/06/Policy">
  <mappings>
    <!--
        The following section describes the policy requirements for the
        sample service. Note that the fault policy is empty.
        This indicates that no policy is applied to faults for this service
operation.
        -->
    <endpoint
uri="http://server2/SecureConvCodeService/SecureConvService.asmx">
      <defaultOperation>
        <request policy="#Sign-SCT-Encrypt-SCT" />
        <response policy="" />
        <fault policy="" />
      </defaultOperation>
      <operation
requestAction="http://schemas.xmlsoap.org/ws/2004/04/security/trust/RST/SCT">
        <request policy="" />
        <response policy="" />
        <fault policy="" />
      </operation>
    </endpoint>
  </mappings>
  <policies xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing"
xmlns:wse="http://schemas.microsoft.com/wse/2003/06/Policy"
xmlns:wsp="http://schemas.xmlsoap.org/ws/2002/12/policy"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
xmlns:wssp="http://schemas.xmlsoap.org/ws/2002/12/secext"
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
    <!--
        This policy is used for the target Web service. It requires
        the body and addressing headers to be signed with the
        SecureContextToken and the body to be encrypted with token.
        -->
    <!--
        This policy is used for the token issuer service. It requires
        the body and addressing headers to be signed with a
        UsernameToken.
        -->
    <wsp:Policy wsu:Id="Sign-SCT-Encrypt-SCT">
      <!--MessagePredicate is used to require headers. This assertion should
be used along with the Integrity assertion when the presence of the signed
element is required. NOTE: this assertion does not do anything for
enforcement (send-side) policy.-->
      <wsp:MessagePredicate wsp:Usage="wsp:Required"
Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">wsp:Body()
wsp:Header(wsa:To) wsp:Header(wsa:Action) wsp:Header(wsa:MessageID)
wse:Timestamp()</wsp:MessagePredicate>
      <!--The Integrity assertion is used to ensure that the message is
signed with SCT. Many Web services will also use the token for authorization,
such as by using the <wse:Role> claim or specific SCT claims.-->
      <wssp:Integrity wsp:Usage="wsp:Required">
        <wssp:TokenInfo>
          <!--The SecurityToken element within the TokenInfo element
describes which token type must be used for Signing.-->
          <wssp:SecurityToken>
            
<wssp:TokenType>http://schemas.xmlsoap.org/ws/2004/04/security/sc/sct>
            <wssp:Claims>
              <wse:BaseToken>
                <wssp:SecurityToken>
                  
<wssp:TokenType>http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#UsernameToken>
                </wssp:SecurityToken>
              </wse:BaseToken>
              <wse:IssuerToken>
                <wssp:SecurityToken>
                  
<wssp:TokenType>http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3>
                  <wssp:TokenIssuer>DC=com, DC=everest,
CN=EverestCsr</wssp:TokenIssuer>
                  <wssp:Claims>
                    <!--By specifying the SubjectName claim, the policy
system can look for a certificate with this subject name in the certificate
store indicated in the application's configuration, such as LocalMachine or
CurrentUser. The WSE X.509 Certificate Tool is useful for finding the correct
values for this field.-->
                    <wssp:SubjectName MatchType="wssp:Exact">DC=com,
DC=everest, CN=Users, CN=Administrator</wssp:SubjectName>
                    <wssp:X509Extension OID="2.5.29.14"
MatchType="wssp:Exact">0Ue6rBPQiujm0dbW4HptwVcym8w=</wssp:X509Extension>
                  </wssp:Claims>
                </wssp:SecurityToken>
              </wse:IssuerToken>
            </wssp:Claims>
          </wssp:SecurityToken>
        </wssp:TokenInfo>
        <wssp:MessageParts
Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">wsp:Body()
wsp:Header(wsa:Action) wsp:Header(wsa:FaultTo) wsp:Header(wsa:From)
wsp:Header(wsa:MessageID) wsp:Header(wsa:RelatesTo) wsp:Header(wsa:ReplyTo)
wsp:Header(wsa:To) wse:Timestamp()</wssp:MessageParts>
      </wssp:Integrity>
      <!--The Confidentiality assertion is used to ensure that the SOAP Body
is encrypted.-->
      <wssp:Confidentiality wsp:Usage="wsp:Required">
        <wssp:KeyInfo>
          <!--The SecurityToken element within the KeyInfo element describes
which token type must be used for Encryption.-->
          <wssp:SecurityToken>
            
<wssp:TokenType>http://schemas.xmlsoap.org/ws/2004/04/security/sc/sct>
            <wssp:Claims>
              <wse:BaseToken>
                <wssp:SecurityToken>
                  
<wssp:TokenType>http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#UsernameToken>
                </wssp:SecurityToken>
              </wse:BaseToken>
              <wse:IssuerToken>
                <wssp:SecurityToken>
                  
<wssp:TokenType>http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3>
                  <wssp:TokenIssuer>DC=com, DC=everest,
CN=EverestCsr</wssp:TokenIssuer>
                  <wssp:Claims>
                    <!--By specifying the SubjectName claim, the policy
system can look for a certificate with this subject name in the certificate
store indicated in the application's configuration, such as LocalMachine or
CurrentUser. The WSE X.509 Certificate Tool is useful for finding the correct
values for this field.-->
                    <wssp:SubjectName MatchType="wssp:Exact">DC=com,
DC=everest, CN=Users, CN=Administrator</wssp:SubjectName>
                    <wssp:X509Extension OID="2.5.29.14"
MatchType="wssp:Exact">0Ue6rBPQiujm0dbW4HptwVcym8w=</wssp:X509Extension>
                  </wssp:Claims>
                </wssp:SecurityToken>
              </wse:IssuerToken>
            </wssp:Claims>
          </wssp:SecurityToken>
        </wssp:KeyInfo>
        <wssp:MessageParts
Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">wsp:Body()</wssp:MessageParts>
      </wssp:Confidentiality>
    </wsp:Policy>
  </policies>
</policyDocument>

-------------------------------

Do i have to include policy file at the
Target service and token issuer service end ? and also can u specify what i
have to include in the <endpoint uri> in policy cache. And also at the
service end the <autoIssueSecurityContextToken enabled="false" />
is that correct?

Hope you understand my problem .

With Many Thanks
Kiran

"Thomas S. Trias" wrote:

> What is the specific failure message? Is it a policy failure regarding the
> encryption / signature token, or is it a failure to map to a specific policy?
>
> I can see where you might have some difficulty setting up SCT mediated
> communication in a web-farm environment if the load-balancer doesn't
> associate a particular client session (identifiable in this case only by the
> SCT / issuer, unless you also use an additional mechanism) with a particular
> server in the farm.
>
> The built-in SecurityContextService only keeps track of the SCTs that it has
> issued; it doesn't know about the other servers in the farm. So, once a
> client has acquired an SCT from a particular server, it either has to be tied
> to that server for the conversation's lifetime, or you have to devise a
> mechanism whereby the servers in the farm share an SCT cache or can query
> each other to validate the SCT. Either of those options requires setting up
> a custom SecurityContextService.
>
> Do you have x509 certificates setup for the servers? Does each server know
> about the public keys for each of the other servers? As long as the servers
> can engage in trusted behavior amongst themselves, you can setup another
> web-service for SCT cache coherency, with operations for querying (pull),
> copying (push), and revocation of SCTs from the caches of the web-farm
> servers.
>
> One thing I'm not clear on is the best way to seamlessly integrate a custom
> SecurityContextService that responds to the standard SCT request (SoapAction
> = "http://schemas.xmlsoap.org/ws/2004/04/security/trust/RST/SCT") on the same
> URI as the main service (e. g. "http://mydomain/myservice.asmx"), without
> getting in the way of the rest of the requests. All of the examples I've
> seen regarding SecurityContextService are focused on handling custom tokens
> with a specific endpoint just for token management. Using a specific
> endpoint for token management may not be the worst solution; it depends upon
> how much control you have over the web service consumers / proxies.
>
> Thomas S. Trias
> Senior Developer
> Afni Insurance Services
> http://www.afniinc.com/
>
> "kiran & Dev" wrote:
>
> > Thanks Thomas ,
> >
> > yes issuing SCT works , but in a webfarm scenario calling service fails
> > using WS- Policy, any suggestions fully appreciated.....
> >
> >
> > with many thnks
> > kiran
>

Relevant Pages

  • RE: Encryption and signing using Security context tokens using WS
    ... Is it a policy failure regarding the ... SCT / issuer, unless you also use an additional mechanism) with a particular ... it doesn't know about the other servers in the farm. ... seen regarding SecurityContextService are focused on handling custom tokens ...
    (microsoft.public.dotnet.framework.webservices.enhancements)
  • Problem in securing webmethod Wse 2.0 sp3
    ... I am trying to implement webservice security, with x509 tokens, ... By signing the message with x509 tokens and encrypting them, ... I am attaching the policy files for u'r ref. ... certificate store indicated in the application's configuration, ...
    (microsoft.public.dotnet.framework.webservices.enhancements)
  • Re: Overriding X509SecurityTokenManager.AuthenticateToken
    ... Authenticate method should just be validating that the certificate it receives ... with the tokens on its way in like, may be add an identity to the token etc.. ... I'd suggest take a look at how you can restrict uses based on policy first. ...
    (microsoft.public.dotnet.framework.webservices.enhancements)
  • Re: Overriding X509SecurityTokenManager.AuthenticateToken
    ... I don't believe I can use a policy. ... service if they have a certificate issued by us. ... > with the tokens on its way in like, may be add an identity to the token etc.. ... > and throw the security fault in the filter. ...
    (microsoft.public.dotnet.framework.webservices.enhancements)
  • Re: Overriding X509SecurityTokenManager.AuthenticateToken
    ... Lookup in the policy configuration reference IssuerToken. ... > our web service if they have a certificate issued by us. ... >> with the tokens on its way in like, may be add an identity to the ... >> manager you're short circuiting the whole authentication process. ...
    (microsoft.public.dotnet.framework.webservices.enhancements)