Security and Design Conadvantages of Using XML Modeling Framework

Transcription

1 Developing a Security Meta-Language Framework Robert Baird Rose Gamble Dept. of Computer Science Dept. of Computer Science University of Tulsa University of Tulsa 800 S. Tucker Drive 800 S. Tucker Drive Tulsa, OK Tulsa, OK robert-baird@utulsa.edu gamble@utulsa.edu Abstract Service-oriented architectures (SOAs) with web services have become commonplace in business and government application development. One reason that web services should facilitate application implementation and deployment is their use of standards to provide clear descriptions of service expectations. However, when reliance on these standards is mandatory, such as in the case of guaranteeing the SOA meets specific security and information assurance constraints, design and development difficulties arise due to the magnitude of standards available, their cross referencing, and dependencies. This paper introduces a framework to provide the foundation for a security meta-language (SML) that models the security relevant portions of the standards for their consistent, comprehensive, and correct application. The goal of the framework is for security constraints and the SOA application domain to filter the model entities for the SML to define the proper message structure and content that each service in the SOA must have. 1. Introduction Due to the increase in inter-organizational communication across business and government industries, service-oriented architectures relying on web services (WS) have become a popular choice for software development due to the concepts of service discovery, resource sharing, and always-on system availability. The core Web Services Architecture [1] outlines a set of service characteristics that enable these complex functionalities to exist. However, the actual specifications of the standards to fully realize the goals of these interactions are left to businesses and standards organizations. A variety of organizations have collectively authored standards documents to define web services, the messages they exchange, and the protocols for their complex invocations across issues of security, transactions, service-level agreements, and discovery. These organizations include the World Wide Web Consortium (W3C), the Organization for the Advancement of Structured Information Standards (OASIS), the Object Management Group (OMG), xmlsoap.org, IBM, Microsoft, and Oracle, to name a few examples. Collectively, standards that have been defined for web services have taken on the name of WS-*. An initial survey conducted by Denning in 2004 [2] pointed to over 60 WS-* standards. Other estimates of the number of standards were ambiguous because multiple organizations contribute from a distance to develop work that later becomes a single unified standard. WS-BPEL, for example, was a joint combination of IBM s XSFL and Microsoft s XLANG, both service workflow languages. As of 2010, IBM DeveloperWork s tracks a listing of 120 such WS-* standards [3]. Software developers must address an issue of not just selecting the appropriate standards for their software to adhere to, but also an issue of properly incorporating them together into a single architecture solution. The vast number of standards unfortunately can inhibit their correct and complete use. Security concerns further complicate the issues of WS and their invocations due to the frequent appearances of abstract interface specifications, task delegation between services, and the variety of transport mechanisms in place to facilitate invocation. Message security through transport and session-level protection mechanisms, authorization protocols, and authentication tokens are common in WS architectures. With each new security concept for services brings additional WS-* standards. For example, the WS- Security standard includes six profile specifications to describe authorization tokens, each with associated syntax and semantics information. Furthermore, when bridging communication between secure environments the WS-Trust standard must be used to broker authorization information across security boundaries. The proper instantiation of each standard must be

2 guaranteed, otherwise communication failure will occur, likely resulting in loss of functionality or operations performed in a less than secure environment. The goals we seek for a solution to this problem must address the following concerns: Consistency: Instantiation of multiple WS-* specifications must coordinate across the highlevel goals of each standard document and its intended use. Completeness: The solution must provide the capacity to fully reason about the necessary standards documents, messages, and service descriptions in compliance with any XML Schema documentation. This can include instantiating XML or pointing to partially needed document attributes. Reusability: The solution must support the instantiation of the WS-* standards in a multiuse environment and be applicable to new standards as they are introduced and revised. We present in this paper a framework that models the essential elements of the standards to develop a Security Meta-Language (SML) for guiding the formulation of secure messages in a web service architecture. The SML uses language constructs derived from meta-information gathered from WS-* standards. The application domain and its security concerns jointly influence the choice of constructs. Thus, the goal of the meta-language is to serve as a mechanism to resolve many of the issues that arise with multiple standards developed by organizations from different perspectives. When standards must be used simultaneously to govern constraints on functional services and correctly specified messages transmitted between their interfaces, the developer must sift through their magnitude and follow the complex dependency paths to achieve an accurate specification. This poorly defined process impacts both usability and understandability of the resulting services. With respect to security concerns, it also can introduce vulnerabilities when standards are not properly specified. The initial application of the SML is targeted towards identity issues due to a larger fit within the domain of trust (e.g. can two services trust messages from each other). However, the broader applications of the SML are not limited to specific WS- * standards in any way. The SML framework consists of a static hierarchical model of WS standards that works in tandem with a notation for specifying security concerns. We define this framework using a set of complementary UML profiles that align WS-* standards into a view. The static aspect of the framework comes from the standards specification, through which document inter-dependencies only change as new WS standards are introduced. The view allows a system developer to target their investigation to only the standards that are of key interest to their particular need. A dynamic aspect of the framework is the ability to propagate mission-critical concerns through the framework towards the generation of SOAP messages with desirable properties (message security, for example). Additionally, we provide an extensive review of core standards across different concerns resulting in a mapping between standards based on document review and schema linking. We organize this paper in the following way: in the next section we introduce the core standards of interest for reasoning about message security in a WS architecture. We demonstrate the difficulties with instantiating their specifications consistently and point to reasons why these consistency issues occur. In section 3 we introduce our framework for the Security Meta Language and outline the key modeling artifacts it requires to properly function. Section 4 describes an example to demonstrate and validate the usage of our model. We conclude our work with a comparison of other approaches related to web service security. 2. WS-* Standards for secure messaging Service implementation within a WS environment has difficulties because each WS-* standard is scoped according to different orientation models. Four key orientation models exist within web service architectures [1]: (1) message oriented models, (2) service oriented models, (3) policy models, and (4) resource oriented models. Message oriented models are concerned with the encoding, transport, and reliability of messages that services transmit. Service oriented models focus on describing services, their interfaces, and the semantics behind their invocation. Policy models restrict interactions or require (obligate) certain actions to occur under specific situations. Resource models target the concepts of service ownership, discovery, and deployment on the web. As hinted at previously, at a high-level conceptual overlap is common across the different models, but often a disconnect exists when investigating specific WS-* standards. For example, SOAP messaging is the de-facto mechanism to invoke a WS, however the SOAP messaging standard is orthogonal to a service oriented model. The Web Service Definition Language (WSDL), a service description standard, is built around the concept of a service oriented model. It provides the structure to describe services, but lacks the necessary

3 modeling perspective to fully facilitate service discovery, requiring the advancement of standards such as the UDDI Specification to address service registration and browsing. Table 1 introduces many of the common WS-* standards with a basic fit for their relationship within these modeling styles. The distinct modeling perspectives mean that developers must (1) understand the standards within that perspective and (2) know how to cross modeling perspectives to achieve a consistent and coherent specification. Table 1. WS-* Standards Modeling Perspective Standard Message Oriented Service Oriented Policy Oriented SOAP UDDI WS BPEL WS Discovery WSDL WS Federation WS Policy WS PolicyAttachment WS Reliability WS SecureConversation WS Security WS SecurityPolicy XML Encryption XML Namespace XML Signature Resource Oriented Complexity increases when it is realized that some standards exist solely to bridge the gap between modeling perspectives. For example, WS-Security is a basic extension to the core messaging functionality within the SOAP messaging standard. It does not address any issue with respect to describing the functionality of a service and its capacity to fulfill security needs. Instead, WS-Security delegates this responsibility to WS-Policy. WS-Policy provides an abstract policy framework but lacks the capacity to directly specify these extensions. The standard WS- SecurityPolicy connects WS-Policy and WS-Security by attaching security information to the basic policy standard. However, as indicated in Table 1, these standards still do not posses coverage that reaches to the service-oriented model. A final standard, WS- PolicyAttachement, is required to obtain complete coverage. When interacting with the various standards, the developer must understand comprehensively both the documentation of the standard and the associated XML Schema declarations each generally possesses. WS- Security, for example, is comprised of a multi-part documentation effort consisting of different profiles to describe the various authentication tokens available for use in SOAP messages. WS-Security schemas governing the XML instantiation span three separate files. To mitigate the issues outlined in this section, we set the objectives of our Security Meta Language to be: Independent of a specific WS-architecture orientation (e.g. service, message, policy, resource) Adaptable across different concerns (security, Quality of Service, management) Capable of instantiating SOAP messages and identifying key service properties expressible in service meta-data for service selection 3. SML Modeling Framework As previously highlighted, magnitude and interrelationships of WS-* standards are the major problems with guaranteeing security concerns across a SOA of web services. We define a framework to underlie the development of the SML. The framework consists of two key parts: (1) a static model that tracks the inter-dependencies between the WS-* standards of interest (and their artifacts), and (2) a dynamic expressive language for use in modeling constraints over their instantiation. The static model houses three diagram types: Standards Package, Import Relationship, and XML Element Class Instantiation. We rely on UML profiles to express each diagram [4]. UML is a multi-level, object-oriented modeling framework providing a specification language for realworld objects built on top of a higher-level metaclass framework. The UML language has structures for describing Class diagrams with attributes and operations as well as other complex structures such as use cases and state charts 1. UML Profiles enable developers to extend the core modeling functionality by expressing new modeling artifacts known as stereotypes. Although in UML, models can be stored in an encoded XML notation [5], UML does not include the necessary framework to model the descriptive 1 A brief overview of UML class diagrams can be here: ontent/rationaledge/sep04/bell/

4 documents of XML specifications (schemas). XML Schemas define the datatypes and structures for XML documents, and are of popular use in the WS-* standards to describe service descriptions, messages, and security extensions. Carlson [6, 7] introduces a UML profile specifically for notating XML schemas. Within the UML core metaclass, elements describe modeling elements that can be used by regular software models or extended by profiles. The profile Carlson specifies extends the UML metaclasses elements class, constraints, package, and property. We condense the main stereotypes outlined in [6] into Table 2, listing the metaclass inheritance and associated XML elements they target. Table 2. XML UML Profile Stereotype names and corresponding XML Elements Stereotype Name Metaclass Inheritance Corresponding XML All Class xsd:all AttributeGroup Class xsd:attributegroup Choice Class xsd:choice Global, GlobalProperty Class Group Class xsd:group Sequence Class xsd:sequence ComplexType Class, DataType xsd:complextype Documentation Comment xsd:documentation Key Constraint xsd:key KeyRef Constraint xsd:keyref Unique Constraint xsd:unique SimpleType DataType xsd:simpletype Union DataType xsd:union Restriction Generalization xsd:restriction Schema Package, Artifact xsd:schema Import PackageImport xsd:import Include PackageImport xs:include Redefine PackageImport xsd:redefine Any Property xsd:any Attribute Property xsd:attribute Content, ContentType Property xsd:simplecontent Element, GlobalElement Property xsd:element GlobalAttribute Property xsd:attribute Facet Property, Constraint xsd:pattern Note that the stereotype <<global>> in the 4 th row is used as a collector for element attributes defined at a global level. Table 2 serves as a mapping between the schema specifications associated with each WS-* standard and the core UML model we advocate. It is important to note that Carlson s UML profile lacks two major aspects we require. First, it is not tied to any level of security concerns. Second, the base profile is insufficient to model the complex document interdependencies present in the WS-* standards. Although the profile contains a <<Schema>> stereotype, it lacks the descriptive framework to collect multiple schema standards into a package concerning single or multi-part WS-* standards. To address these modeling aspects, we define new modeling extensions in Figure 1. <<metaclass>> Package <<stereotype>> Standard <<metaclass>> Document +version: String[0..1] +organization: String[0..*] +authors: String[0..*] +documentationurl: String[0..1] +schemas: Schema[0..*] <<stereotype>> Describes <<metaclass>> Dependency <<stereotype>> Uses <<stereotype>> Extends Figure 1. Standards Package Stereotypes Figure 1 contains the four UML stereotype definitions we require to diagrammatically notate a Standards package view. On the left in Figure 1 is a stereotype to describe a WS-* Standard. The stereotype is a generalized form of the UML metaclass Package and Document. This dual generalization stems from the WS-* containing namespace declarations, which are attributes commonly associated with UML packages, and documentation information, which the UML document and artifact stereotypes are tasked with notating. Each standard contains a version, of which more than one can be in use. The organization, authors, and documentationurl are also represented. As part of the Standard stereotype in Figure 1, a standard can posses multiple Schema specifications, taken from the Carlson stereotype for <<schema>>. This datatype stores the information traditionally held within the root element of a schema specification including version number, target namespace, namespace prefix, and schema location. By incorporating multiple schema specifications into a single standard, our model addresses the issues outlined in the previous section for multi-part standards specifications. Figure 1 defines three stereotypes generalizing UML dependency associations: <<describes>>, <<extends>>, and <<uses>>. These stereotypes are not to be confused with <<extend>> for use cases and <<use>> for classes. The stereotype Extends references specifications that expand the number of XML elements available for use in instantiated XML documents, or those standards that define new messaging patterns for use in web service communication. The Uses stereotype refers to the delegation of responsibility or message specification. For example, services delegate the task of communication to the SOAP messaging standard, and WS-Security delegates the encryption of specific XML elements to XML-Encryption. The stereotype Describes is explicitly reserved for standards that provide meta-data surrounding services, their invocations, and the extension mechanisms between the standards.

5 <<uses>> WS-PolicyAttachment SOAP WS-Addressing <<extends>> <<uses>> WSDL <<describes>> Web Service <<extends>> <<uses>> XML-Encryption <<describes>> <<describes>> WS-Security <<uses>> XML-Signature WS-Policy <<extends>> <<extends>> <<extends>> <<extends>> <<extends>> WS-SecurityPolicy <<describes>> WS-ReliableMessaging WS-Trust WS-SecureConversation WS-Federation <<describes>> <<describes>> <<describes>> Figure 2. WS-* Standards Package Diagram Figure 2 shows the basic usage of the three associations. For example, WS-Security Extends the core functionality of SOAP messages, and WS- Security Uses the specifications XML-Encryption and XML-Signature. An abstract web service class serves as a placeholder to root the example standards in the WS domain, showing how WSDL (and WS-Policy) Describes the functionality of web services. Note that the number of standards shown in Figure 2 is only a partial representation of the full collection that comprises the framework. A complete model can be downloaded from [8]. Notating the dependency relationships according to these terms assists in making the profile viewpoint standards-centric, instead of the traditional message or service-centric approaches used in other meta-models. Our next diagram in the UML profile is the Import Relationship diagram in Figure 3 which maps the complex interdependencies between the WS-* standards packages to an XML schema level of analysis. To generate the diagram we attach specific XML Schemas to each Standard definition. This information is taken from the <<schema>> stereotype and summarized in Table 3. Each schema is shown using a standard notation. The stereotype is defined within the core UML specification [4] and refers to tangible artifacts associated with development, in this case schema files associated with the packages that each standard advocates. Though each Schema conforms to the full data type for XML Schemas established by [6], we use this small notational difference to simplify the figure due to its complexity of interrelationships. Also note that references to the XML Schema declaration template ( are not included due to their appearance in every WS standard.

6 Figure 3. Import Relationship diagram Table 3. Standard-Schema Relationships Standard Schema SOAP envelope soap envelope WS Addressing ws addr.xsd WSDL wsdl wsdl/http wsdl/mime wsdl/soap WS Federation authorization.xsd federatoin.xsd privacy.xsd WS Policy / WS PolicyAttachment ws policy.xsd WS ReliableMessaging fnp 1.1.xsd reference 1.1.xsd ws reliability 1.1.xsd wsrmfp 1.1.xsd WS SecureConversation ws secureconversation 1.3.xsd WS Security oasis wss wssecurity secext 1.0.xsd oasis wss wssecurity utility 1.0.xsd oasis wss wssecurity secext 1.1.xsd WS Trust ws trust 1.3.xsd XACML access_control xacml 2.0 policy schema os.xsd XML Encryption xenc schema.xsd XML Signature xmldsig core schema.xsd soap-envelope.xsd WSDL oasis wss-wssecurity-secext-1.0.xsd oasis wss-wssecurity-utility-1.0.xsd oasis-wss-wssecurity-secext-1.1.xsd xmldsig-core-schema.xsd xml.xsd ws-addr.xsd MetadataExchange.xsd saml-schema-metadata-2.0.xsd ws-securitypolicy-1.2.xsd ws-authorization.xsd Error ws-policy.xsd xenc-schema.xsd envelope privacy.xsd federation.xsd ws-secureconversation-1.3.xsd ws-trust-1.3.xsd ws-reliability-1.1.xsd reference-1.1.xsd fnp-1.1.xsd wsrmfp-1.1.xsd WSDL/SOAP WSDL/HTTP WSDL/MIME

7 The model in Figure 3 relies on the UML PackageImport stereotype to notate appropriate usage information. Within UML, a package import is an association from an importing package to the imported package indicating that the importing namespace collects the names of the elements of the package to its own scope [4]. In the example from Figure 3 this means that the WS- Security schema -secext-1.0.xsd can use the elements defined in the SOAP messaging schema soapenvelope.xsd. Given the information formulated for the first two diagrams, we generate the final diagram in our profile the XML Element Class Instantiation shown in Figure 4. Class instantiation in this case refers to the ability for the profile to take XML elements within each of the associated XML Schemas and translate the information into UML classes given the mappings established in Table 2. Instantiation does not refer to a real-world object instantiation or XML document generation; this is reserved for our dynamic model which will be discussed in the following section. Figure 4 takes modeling elements from the specification for WS-Security and diagrammatically shows their information alongside the associated package relationships revealed in the Schema Package Artifact diagram. Note that the package names between the standards packages (Figure 2 for example WS- Security), and the Class view (Figure 4, for example wsse) are different. This is to be expected as the packages refer to different levels of granularity. At the higher level the diagram is a visualization of the standard. At the lower level the diagram is a visualization of the Schema and XML. Currently, the UML profile has a high-level view of the interconnectivity of the standards based on their documentation and relationships, and a low-level interconnectivity analysis based on the underling XML schema specifications. As depicted in Figure 4, tracing information down to a singular XML Class introduces a collection of XML elements and attributes. By targeting specific concerns at the higher-level packages fewer numbers of these classes must be considered when proceeding to map specific constraints over their instantiation. 4. Evaluating the Dynamic Model In this section we introduce our dynamic model which will form the foundation of the language in our Security Meta Language framework. Taking the basic static model established by the WS-* standards and their associated XML Schema documents, this dynamic model overlays specific security concerns onto the elements that are available and their instantiation within XML documents. The dynamic model must incorporate constraints from three key sources of information: The static UML model: including the classes available for use and any instantiation constraints that can be gleaned through Schema analysis. For example, a WS-Security XML header can consist of any number of XML sub-elements. The standards documentation: which govern the intended use of the Schemas and the XML structures they specify. For example, in multirecipient environments, WS-Security headers need to clearly identify the intended recipient. The operational needs of the environment: including any needs for specific service functionality, message deliverability assurances, and transport security.

8 Envelope +header: Header[0..*] +body: Body[1..*] s11 soap-envelope.xsd <<import, access>> <<element>> Header <<element>>+: any[0..*] <<element>> Body <<element>>+: any[0..1] <<extends>> oasis wss-wssecurity-secext-1.0.xsd <<import,access>> oasis-wss-wssecurity-secext-1.1.xsd <<element>>+security: SecurityHeaderInstance[1..*] <<import,access>> wsu oasis wss-wssecurity-utility-1.0.xsd <<desired>> wsse::securityheaderinstance <<attribute>>+mustunderstand: Boolean <<attribute>>+actor: S11:actor <<attribute>>+role <<element>>+securitytokenreference: wsse:securitytokenreferencetype[0..*] <<element>>+binarysecuritytoken: wsse:binarysecuritytokentype <<element>>+usernametoken: wsse:usernametokentype wsu:id <<attribute>>+id: xsd:id[1] wsse wsse::securitytokenreferencetype <<any,element>>+wildcard[0..*] +<attribute>>: wsu:id +<attribute>>: wsse:usage <<any,attribute>>+wildcard[0..*] <<global>> WSSGlobals <<globalelement>>+usernametoken: wsse:usernametokentype <<globalelement>>+binarysecuritytoken: wsse:binarysecuritytokentype <<globalelement>>+reference: wsse:referencetype <<globalelement>>+embedded: wsse:embeddedtype <<globalelement>>+keyidentifier: wsse:keyidentifiertype <<globalelement>>+securitytokenreference: wsse:securitytokenreferencetype <<globalelement>>+security: wsse:securityheadertype <<globalelement>>+tranformatoinparameters: wsse:transformationparameterstype <<globalelement>>+password: wsse:passwordstring <<globalelement>>+nonce: wsse:encodingstring <<globalattribute>>+usage: wsse:tusage wsse::transformationparameterstype <<any,element>>+wildcard[0..*] <<any,attribute>>+wildcard[0..*] EmbeddedType <<any,element>>+wildcard[0..*] <<attribute>>+valuetype: xsd:anyuri <<any,attribute>>+wildcard[0..*] ReferenceType <<attribute>>+uri: xsd:anyuri <<attribute>>+valuetype: xsd:anyuri <<any,attribute>>+wildcard[0..*] SecurityHeaderType <<any,element>>+wildcard[0..*] <<any,attribute>>+wildcard[0..*] <<enumeration>> FaultcodeEnum +wsse:unsupportedsecuritytoken +wsse:unsupportedalgorithm +wsse:invalidsecurity +wsse:invalidsecuritytoken +wsse:failedauthentication +wsse:failedcheck +wsse:securitytokenunavailable <<datatype>> QName Figure 4. XML Element Class Instantiation Diagram

9 Failure to take account of essential information can lead to several sources of errors. Not accounting for operational needs can result in service operations that do not fulfill the intended goals of the software developers or end-users. For example, services that do not encrypt their communication introduce an information security risk. Failure to follow the standards documentation can potentially generate SOAP message communication that adheres to normative Schema standards, which can be transmitted, but will result in failures at service endpoints due to lack of adherence. Finally, failure to follow the XML schemas will result in SOAP messages that do not pass basic type checking constraints. As an example instantiation of the dynamic model, we investigate a basic WS domain that requires communication between a client and service to include the attachment of a username token to each SOAP message. This exemplifies a security requirement for attaching identity to invocations. We model the requirement in Figure 5, showing the link between the static model and the dynamic model. SOAP Message : Envelope +header: Header +body: Body header : Header +token: UsernameTokenType token : UsernameTokenType <<attribute>>+wsu: Id = "tokenid" <<element>>+username = "user1" Envelope +header: Header[0..*] +body: Body[1..*] <<element>> Header <<element>>+: any[0..*] UsernameTokenType <<sequence>>+ <<attribute>>+: wsu:id <<any, attribute>>+wildcard[0..*] Figure 5. Dynamic Model Instantiation Along the right hand side of Figure 5 are the classes representing XML elements of the static XML Class Instantiation model. Along the left hand side is an instantiation of a real world object attaching requirements that fulfill constraints from all three sources of dynamic information. In this example, there is a SOAP Message with an instantiated header, it contains a single token with a Id of tokenid and a username element of user1. Fully establishing the SML will require instantiating several XML objects that fulfill security requirements. The UML model will act as a template in this case due to the fact that, although the XML is being given basic structure, specific details such as the message body are left unspecified. In this sense the SML, once fully instantiated with multiple security concerns across multiple domain goals, will serve as an intermediary between the high-level security assurance criterion and the low-level XML message instantiation. 5. Related Research Issues of software assurance permeate web services and their development, ranging from source code development to more complex issues of federated trust and identity management. We focus on software assurance within the realm of the standards that govern WS interactions. This typically deals with the interfaces that services expose, and not their internal functionality. Previous research has established a mapping relationship between NIST security controls and specific WS-* standards documents and element attributes [9]. Many of the security controls address software assurance considerations, such as auditing across distributed WS and the protection of audit records. Within this realm it is possible to map specific assurance levels to the existence of XML element attributes in SOAP messages and service descriptors, though consistency is still required across the instantiation of all the compatible standards. Meta-modeling within WS architectures traditionally concerns the generation of semantic information to attach with existing WS standards documents. A variety of current standards can accomplish the level of annotation that services require. Work in [10] establishes a meta-model across the different WS-* semantic standards (OWL-S, WSDL-S, WSMO, SWSF, etc.) to join different conceptual semantic models. Although these standards are XML in nature, the model targets the higher-level conceptual concepts across the different languages. Modeling elements and associations are presented in UML, however no extensions to the base UML metamodel are created. Other approaches to model the different types of semantic information that can be attached to WS include examining the different technology layers associated with services and the types of standards that can be applied across them [11]. 6. Future Work and Conclusion Early modeling of the WS-* standards into the static portion of the model has resulted in the discovery in standards inconsistencies between the various XML Schema specifications. For example, within the standards for WS-Federation a reference is made to the external standard WS-Addressing to deal with addressing concerns within SOAP messages. However the XML reference is to an invalid XML Schema file

10 location. As we explore more standards it is likely that more inconstancies will be found both at the schema level and the documentation level. Larger evaluation for the complete SML requires subsequent analysis to determine if the framework includes standards from multiple organizations and that are currently relevant to WS development. Success of the SML will be measured through the crafting of complete SOAP messages and assessing their desirable properties. These properties include the capability for delivery, security, and message reliability. Checks to determine if the SOAP messages violate any of the internal attribute linking constraints will complete the SML. We currently use the software StarUML [12] to model the XML elements within the SML. Future work will complete the profile specification in a module that is fully compatible with StarUML so that stereotype specifications can be used natively within the modeling environment, and downloadable so that software developers can instantiate and experiment with various WS-* standards documents. Additional plans include developing a clear application of the meta-model associations between the WS-* packages based on clear goal statements taken from the associated standard documentation. This will provide grounding to these mappings within the SML framework. Although we apply our example to WS-* message security and software assurance, it is easy to see that the framework is not limited to that domain. Although the area of focus we target for standards instantiation is within the domain of web service security, a complex interrelationship between these XML standards exists for the domains of web service management, workflow orchestration, and service level agreement negotiations. Acknowledgement. This material is based on research sponsored in part by the Air Force Office of Scientific Research (AFOSR), under agreement number FA and in part by the Air Force Research Laboratory (AFRL) under agreement number FA The U.S. Government is authorized to reproduce and distribute reprints for Governmental purposes notwithstanding any copyright notation thereon. The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied of the AFOSR, AFRL, or the U.S. Government. 7. References [1] W3C, "Web Services Architecture," [2] P. Denning, "Annotated List of Web Services Specs," [3] IBM developerworks, "SOA & Web Services - Standards," vices/standards.jsp [4] Object Management Group, OMG Unified Modeling Language (UMG UML) Superstructure, [5] Object Management Group, "MOF 2.0 / XMI Mapping Specification, v2.1.1," xmi.htm [6] D. Carlson, "UML Profile for XML Schema," s/xmlschemaprofile [7] D. Carlson, Modeling XML Applications with UML: Practical e-business Applications: Addison- Wesley Professional [8] Software Engineering and Architecture Team, [9] R. Baird and R. Gamble, "Security Controls Applied to Web Service Architectures," in 19th International Conference on Software Engineering and Data Engineering, [10] F. Lautenbacher and B. Bauer, "Creating a Meta- Model for Semantic Web Service Standards," in Proc. of the 3rd Intl. Conf. on Web Information System and Technologies (WEBIST)-Web Interfaces and Applications, Barcelona, Spain, [11] B. Thuraisingham, "Security standards for the semantic web," Computer Standards & Interfaces, vol. 27, pp , [12] StarUML,