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

sharepointsecurity.com Main Site RSS Feeds Fixed

Well didn’t that suck, especially on a frickin Sunday, go figure. AC (Andrew Connell) let me know that the main feed off the site was farting out today, which was a pain in the butt to fix, ugh. The first problem was fixing the actual feed generation off the nuke content module itself. Well, unbeknown to me IE7 doesn’t support DTD’s, which as most people know are used in order to help an XML parser work with a document, particularly for validation, which I unfortunately had in my XML generation code, that was no biggie to fix, just stripping out that from my $rssFeed variable declaration.

Then, my god, the mod_rewrite rules that I had set up for Apache to massage more friendly URL’s for output were screwing up the pulling of the nuke URL which I just did a simple $nukeurl = $row[‘nukeurl’]; to normally query for. Well, that didn’t work out so well because the mod_rewrite said that should actually output to its rule output so was appending an index.html to the final string. So, then I had to declare a $domain = eregi_replace(“index.html”, “”, $nukeurl); to strip that out.

Then, the link XML declarations were getting hosed and causing code errors in the feed because of the mod_rewrite / Apache upgrades that were done on the server on Friday. About ready to slit my wrists, I fixed the link URL by doing a:

[php]

.’ ‘.$domain.’content-‘.intval($row[‘pid’]).’.html‘.$slf
[/php]

Which finally got the functionality I needed back. Now I have to increase the character return of the summaries, and then I can finally get back to finishing my other work.

Bah! :-)

Share

What is Disaster Recovery in Relation To SharePoint?

* This article was written in the context of System Center Data Protection Manager 2006 (SCDPM), a technology now considered deprecated with the introduction of System Center Data Protection Manager 2007. Variations may exist. *

What is Disaster Recovery in Relation To SharePoint?
Disaster recovery in relation to SharePoint can mean many things, depending on the organization. Different enterprises use SharePoint for different purposes, ranging from implementing it solely for collaborating and communicating within virtual teams to using it solely for hooks into other server systems such as Team Foundation Server or Project Server. For whatever reason a company uses SharePoint, it is clear that there needs to be policies in place that will facilitate disaster recovery in the event that something may cause massive data loss for your portal. In essence, DR in relation to SharePoint can generally be thought of as processes, mechanisms, and policies that if data loss does occur for whatever reason that disrupts the portal to an irretrievable state it can quickly be returned to operational efficiency with little effort.
 
Why Should I Be Concerned With Disaster Recovery?
Disaster recovery can be an issue at many levels. Damage could inflict SharePoint file stores, custom development (ASP.NET 2.0 WebParts, SharePoint WebParts, or Framed Applications), design / branding efforts (master pages, manual modifications), and most importantly your stored business data. Without a disaster recovery policy and DR tools, your SharePoint environment can quickly become a central portion of business processes within an enterprise to a useless system leaving a bad taste in user’s mouth bringing SharePoint adoption to a standstill.
 
What Can I Do To Prepare for Proper Disaster Recovery?
There are several mechanisms that should be implemented in order to prepare for a disaster recovery situation. Some of which deal with implementing a proper disaster recovery policy, others are for implementing various types of software that will help to facilitate bringing your portal backup to speed if there is an event of large data loss.
 
What Types of Disaster Recovery Software Are Available?
There are several types of disaster recovery software that are based on varying types of software theories. In relation to the actually physical archiving of backup data, the three most popular are:
  1. Disk-to-Tape (DtT)
  2. Disk-to-Disk (DtD)
  3. Disk-to-Disk-to-Tape (DtDtT) 
Three of the most popular types of software are:
  1. RTR (Real Time Replication)
  2. CDP (Continuous Data Protection)
  3. DPM (Data Protection Manager)
How do I Choose the Appropriate Software for Disaster Recovery?
The software that you choose for your disaster recovery policy varies heavily on your organization. Some of the decision factors will be based on company cultural, some on functionality that you desire out of your DR bundles. As an example of cultural decisions, some shops will only implement Microsoft-centric software since it will generally build on and into other server packages and client software (as is the case with the Microsoft Operations Framework, since DPM will tie into Microsoft Operations Manager for management and reporting purposes), and is typically part of their Microsoft enterprise agreement(s). Some organizations are indifferent to the vendor, and are more concerned with varying functionality. When looking at replication or disaster recovery solutions, quick decisions are never the best ones. You have to examine each package in relation to your SharePoint environment, and possibly other systems that might be sheltered by the same solution.
 
Why is SharePoint a Difficult Product to Implement Disaster Recovery for?
SharePoint as a platform is subject to constant change, users uploading, modifying, and deleting documentation and other relevant portal assets, customizations being made to different site collections, and new portions of the portal being extended and de-extending everyday at every hour. Implementing disaster recovery for an environment that requires such an extent of synchronous backups during such intensive intervals during normal user hours is incredibly difficult. Ensuring that data is constantly intact in such a largely user adopted platform can also be problematic since the platform is almost constantly in use.
 
Is the Disaster Recovery Process a Task of a SharePoint Administrator, Network Administrator, or Users?
Protecting the assets of the portal is the responsibility of all of the above parties, and doesn’t all solely on the shoulders of just one position or person. The SharePoint administrator is typically most familiar with the status of the database and overall environment, the network administrator knows bandwidth usage and disk allocation within the network, and the users of the portal are typically the most familiar regarding specific assets within arbitrary site collections. The restore process depending on what has been lost can be the responsibility of either of the parties as well, as long as the process as it is tripped is documented, and doesn’t interfere with other SharePoint user activities.
 
What Does a Disaster Recover Policy Consistent of for SharePoint?
Here is a sample disaster recovery policy for SharePoint. It might have to be tailored to your environment more depending on what your corporate standards are, but will still be a good start. It is free to use with no copyright restrictions.
 
Is There Specific Disaster Recovery Software Exclusive To SharePoint?
There is no disaster recovery software made explicitly for SharePoint. However, such packages as Data Protection Manager are easily tailored to implement disaster recovery for a SharePoint environment, and can shelter other systems as well.
 
What Are the Prices of Disaster Recovery Software?
Disaster Recovery software can range from relatively cheap to exceedingly expensive and can depend on certain agreements with certain vendors (such as having enterprise agreements within Microsoft). It depends on what level of functionality you are seeking from the software. With real-time-replication, you can recover data within minutes of a disaster, but is not cost effective for small-to-medium (SMS&P) businesses, whereas DPM will be an hourly solution, but several thousands of dollars less and is relatively inexpensive to extend (buy more agents for) and maintain.
Share