Comparing all DataBound Controls

ListView GridView Repeater DataList Paging Support Yes Yes No No Flexible Layout Yes No (only tabular layout possible) Yes No (Layout uses tables) Editing support Yes Yes No Yes Insertion support Yes No No No

Stepping Up 2008

You know you’ve got the skills to do the job, but how do you convince potential customers and employers?

To broaden the vision of the career-minded professional in you, we have arranged a seminar on: - Planning better careers in IT - Getting the most out of potential customers and employers - New Generation Certifications and how to get the most out of them - Increased service excellence as the driver of IT policy - Attend the in-person seminar by industry leaders and experts! Get answers to the questions you have always wanted to ask.       MARK YOUR CALENDAR AND REGISTER NOW  FOR FREE!   Click at your city - Mumbai Bangalore Hyderabad     Chennai Delhi

WSE 2.0 Vs WSE 3.0

This is probably one of the main concerns for people involved in the development of web services using WSE.
Unfortunately, WSE 3.0 was designed from the beginning to be compatible at wire level with Indigo and therefore it doesn't interoperate well with WSE 2.0.
To be clear, "Wire compatible" means equivalent messages.
I wrote this post to provide some necessary points to obtain interoperability between both versions.

WS-Security xx specs

At this moment, there are two available versions of this specification, 1.0 and 1.1 (Also called WS-Security extensions).
WSE 2.0 only implements the first version whereas WSE 3.0 uses features of both versions (such as signature confirmation and key derivation).
Both endpoints, the client and the server should use features provided only by WS-Security 1.0.

Secure conversation

Secure Conversation is a special feature provided by WSE, in which client and server negotiate a session token to protect the communication for a specific period of time. This feature decrease the response time because the token negotiation happens once compared to other turn-key scenarios where the negotiation is done for each message. (This feature is really important when the client and the server interchange many messages during a period of time).
The SecureContext token used in WSE 3.0 is not compatible with WSE 2.0 since it was modified to support new features like "Stateful secure context tokens".

WS-Addressing xx specs

WSE 3.0 uses a newer version of this specification (The same as Indigo) and therefore the messages produced by both versions are not compatible.
There is not a good way to fix this problem, but probably a SoapFilter to update the addressing headers can be a solution.

Algorithm suite

WSE 3.0 uses by default the same algorithm suite as Indigo, AES256 for symmetric encryption and RSA-OAEP for key wrap. On the other hand, WSE 2.0 uses AES128 and RSA-15.
You will have to update the configuration settings in both endpoints in order to use the same algorithm suite.

Using the same algorithm suitein WSE 2.0 and WSE 3.0

Default algorithms in WSE 3.0

WSE 2.0 and 3.0, both provide AES128 + RSA 1.5 as default algorithms for symmetric encryption and key-wrap.
However, AES256 + RSA-OAEP are always recommended for these purposes, and Indigo will ship with that combination as default.

In WSE 2.0, these algorithms could be changed adding some settings in the configuration file:

<microsoft.web.services2>
...
  <security>
  ....
    <binarySecurityTokenManager
      valueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3">
      <sessionKeyAlgorithm name="TripleDES"/>   <!-- add this to switch to TripleDes from default AES128 -->
      <keyAlgorithm name="RSAOAEP"/>  <!-- add this to switch to RSA-OEAP from default RSA15 -->
    </binarySecurityTokenManager>
  </securityç>
...
<microsoft.web.services2>

These settings don't affect in the same way to WSE 3.0 because it implements some changes in the code used to secure messages. The security assertions
shipped within WSE 3.0 use different tokens to secure messages, they don't use an X509 security token anymore, instead they use derived tokens.

EncryptedToken: Usually, this token is used by the security assertions to sign and encrypt messages.

DerivedKeyToken: Only used when the flag "DeriveKeys" is on.

SecureContextToken: Only used in secure conversations. (When the flag "establishSecurityContext" is on)

The following configuration shows how to override the default algorithm used by these tokens:

<microsoft.web.services3>
  <security>
<binarySecurityTokenManager>
  <add
    type="Microsoft.Web.Services3.Security.Tokens.X509SecurityTokenManager, Microsoft.Web.Services3, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"
   valueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3">
    <keyAlgorithm name="RSAOAEP"/>
  </add>
</binarySecurityTokenManager>
<securityTokenManager>
  <add localName="EncryptedKey"
   type="Microsoft.Web.Services3.Security.Tokens.EncryptedKeyTokenManager, Microsoft.Web.Services3, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"
    namespace="http://www.w3.org/2001/04/xmlenc#">
    <keyAlgorithm name="AES256"/>
  </add>
  <add localName="DerivedKeyToken">
    type="Microsoft.Web.Services3.Security.Tokens.DerivedKeyTokenManager, Microsoft.Web.Services3, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"
    namespace="http://schemas.xmlsoap.org/ws/2005/02/sc">
    <keyAlgorithm name="AES256"/>
  </add>
  <add localName="SecurityContextToken"
    type="Microsoft.Web.Services3.Security.Tokens.SecurityContextTokenManager, Microsoft.Web.Services3, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"
    namespace="http://schemas.xmlsoap.org/ws/2005/02/sc">
    <keyAlgorithm name="AES256"/>
  </add>
</securityTokenManager>
</security>
</microsoft.web.services3>

Securing Web Services using WSE 3.0

Links

• patterns & practices
• Web Services Security
• Web Services Security QuickStarts
• Web Services Security Community Workspace
• Slides from this webcast

If you liked this episode check out these...

• ARCast - Securing Web Services with Kerberos Tokens in WSE 3.0 (Part 2)
• ARCast - Securing Web Services with X.509 Certificates in WSE 3.0 (Part 1)
• ARCast - Securing Web Services with X.509 Certificates in WSE 3.0 (Part 2)
• ARCast - Web Services Security Patterns Post Game Show
• ARCast - Web Services Security Patterns (Part 1)
• ARCast - Web Services Security Patterns (Part 2)

Securing Web Services with WSE 2.0

Requiring UsernameTokens
Authentication and Authorization
Implementing a UsernameTokenManager
Requiring Signatures
Using DerivedKeyTokens
Requiring Encryption
Signing and Encrypting with X.509 Tokens
Automating Security with Policy
Note on the UsernameTokenManager
Where Are We?

Read the article for complete view : http://msdn.microsoft.com/msdnmag/issues/04/10/ServiceStation/

Debug classic ASP code in Visual Studio 2005

Go to Debug > Attach to Process ...

Select dllhost.exe and click Select... button. Select "Script" checkbox from the dialogue box.

Click OK and ultimately click Attach.

NOTE: Debugging will not work unless your IIS is enabled for .asp debugging. To do that go to your IIS > Home Directory > Configuration > Debugging and check both checkboxes (Enable ASP server-side debugging and Enable ASP client-side debugging)