First Steps In Web Service Security

The notion of the Web Services framework and Services Oriented Architectures are gaining momentum as an approach to collaborative business systems by supporting the creation, deployment, and dynamic discovery of various channels of information. The Web Services evolution is made possible in part by the adaptation of universally accepted standard protocols, these include:

  • HTTP (Hyper Text Transfer Protocol)
  • XML (Extensible Markup Language)
  • SOAP (Simple Object Access Protocol)
  • WSDL (Web Services Description Language)
  • WSFL (Web Services Flow Language)
  • UDDI (Universal Description, Discovery and Integration)

These concepts are discussed more exhaustively in terms of protocol here.

What are the portions that are involved in Web Service security

  • Authentication – Determine the identity or role of a party attempting to perform some action such as accessing a resource or participating in a transaction. A role may be appropriate to many parties, for example “Human Resources Person”.
  • Authorization – Determine whether some party is allowed to perform a requested action, such as viewing a web page, changing a password, or committing an organization to a 10 million dollar transaction.
  • Integrity – Ensure that information is not changed, either due to malicious intent or by accident. This may be information transmitted over a network, such as from a web browser to a web server, information stored in a database or file system, or information passed in a web services message and processed by intermediaries, to give a few examples.
  • Signature – Produce or verify an electronic signature intended to be the equivalent of a handwritten signature. Such a signature may be used for different purposes such as approval, confirmation of receipt, acceptance or agreement.
  • Confidentiality – Ensure that content may only be viewed by legitimate parties, even if other access control mechanisms are bypassed. Confidentiality is generally associated with encryption technologies, although other approaches such as steganography (information hiding) might serve a similar purpose.
  • Privacy – Personally identifiable information is required by individuals and companies in order to perform services for the individual. An example is a Doctor’s office that requires medical records to track a patient’s health. Privacy relates to control over what is done with this information and whether it is redistributed to others without the individual’s knowledge or consent. Privacy may be managed by a combination of technical and legal means. Confidentiality technology may be used to protect privacy, but cannot prevent inappropriate sharing of information.
  • Digital Rights Management – Ensure that content is used according to license agreements. Generally access rules are incorporated with the content, and enforcement controls are integrated with the clients needed to use the content.

This in turn break down to the actual protocols involved:

  • XML Digital Client Signatures for LOB signing solutions
  • XML Encryption for confidentiality and verifiable integrity
  • XML Key Management (XKMS) for encryption key buckets
  • Security Assertion Markup Language (SAML) for conveying authentication and authorization
  • XML Access Control Markup Language (XACML) for defining ACL related information
  • Platform for Privacy Preferences (P3P) for defining privacy actions and associations
  • Digital Rights Management (eXtensible Rights Markup Language 2.0 – XrML)

XML Security standards provide a set of technical standards to meet security requirements. These standards are designed to conform to common XML paradigms. The XML Security standards leverage existing XML standards and also enhance XML standards as follows:

  1. The XML Security standards define XML vocabularies for representing security information, using XML technologies, such as XML Schema, for definition. An example is the element defined in the XML Digital Signature recommendation for carrying signing or encryption key information. This definition is used in a number of the specifications. The specifications define a shared meaning for the XML vocabularies.
  2. The XML Security standards use other existing XML standards where possible to leverage current XML efforts. For example, XML Digital Signature allows XPath expressions to extract portions of XML for processing. (Defined in XMLDigSig and extended in XPathFilter).
  3. The XML Security standards are designed to offer the flexibility and extensibility aspects of XML. They allow security to be applied to XML documents, to XML elements and element content, as well as to arbitrary binary documents. They support extending the XML vocabularies through the use of XML namespaces and extensible XML Schema definitions.
  4. XML Security technologies may be applied to end-end security, which is especially important when XML messages are routed through a number of processing intermediaries. Persistent security is associated with the content, rather than with a transport pipe. The security remains with the content. XML Security technologies may be used in conjunction with transport security technologies, such as SSL/TLS, as well.
  5. XML Security technologies reuse existing cryptographic and security technologies whenever possible, without reinventing the wheel. For example, X.509 V3 certificates [ X509Cert ] are used without redefinition when needed – they are simply encoded in a text format. Existing algorithms, such as the SHA1 digest algorithm, are also brought into the XML Security standards world by associating unique URI identifiers with them and defining how they may be used in the XML Security processing models.

Although there is a mixture of these protocols, it does not necessarily mean that these protocols have to be used in order for one to exist within a Service Oriented Architecture.

For example, SOAP is a protocol for remote procedure calling and messaging with XML-encoded application data. However, SOAP does not require the use of XML. In fact, SOAP supports remotely referenced data such as objects provided by third parties that are produced or consumed at separate hosts. SOAP also specifies various usage scenarios, such as one-way message passing, single and multiple request-response invocations, as well as routing.

It is also important to note the differences that exist in XML protocols and although it is a set amount of standards, there are vast types that exist. Most XML protocols that are going to be consumed across varying businesses are based on DTDs rather than XML schemas and lack XML namespace and extensibility properties that others may have. The expressiveness of these protocols is restricted to a set of pre-defined data types offered by the protocol. This is an important note to take when attempting to consume various types of web services into a SharePoint environment that may come from various sources.

The security of web services involves many other asepcts. With the growing acceptance of XML technologies for documents and protocols, it is logical that security should be integrated with XML solutions. The XML Security standards define XML vocabularies and processing rules in order to meet security requirements. These standards use legacy cryptographic and security technologies, as well as emerging XML technologies, to provide a flexible, extensible and practical solution toward meeting security requirements.

Share

Event Handling In InfoPath

Within the InfoPath 2007, there is the option to handle events using an item called the Event Manager. Similar to the event receiver architecture provided by other facilities of SharePoint, the Event Manager provides mechanisms by which forms can provide and respond to event capturing. Writing code that is consumed by the Event Manager is done using Visual Studio Tools for Application (VSTA), and when choosing to program events off the InfoPath design surface it will attempt to open the VSTA IDE.

The Event Manager is called from the InternalStartup() method, which controls the events that are registered when a form is initially loaded. Each event that should be captured can be registered within the InternalStartup() method and then delegates can be constructed to encapsulate a reference to a method which handles the events tripped custom code.

There are several events that can be captured and managed when leveraging the Event Manager.

Event Capturing Available Through the Event Manager

Event Type
Event Capture
Action
Delegate
Control Event OnClick When a user clicks a control in InfoPath ClickedEventHandler(object sender, Microsoft.Office.InfoPath.ClickedEventArgs e)
Form Event OnSaveRequest When a user saves an InfoPath Form SaveEventHandler(object sender, Microsoft.Office.InfoPath.SaveEventArgs e)
Form Event OnContextChange When a user changes a Form Context, such as when a form is submitted SubmitEventHandler(object sender, Microsoft.Office.InfoPath.SubmitEventArgs e)
Form Event OnSign When a user signs an InfoPath form with a digital signature SignEventHandler(object sender, Microsoft.Office.InfoPath.SignEventArgs e)
Form Event OnMergeRequest When a user merges a set of InfoPath forms (merge operation) MergeEventHandler(object sender, Microsoft.Office.InfoPath.MergeEventArgs e)
Form Event OnSwitchView When an InfoPath view is changed (switch view operation) ViewSwitchedEventHandler(object sender, Microsoft.Office.InfoPath.ViewSwitchedEventArgs e)
Xml Event OnBeforeChange Before a passed XPath node is changed, wire an XML event XmlChangedEventHandler(object sender, Microsoft.Office.InfoPath.XmlEventArgs e)
Xml Event OnValidate When an XPath node is being validated, wire an XML event XmlChangingEventHandler(object sender, Microsoft.Office.InfoPath.XmlChangingEventArgs e)
Xml Event OnAfterChange After an XPath node is changed, wire an XML event XmlValidatingEventHandler(object sender, Microsoft.Office.InfoPath.XmlValidatingEventArgs e)
Registering View Delegate in InternalStartup()

Using the InfoPath event handlers is as straight-forward as the event receiver/listener architecture that is present with SharePoint content types and list definitions. The event being captured must be registered within the InternalStartup() method by standard declaration. Wiring an event to display a message box telling the user they are switching views requires registering the event first.

[csharp]

void InternalStartup(object sender, EventArgs e)   
{     
((FormControl)sender).EventManager.FormEvents.ViewSwitched +=        new ViewSwitchedEventHandler(OnSwitchView);    
}
 
[/csharp]
 

View Delegate
Once the handler has been registered within the InternalStartup() method, the event handler that it is called can be declared by a delegate.
 
[csharp]
public delegate void ViewSwitchedEventHandler(object sender,         Microsoft.Office.InfoPath.ViewSwitchedEventArgs e)  
{      
MessageBox.Show(“You are switching InfoPath Views!”);  
}
[/csharp]

With the event wired as such, whenever a user switches InfoPath views, a message box displays, confirming that they are switching views. More elegant event handlers could be developed depending on the event capturing logic that is required; however the overall concept remains the same.

By the same token, it is possible to validate the XML fields so a user entering null values into an InfoPath form is passed a message.

Register Event in InternalStartup()
First, register the XML event handler in the InternalStartup() method. Since it is an XML event, an XPath statement is required in order for InfoPath to know which control to validate against.
 
[csharp]
public void InternalStartup()
{   
EventManager.XmlEvents[“/my:myFields/my:ProSharePoint2007Field “].Validating += new XmlValidatingEventHandler(ProSharePoint2007Field_Validating);
}
[/csharp]
Once the event handler has been registered, the actual event logic can be wired to the event to be called when the XML event is tripped.
Validating a Null Value with Event Handling
Use a String.IsNullOrEmpty if check on the value being passed into the InfoPath control to verify a null entry. Otherwise, you can use the Errors.Add method in order to point each error to the XML node, or InfoPath field the error is associated with; in this case the ProSharePoint2007Field. The other error handling method in the below code is the Error.Delete method which removes the error handler if no errors are encountered in the InfoPath field. Any number of string comparison options that are available through the .NET framework could be leveraged if you’re looking for a more elegant error-checking mechanism.
 
[csharp]

public void ProSharePoint2007Field_Validating(object sender, XmlValidatingEventArgs e)

{  

if (!String.IsNullOrEmpty(e.NewValue))    

{       

Errors.Add(e.Site, “ProSharePoint2007Field “, “Null Values are not allowed!”);    

}   

else    

{       

Errors.Delete(“ProSharePoint2007Field “);    

}

}

[/csharp]

Share