Printer Friendly


Byline: Mukhtiar Memon, Gordhan D. Menghwar, Akhtar A. Jalbani, Mansoor H. Depar and Ghulam Ali Rahu


In today's digital world the business processes change dynamically as the services offered by organizations involve collaboration among many partners. Every partner contributes a part of the whole process in the service. A service portal provides an interface to service consumers and invokes other services to complete the business process [1]. Such inter-organizational workflows involve sharing of resources owned by collaborating partners and consumers. These resources contain the personal data of individuals and financial, organizations and legal facts of the companies. Also, increasing complexity in the business collaborations involving software-based negotiations among partners magnifies the security challenges [2]. Therefore, workflows processing security-sensitive data of business partners or personal data of individuals need to be modeled explicitly with security considerations.

The common practice has been to include security related requirements in the systems during implementation phase with handcrafted fixed-code. But today's business activities are not so simple that the security programs written once can withstand the unforeseen challenges emerging due to changes in the processes, platforms, legalities or business priorities. As a result the security of systems is often compromised while unjustifiably using the fixed-code security procedures. Moreover, it is not easy to accommodate changes in such platform-specific and tightly-coupled security procedures when the systems are in execution. However, if Security requirements are modeled with the functional models and validated timely by domain experts then the requirements can be met accurately and changes can be accommodated smoothly [3]. Expressing security concerns with functional models provides the opportunity for communication among stakeholders which ensures early requirement validation.

In fact, this is the main objective of model-based engineering (MDE) to design the systems using the high-level models and write transformation rules with model-transformation languages instead of writing computer programs. Our approach applies model-transformations to generate executable abstract security services instantiated by other applications. This raises the state-of-the-art from software engineering to security engineering, where developers can use concepts, methods and tools for the systematic and cost-effective development of secure solutions.

The remainder of the paper is organized as follows. In Section 2, we discuss the related approaches. Section 3 presents the use case for security requirements. The proposed approach for modeling security services is presented in Section 4, followed by Security Composition in Section 5. We conclude our discussion in Conclusion part.


Different approaches in security engineering community deal with the specification of security requirements in the context of formal methods. The main objective of most of the research related to modeling security aspects is to provide frameworks for the tool-supported correctness proof of security solutions [4,5,6]. Alexander Roehm [7] has discussed how composed security services can be evolved from abstract security specifications to enable technological solutions. The main stages suggested by the authors for security of business transactions are Abstract Specifications, Implementation and Execution at the runtime platform. Accordingly, Joese Vivas [8] research is based on empirical studies, which prove that domain experts express the security requirements at business process level. Their surveys further elaborate that there is a lack of systematic support for software engineers for designing secure systems and specify high level security policies.

The model proposed by them extends the business processes with security extensions using UML stereotypes to capture the basic security requirements at data elements. Some of the research work deals with code generation for the platform technologies to evolve secure systems. In this regards, Martin Johns [9] has motivated how to generate code for secure web applications by separating the data from code. Among foundational research in this direction by David Basin [10,11] and Ulrich Lang [12] have presented the methods for high-level specification of access control policies targeting J2EE environment and CORBA architecture, respectively.

The proposed approach is also compatible to Service Oriented Security (SOS) Architecture [13], as we compose the service components using Service Component Architecture paradigm. Like SOSA, our approach relies on the abstract security services and provides security implementations to other applications. We define the security viewpoints of Use case, Service, Identity and Message as in SOSA [13].

3. USE CASE: HEALTHCARE SYSTEM S SECURITY The healthcare systems offer medical services which access patients' medical records (PMR) created by the Primary Physician (PP). The PP stores the record in the local database of clinic. However, this record is accessed by other healthcare users for different purposes. For example, when the PP refers the patient to a specialist, then the specialist should access the PMR to know about patient's disease history before performing any tests for diagnosis. Similarly, a Pharmacy accesses the PMR for providing medicine; the health insurance has to verify insurance coverage of the disease, a medical institute needs the data for research. In these scenarios, when the medical record is accessed by different organizations, it is more challenging to ensure the secrecy and privacy of the medical data. The patient does not want to disclose their sensitive medical data to public, because it can adversely affect their personal, professional and social life.

The health privacy legislation [14, 15] authorizes the patient as the owner of her medical record. This means that any disclosure of any parts of medical record, without consent from the owner is illegal and un- ethical. We describe a use-case, which defines complex security and privacy requirement in the healthcare, as shown in Figure 1.accesses the patient's record with no restrictions, without any rights delegation and consent from patient only in the context of 'Emergency'. The patient can give the consent for a context. For instance, a patient gives a consent that the RS should access certain records from PMR for taking a radiography. In that case, consent will be included in the authorization policy is an additional constraint. Consent defines who should access which records from PMR; for which purpose and for how long etc. We will use context- based authorization pattern for modeling the policies in a context.

Non-Repudiation: The PP refers the patient to a RS. The reference is in the form of a message that goes from PP to RS. The system should be able to create evidence for this communication, so that both PP and RS should not be able to deny having sent and received the reference. This is achieved by enforcing Non-repudiation. To achieve these security requirements, the target architecture requires security policies for authentication and authorization. Moreover, to keep the business and security code separate, it is important that the security policies should not be interleaved with business logic. In the subsequent section, the proposed layer approach is discussed to achieve these goals.


This section is dedicated to describe the proposed approach.Figure 3 shows the three layers of the proposed approach i.e., i) Security Requirements, ii) Abstract Security Protocols, and Controls and iii) Implementation-specific Model (ISM) layers, respectively. The Security Requirements layer defines high-level security requirements written in OCL. The Protocol and Controls layer takes the requirements from first layer to design the high-level security protocol and controls. The Implementation-specific Model layer is about the target platform that defines the security architecture, protocols, encryption and signature methods, security tokens etc., supported by underlying platform. The idea of ISM brings the advantage that the abstract models are used for a variety of platform implementations, whose details are captured by ISM. ISM is used to generate the security policy (as WS-SecurityPolicy), based on the security requirements of execution platform. ISM is shown in Figure 3.

Different parts of Figure 3 are discussed below as numbered:

Authentication is defined as a requirement using an OCL [3] constraint, which means that the physician must be authenticated to access the services.

The services are defined in the abstract class of Healthcare Service, describing interfaces to view and modify the Electronic Health Record (EHR) respectively (i.e. viewEHR and modifyEHR).

The Abstract Security Protocol shows that the healthcare service provider must attach an Authentication Policy with the service that defines its authentication requirements. We generate the SAML- based authentication policy written as WS- SecurityPolicy from ISM.

Physician invokes security service to get the SAML tokens and protect them as defined in service provider's policy and also shown in abstract security control i.e., Protection(credentials).

Protection control is mapped to the equivalent cryptographic controls of Encryption, Signature and

Service provider sends the authentication policy to the physician Time-stamping, which means that using these mechanisms the credentials can be protected.

Cryptographic controls depend upon other parameters i.e., Type of Binding, Tokens and Algorithms also defined in the authentication policy. Figure 3 shows the example values of those parameters. For example, the type of required binding is Asymmetric; x509

Certificates are used as security tokens for authentication; Username Token is accepted as Supporting Token and SAML Token are required as Signed Supporting Token.

The Architectural part of ISM shows the endpoints as Policy Subjects. As the architecture is also a platform-specific, so it is not provided in the abstract protocol. This means that the abstract protocol can be used for a number of architectural implementations. How the architecture could be different is based upon which partners are involved in the security protocol. For instance, it is possible that the healthcare service provider is also an identity provider. The second possibility is that the service provider relies on token validation decision of an authenticator, which is covered in our example. Additionally we assume that the service provider accepts the signed SAML tokens, provided by SAML Authority of security broker. The SAML-based Authentication Security Protocol based on these considerations is shown in Figure 4. The protocol shows that the service provider calls services of a Security Broker for token validation, who is a security service provider.

The Security Broker provides two services i.e. token validation by Authenticator which relies on a Security Token Service (STS) and token assertion by a SAML Authority. The requester obtains the SAML authentication assertion from the SAML Authority and submits to the service provider as defined in SAML Profiles [16].


One of the essential features of proposed approach is the security engine which does most of communication with candidate services and other internal components of abstract execution platform. Different parts of this platform (Figure 4) are responsible to perform specific tasks to execute platform-independent security services.

These parts are Security Engine, Service Composition and Security Components. When service consumer requests secure system functionality, the service provider as candidate requests the corresponding security service to ensure secure access.

The candidate's request is received by the Adapter, which is an integral part of security engine. We use Adapter to enable communication between heterogeneous functional and security services. The security requirements by the candidate service are defined in the form of abstract models; therefore it is required to find suitable executable service(s) which can provide requested security functionality from available security components. An adapter specifies, which services required by the candidate needs implementation of which components. It is also responsible for handling any logic necessary to transform data into a form that is useful for the services. Through the adapter the Security Engine collects security requirements from the candidate application and forwards to the service composition. Based on the request the service composition selects required security components, integrates them into service composite and returns to adapter, which sends service instance to candidate.

A security component is specifically programmed to provide a dedicated security service (e.g Encryption, Digital Signing or Auditing). The Service Composition requires information about rules to set the order of execution of components and select appropriate security protocols.


In this paper, we proposed a three-layered approach of transforming the security-aware high-level functional models into platform specific security services. We separate the Application Domain and the Security Domain, so that the application designers should focus more on business problems and define the security objectives in high-level business models with patterns. We assume that any services (e.g. web services, BPEL process) or applications (e.g. web, J2EE etc.) can be the candidates. Proposed solution supports reusability of design, as the security services are formed from components programmed once and used for a variety of implementations.


[1] M. Zur Muehlen and M. Indulska. Modeling languages for business processes and business rules: A representational analysis. Inf. Syst., 35(4):379-390,2010.

[2] Jun Han and Khaled M. Khan. Security-Oriented Service Composition and Evolution. In APSEC '06: Proceedings of the XIII Asia Pacific Software Engineering Conference, pages 71-78, 2006.

[3] Mouratidis, H. Software Engineering for Secure Systems: Industrial and Research Perspectives, IGI Global, 2011. 1-388, June 2011.

[4] Jan Juerjens, Secure Systems Development with UML,Springer Verlag, 2003.

[5] Guido Wimmel and Alexander Wisspeintner, Extended description techniques for security engineering. In Sec '01: Proceedings of the 16th international conference on Information security: Trusted information, pages469-485, 2001.

[6] Anupam Datta, Ante Derek, John C. Mitchell, and Dusko Pavlovic, A derivation system and compositional logic for security protocols. Journal of Computer. Security, 13(3): 423-482, 2005.

[7] W. Roehm, G. Herrmann, and G. Pernul. A Language for Modeling Secure Business Transactions. In ACSAC '99: Proceedings of the 15th Annual Computer Security Applications Conference, page 22, Washington, DC, USA, 1999.

[8] J. L. Vivas, J. A. Montenegro, and J. Lopez. Towards a Business Process-Driven Framework for Security Engineering with the UML. Lecture Notes in Computer Science, Vol. 2851/2003, 381-395, 2003.

[9] Martin Johns, Christian Beyerlein, Rosemaria Giesecke, and Joachim Posegga. Secure code generation for web applications. In Proceedings of 2nd International Symposium on Engineering Secure Software and Systems (ESSoS 2010), Lecture Notes in Computer Science, Vol. 5965: 96-113, 2010.

[10] Torsten Lodderstedt, David A. Basin, and Jurgen Doser. SecureUML: A UML-based modeling language for model-driven security. In UML '02: Proceedings of the 5th International Conference on The Unified Modeling Language, pages 426-441, London, UK, 2002.

[11] David Basin, Juergen Doser and Torsten Lodderstedt. Model Driven Security: From UML Models to access control infrastructures. ACM Trans. Software. Engineering. Methodologies, 15(1):39-91, 2006.

[12] Ulrich Lang and Rudolf Schreiner. Developing Secure Distributed Systems with CORBA, Artech House, Inc., Norwood, MA, USA, 2002.

[13] Gunnar Peterson, Service Oriented Security Architecture, 2005.

[14] Office of the Privacy Commissioner of Canada. Personal Information Protection and Electronic Documents Act, (PIPEDA)., 2005.

[15] United States Department of Health and Human Services. Health Insurance Portability and Accountability Act, (HIPAA),, 1996.

[16] Security Assertion Markup Language (SAML).
COPYRIGHT 2012 Asianet-Pakistan
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 2012 Gale, Cengage Learning. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Author:Memon, Mukhtiar; Menghwar, Gordhan D.; Jalbani, Akhtar A.; Depar, Mansoor H.; Rahu, Ghulam Ali
Publication:Science International
Article Type:Report
Geographic Code:9PAKI
Date:Sep 30, 2012

Terms of use | Privacy policy | Copyright © 2020 Farlex, Inc. | Feedback | For webmasters