Can “Feature” be used to Model the Changing Access Control Policies?
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Can “Feature” be used to Model the Changing Access Control Policies?

on

  • 413 views

Access control policies [ACPs] regulate the access to data and resources in information systems. These ACPs are framed from the functional requirements and the Organizational security & privacy ...

Access control policies [ACPs] regulate the access to data and resources in information systems. These ACPs are framed from the functional requirements and the Organizational security & privacy policies. It was found to be beneficial, when the ACPs are included in the early phases of the software development leading to secure development of information systems. Many approaches are available for including the ACPs in requirements and design phase. They relied on UML artifacts, Aspects and also Feature for this purpose. But the earlier modeling approaches are limited in expressing the evolving ACPs due to organizational policy changes and business process modifications. In this paper, we analyze, whether “Feature”- defined as an increment in program functionality can be used as a modeling entity to represent the Evolving Access control requirements. We discuss the two prominent approaches that use Feature in modeling ACPs. Also we have a comparative analysis to find the suitability of Features in the context of changing ACPs. We conclude with our findings and provide directions for further research.

Statistics

Views

Total Views
413
Views on SlideShare
413
Embed Views
0

Actions

Likes
0
Downloads
1
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Can “Feature” be used to Model the Changing Access Control Policies? Document Transcript

  • 1. International Journal of Research in Computer ScienceeISSN 2249-8265 Volume 2 Issue 6 (2012) pp. 21-31www.ijorcs.org, A Unit of White Globe Publicationsdoi: 10.7815/ijorcs. 26.2012.052 CAN “FEATURE” BE USED TO MODEL THE CHANGING ACCESS CONTROL POLICIES? K.Shantha Kumari1, Dr T.Chithralekha2 1 Research Scholar, Dept of Banking Technology, Pondicherry University, INDIA Email: shanthajayakumar@gmail.com 2 Associate Professor, Dept of Computer Science, Pondicherry University, INDIA Email: tchitu@yahoo.com Abstract: Access control policies [ACPs] regulate risks and vulnerabilities without jeopardizing speed orthe access to data and resources in information cost, organizations must bring security into thesystems. These ACPs are framed from the functional development process and this proved to be effective.requirements and the Organizational security & Hence, the process of integrating the ACPs with theprivacy policies. It was found to be beneficial, when FRs was recommended [2], [3], [4], [5], and [6]].the ACPs are included in the early phases of thesoftware development leading to secure development From the design perspective, access control policiesof information systems. Many approaches are provide an insight to the various kinds of threats,available for including the ACPs in requirements and violations that can be handled in the design phase ofdesign phase. They relied on U ML artifacts, Aspects the software development. The overall systemand also Feature for this purpose. But the earlier development process is fruitful when the design phasemodeling approaches are limited in expressing the supports integrated modeling of ACPs and FRs. Henceevolving ACPs due to organizational policy changes defining the ACPs in the same way as the FRs in theand business process modifications. In this paper, we Design phase is considered as a prudent way. Theanalyze, whether “Feature”- defined as an increment modeling process should be expressive and flexiblein program functionality can be used as a modeling enough to accommodate all the different requirementsentity to represent the Evolving Access control that may need to be expressed, while at the same timerequirements. We discuss the two prominent be simple both in terms of use and implementation (soapproaches that use Feature in modeling ACPs. Also that it can be verified with ease).we have a comparative analysis to find the suitability In some prior works, the existing modelingof Features in the context of changing ACPs. We methodologies are modified to define ACPs as likeconclude with our findings and provide directions for FRs. These methodologies have to take care of thefurther research. proper abstraction of ACPs and the process ofKeywords: Access control polices, Features modeling without losing the consistency of theFunctional requirements, modeling, RBAC functional requirements. Also, the ACPs of today’s enterprise information systems tend to be complex, I. INTRODUCTION 14B dynamic and scalable with respect to the resources under the protection, top management’s policy changes Access control is defined as the ability to permit or etc. The Modeling approach has to accommodate thedeny access to a particular resource (object) by a same for providing consistent access controlparticular entity (subject). An Access control policy throughout the system development. But the presentdefines the (high-level) rules according to which modeling methodologies cannot support these kinds ofaccess control must be regulated. An ACP may express intricate requirements. There is a need for higher levelconditions that must be satisfied before an access of abstraction to capture the complex characteristics ofrequest can be granted. ACPs are derived from ACPs.requirements as well as high-level security and privacypolicies of the organization. Traditionally, ACPs are In recent years, Feature oriented programming andhandled in an ad-hoc way i.e. addressed in an existing Feature modeling caught the attention of the researchsystem either as an afterthought, or manually injected world. Features- a basic building block that representsinto practices of the organization. Late analysis of the intention of concept can satisfy intuitive userACPs can generate conflicts between them and the formulated requirements on the software systems.FRs of the system. This leads to security failures, Feature modeling also has the capacity to representviolations from the access control rules, leakage of variations by feature composition. This makes it morevital information etc [1]. To properly address security suitable for modeling dynamic requirement. www.ijorcs.org
  • 2. 22 K.Shantha Kumari, Dr T.Chithralekha In this paper, Feature based ACPs modeling and represents their behavior using anyone of theapproaches are studied and analyzed. A detailed diagram. But the scalable, dynamic and evolvingcomparison of each feature modeling approach is natures of the ACPs are not represented in UML.done. The advantages and the limitations of every Moreover they either focus on specifying securitymethod are presented. This analysis would help for requirements in UML notation or analyzing UMLpossibilities of new areas in further research. In section models against the specified requirements. Still the2, the modeling approaches prior to feature modeling problem of systematic enforcement of the specifiedare presented and their limitations are reviewed. In requirements exists. To overcome this, researchersSection 3, Features and Feature modeling are took the idea from “Principle of separation ofintroduced. Then ACP modeling approaches using concerns”. This principle helps to identify,features are analyzed and a comparative study is done encapsulate and manipulate those parts of softwarein Section 4. The paper concludes with the future that are relevant to a particular “concern” that maydirections of research. crosscut many design elements at the Design level. 4. Aspect oriented Software development technologies II. LITERATURE REVIEW 15B are a promising proposal to enable the Olden year software systems, by their very nature, modularization of these crosscutting concerns [20].have simple and generic access operations and are not ACPs being a crosscutting concern across theconcerned with the meaning of the resources they functional design and implementation can behandle. On the other hand, modern Information encapsulated as “aspects”. Subsequently, a weavingsensitive systems and applications handle quite process is employed to compose core functionalitycomplex access operations due to their specific user model elements with those aspects, therebypurposes and high functionality. This complexity generating an architecture design. The dynamicneeds to be translated by generic models and specific nature of ACPs is well addressed by “AspectACPs into design phase understandable processes. oriented modeling” [AOM]. The use of aspects inMany approaches including the Formal approaches, security is among the most successful uses ofHigh level languages, Model based approaches aspect-oriented concepts, both at the specification[UML], Process based approaches are available. and coding levels. The Aspect oriented software development which uses the aspects as its base unit1. Formal logic approaches [[7], [8], [9], [10], [11], typically has a programming language character in [12], [13], [14]] have been a significant part in this order to attract a wide user community. research area. They proved to be very much useful − Despite its attractiveness to programmers, this due to their formal theory. Approaches for code-level approach has its disadvantages. specifying and analyzing the ACPs are based on Generally aspects are stated operationally, that sophisticated mathematical concepts, that formally results in unclear specification of it intention. It is stated allows one to check whether the developed quite difficult to prove the correctness of an ACPs enforce the required level of protection. aspect. Also, it is quite unsure about the However, in practice, applying mathematically- application of pointcut to all occurrences of the based formal specification techniques can be intended runtime events. Moreover the difficult because of the high degree of mathematical complexities of the system and ACPs may require skill needed. Thus formal-logic based approaches extending the pointcut and advice description to which are difficult to use and understand, are cover any extra cases which requires an seldom used by application developers. understanding of the modified set of runtime2. Another extreme end is High level languages [[15], events being targeted, and what code to execute [16], [17]]. High-level languages are easy to use in each specific context of occurrence [21]. and understand, but are not amenable for analysis. 5. But a feature represents the intention of a concept. Therefore, a representation that can be analyzed A feature is a logically cohesive piece of without sacrificing understandability and usability functionality and is present in all phases of software is desirable. development. Features may occur at any level, for3. The UML diagrams [3] [18] [19]and UML profiles example high-level system requirements, [4] [5] model the static ACPs. The constraints in the architectural level, subsystem and component level. requirements are captured using OCL. The Thus, it is natural to expect that modularization of effectiveness of the UML as a standard is software into features can provide a lot advantages. predicated. Among other things, being a clear, ACPs which tend to be continual can be modeled precise, and pragmatic semantics for its notations is using feature modeling as the features reflect user an advantage. But the semi-formal semantics of requirements and can incrementally refine one UML has ambiguity and inconsistency issues. another. Moreover UML captures the static requirements www.ijorcs.org
  • 3. Can “Feature” be used to Model the Changing Access Control Policies? 23 The available approaches available for access features based approaches are more appropriate forcontrol modeling in the design phase could be modeling complex and dynamic access controlclassified into the following way as shown in figure 1. requirements modeling. Hence, the disadvantages of all the other approaches as a whole are explained and However, in this paper, the emphasis is on delving the subsequent discussion progresses with the featureinto the details of Feature Oriented modeling oriented modeling.approaches only. This is because, as mentioned earlier, Access control Policy Modeling at Design Phase Formal Logic HLL Model based approaches Process –Based Approaches UML Diagrams UML Patterns UML Profiles Aspects OCL and Class Secure Patterns Diagrams Features UML Template classes Usecase, Object, Class and Sequence diagrams Feature Meta-Model Feature as Patterns Figure 1: Classification of Different Approaches in ACP Modeling at Design Phase In the forthcoming sections, a preliminary future requirements, the integration of domain analysisintroduction to Feature, Feature modeling is given. activities with software development turned out to beFollowing is the brief explanation of TWO different necessary, both from a process and from the economicapproaches taken for modeling the ACPs using point of view. Ever since its introduction in 1990,Feature. From the Literature survey, it is noted that the feature modeling has attracted a great number ofFeature based modeling for ACPs is a new emerging application domains. And it becomes the most populararea of research and hence limited number of method of domain analysis with the development ofpublications are available. The Available publications domain engineering and product line.are either based on designing a Feature meta-model ortreating a Feature as a Pattern similar to UML. As the Secure Software development is increasingly underyears progress, many research works based on Feature the demands of unpredictable, diverse and growingwould be available. business requirements, as well as limited time-to- market, meticulous product value and mounting competition. The ACPs fall under this category can be III. FEATURES, FEATURE MODELING AND elegantly modeled with the FRs using feature 16B ACPS modeling Features are basic building blocks that satisfyintuitive user formulated requirements on the software − Feature Meta-modeling is a standard way ofsystem. They reflect user requirements and representing the ACPs as features and also providesincrementally refine one another. Feature model was a conceptual scheme to integrate the semiformalintroduced from the Feature-Oriented Domain requirements with the functional requirements.Analysis (FODA) methodology [22] and further − In the same lines, Patterns are also proved to be adeveloped from a number of approaches. wonderful tool for defining the ACPs. Feature models are used to represent the variability − Techniques like Ontological models and Case-baseand commonality of software product lines, and permit reasoning is also available as higher abstractthe configuration of specific applications. Hence it can structures.be defined as the activity of modeling the common andvariable properties of concepts [23]. For planning www.ijorcs.org
  • 4. 24 K.Shantha Kumari, Dr T.Chithralekha real time. Interactions between features are not In this paper, Features being an intention of concept considered in this approach.is modeled and discussed as Meta-models andPatterns. As mentioned earlier, being a novel thought, B. Pattern Based ACP Modeling approachesFeature based ACP modeling is carried out with thesetwo approaches only till now. The Following section A design pattern describes a generic solution to areviews the related work in both the approaches. recurring design problem. ACPs for any domain can be captivated in form for Access control patterns and canA. Meta-Model based ACPs Modeling Approaches be applied along with the software functional requirements. Whereas Meta-Model represents a high Meta-modeling in software engineering and level of abstraction of various models, the Patterns cansystems engineering among other disciplines, is the be defined as the solution to a repeated problem withanalysis, construction and development of the frames, respect to context. Just as Meta-model is tailored torules, constraints, models and theories applicable and domain specific requirements; patterns too can beuseful for modeling a predefined class of problems. A instantiated for a particular application. Features asmeta-model is yet another abstraction, highlighting Patterns and its structure can be represented usingproperties of the model itself. A model conforms to its Feature Modeling. Any Access control model’smeta-model. properties and characteristics can be defined using a− Using Meta-modeling concept, the ACPs can be declarative language such as OCL, when the Pattern is presented as a Feature along with their represented using UML. relationships, dependencies and constraints in a Research work available: The works defined in [[26], simple yet powerful way. The complexity and the [27], [28]] have done modeling of Access control dynamic nature of the ACPs can be captured and policies as patterns and configured with respective represented using composition and decomposition domain requirements. ACPs are conformed to RBAC relationships. model and then they are treated as a Pattern with OCL defined constrains. The works are briefly explained in− Any Access control requirement represented in the the following section: model that conforms to the meta-model ensures the 1. Any Policy is useful only, when it is appropriate at consistency between the FR and ACPs. For that particular instant. The work in [26] used this example, RBAC model can be used to represent the concept and presents a modeling approach that ACPs with respect to the meta-model. The Core configures ACP features on “Need Basis”. This RBAC and other forms of RBAC can be step-wise method produces Configured ACP features with refined. The RBAC requirements can be composed respect to the Application. ACPs are represented as with the domain requirements as per the RBAC features and they are composed with the composition relations described in the meta-model. FRs using “Partial Inheritance”. The RBACResearch work available: In this section, one of the features and the relationships are captured bypremier works done in modeling the access control Feature modeling and UML is used for specifyingrequirements using Feature Meta-model is reviewed. the RBAC features in a form of patterns. The partialThe work in [24] presents a feature-based Access inheritance of RBAC features enables step-wiseControl Requirements Modeling approach. The Access composition, which allows verification ofcontrol policy is unfolded as Access control immediate impact of selected features. The authorsrequirement in this approach. Access control use the Object Constraint Language (OCL) [29] torequirement and FRs are represented as AC-Feature define operation semantics. This approach enablesand F-Feature respectively. Any Access control model fine-grained configuration of RBAC at the featureincluding RBAC, DAC, and MAC is abstracted as level in a systematic manner, which helps to lowerACM-Feature. Any Access control requirement is development complexity and reduce potential errorsmodeled as a composition of ACM and F-Features. by excluding unnecessary features. . This workThe Composition relations are defined in the Feature didn’t represent all the properties of the Accessmeta-model. This helps to capture the model to which control model [RBAC] taken for representing thethe ACPs conform and also ensures the consistency ACPs.between FR and ACPs. This work adapts the Feature 2. The lacking factor of the previous work is resolvedmeta-model defined in [25]. The easy-to-tailor nature in [27]. The authors have extended to include theof the feature model can be used to elegantly control specification for the static separation of duty featurethe complexity and changefulness of ACPs. The and also updated the Core & General features withlacking factor of this approach is that, the relationships additional behaviors of RBAC. The completemodeled are very minimum, when compared to the www.ijorcs.org
  • 5. Can “Feature” be used to Model the Changing Access Control Policies? 25 profile of RBAC is represented as a Pattern. In this IV. DISCUSSION 17B pattern Core and non-core features are defined to From the early days, feature modeling is used in represent the basic and additional behaviour of the various application domains. It has become one of the Access control model. Along with Partial success methods of domain analysis with the inheritance, “Compatibility principle of design” is development of domain engineering and product line. used to check the Compatible features. This Also, enormous tool support is available. approach benefits most in-house development as it allows feature configuration in full scale to address In spite of their success, feature modeling has not the specific needs of the target system and seamless seen widespread adoption as a routine part of systems integration of configured RBAC into architecture. development practice. Previous surveys and our recent Still the privacy and temporal features have to be review indicate that there have been successes in the explored and also the systematic integration of application of feature models to problems of secure dynamic ACPs has to be addressed. software systems; yet have certain limitations too, which have to be researched further. This section3. All Access control models can be treated as provides valuable insights of every approach explained Patterns and the ACPs can be represented using earlier, through summarized overview and Qualitative those patterns. Hybrid Access control models were analysis. Also this paper tries to bring out the work proved to be effective in many instances. Hence still to be explored in ACP Modeling of feature they can also be represented as patterns to define modeling. ACPs of same kind. This thought was materialized in [28]. RBAC and MAC were considered in this In table 1, we revisit concerns raised in previous work. Similar to [27], the features are defined and surveys and identify progress, trends, and remaining configured with the application design on need challenges in the light of more recent projects through basis. “Homogeneous” and “Heterogeneous summary analysis. The summary includes the design Composition” are defined as Composition rules for of the features used in the method, the composition RBAC and MAC features. This approach enables techniques, the verification process, the representation fine-grained configuration of hybrid models of of ACPs in the proposed models and finally the RBAC and MAC at the feature level, which helps representation of relationships and dependencies. This reducing development complexity and errors by summary would highlight the application of Features excluding unnecessary features in early in representing the characteristics and properties of the development phase. Access control model taken for representing the ACPs of an application. Table 1: Summary of Contributions Approaches Meta-Model based Pattern Based ACPs modeling ACPs modeling Ref: [26] Ref: [27] Ref:[28] Parameters Ref: [24 ] How a Feature is Feature Meta- Patterns defined Model Access control RBAC RBAC RBAC RBAC & model used for MAC ACP representation. Definition of ACP ACP is defined as The Access control Model –RBAC is defined as a Access control Pattern. feature Features defined AC-Features Core Feature Core Feature Core Feature for representing F-Features Hierarchy Hierarchy feature Hierarchy the ACPs ACM-Features feature General feature feature General feature Advanced Feature General Advanced SOD Feature feature Feature Review feature Advanced SOD Feature Temporal feature Feature SOD Feature Refinement Decomposition, Refinement using Partial inheritance Relationships Specialization, [No Specialization] defined Characterization www.ijorcs.org
  • 6. 26 K.Shantha Kumari, Dr T.Chithralekha Representation of “Relationships” Class diagrams Refinement from UML core relationships package Dependencies Requires, excludes, Cardinality, Containment defined Complex constraints, Protection Representation of “Relationships” Sequence diagrams Dependencies from UML core package Interpretation of Using the Object Constraint Language relations, constraints Pre and Post-Conditions dependencies, constraints Feature interaction Behaviour and Not discussed Compatibility relation is a set of (1) or and behavior Interaction are relations (e.g., (SSD, DSD)) under the defined using the same branch, (2) relations of features constraints across branches that can be combined (e.g., (General, DSD)), and (3) implication dependencies. Composition Composition is Step-wise Composition using Partial Homogeneous techniques done through inheritance. Composition integration AC 1. Relationship composition Heterogeneous features with F- 2. Class Composition Composition Features using 3. Operation Composition relationships defined Representation of Feature Meta- Feature Composition is defined in terms of class Composition Model diagrams and sequence diagrams. Also, Feature process composition is the refinement in view of Multiple inheritances Verification Reference process Step-wise Composition and Configuration is the process is described as a verification process series of steps. Tool Support Not Available IBM Rational Software architect [RSA] and Eclipse plugin UML Support UML Core Meta- UML Class Diagrams and Sequence diagrams Model Meta-Model Yes NO Usage Reusable Features Yes Patterns can be configured based on the application Notation of Tree structure Class Diagrams Feature Model Role Hierarchies Easily The features have to configured depending upon the customizable needs Feature Conflicts They are not They are not analyzed and Interactions analyzed Following is the Qualitative analysis of the A. Factors that focus on representation of ACPs- 41Bapproaches for ACP modeling in table 2. An analytical Applicabilityframework is partially adapted from the work [30] and 1. Expressiveness [31]: Refers to the ability of[31] , that defines the following technical criteria is representing security policies as models. This is anused for analysis. Certain criteria are newly proposed important criterion that would make the modelingin this paper that would enhance the qualitative approach successful. Regarding this criterion, anyanalysis. specification approach will evaluated in expressing www.ijorcs.org
  • 7. Can “Feature” be used to Model the Changing Access Control Policies? 27 the kind of requirements and can take one of the 2. Usability: The usability principle measures how following values: simple or complex a technique can be used. In the context of evaluation, the amount of work involved − Static ACPs: if it allows the specification of the in applying the technique, gathering information majority of statically enforceable ACPs. and processing for output is considered. Once the − Dynamic ACPs: if it allows the specification of information is collected, how usable is the process the majority of dynamically enforceable ACPs. of designing a diagram, tree, or table. It can take the − Evolving ACPs: if it allows the specification of following values: majority of evolving new ACPs. − Difficult: if the modeling approach consists − Scalable ACPs: if it supports scalability of the difficult, long procedures/methodology ACPs. − Medium: if the approach consists of − All ACPs: if it supports all ACPs intermediate level of methodology with respect to time and work.2. Level of formality [30]: Refers to the ability to check the formality [Procedures] in Modeling − Simple: if the approach consists of simple approaches, to design and produce clear, reliable, methodology complete and provable Models for the expressed 3. Analyzability: The analyzability measures how ACPs. easily a developer can interpret and implement the − Clear design: if the procedure produce a results provided by the techniques. For example, unambiguous design whether the conflicts between the ACPs and FRs − Reliable design: if the procedure supports are modeled? Is it possible to verify the security consistent design assurance provided by the technique? − Complete design: if the approach produces a − Easy: Analysis of the Output of the Modeling complete model approach is Simple − Provable design: if the approach produces a − Difficult: if the output interpretation is difficult. model that can be verified. C. Factors that check the Verifiability of the Models3. Scope of specifications [30]: Refers to the ability of 43B produced by the approaches: representing both ACPs and FRs using same notations. It can be measured with the value 1. Support for Variations: Refers to the ability in “complete”. providing representations to show all possible variations and their output.4. Comprehensiveness: Refers to the ability to check whether the particular set of modeling notations and 2. Support for Consistency checking: A Modeling parameters including relationships are approach should produce a Model that allows comprehensive to represent the ACPs. This can take checking the consistency between the ACPs and the following values FRs composed together. Automatic internal verification supported by a technique may improve − Complete :if the approach can model all kinds of the reduction of ambiguity, ensure completeness, ACPs and relationships improve consistency, and hence, make − Incomplete: if the approach fails to capture specifications more verifiable. certain ACPs and their relationships. 3. Support for Correctness of Specification: It mayB. Factors that Focus on Usability of the Approaches: 42B ensure correctness of the design produced by the approach by validating it against requirements1. Learn ability: Refers to the ability of learning the and/or implementation. modeling approach and using it. It can take the following values: Table 2 allows us to relate Modeling approaches and specification technique criteria. We can see, for − Difficult : if the modeling approach is difficult instance, that the fulfillment of a technical criterion to learn and use for designing must generate the fulfillment of all Requirement − Medium: if the approach is learnable and usable criteria related to that criterion. The degree of after meticulous study and training fulfillment will be “Y” (Yes), “N” (No) or “P” − Simple: if the approach is suitable for usage (Partial). even for new users. www.ijorcs.org
  • 8. 28 K.Shantha Kumari, Dr T.Chithralekha Table 2: Qualitative Analysis of Features in ACPs modeling Technique Criterion Requirement Methodologies Criteria Meta-Model Pattern Based based modeling Modeling Expressiveness Static ACPs Y Y Dynamic ACPs P N Evolvable ACPs P N Scalable ACPs N N All ACPs N N Level of Formality Clear Y Y Reliable P Y Complete P P Provable P P Scope of Specification Complete P P Comprehensiveness Complete P P Incomplete Y Y Learn ability Difficult P P Medium Y Y Easy N N Usability Difficult P P Medium Y Y Easy N N Analyzability Difficult P P Easy P P Support for Variations - N N Support for Consistency - P P checking Support for Correctness - P P of specification V. INFERENCE 18B application. Hence the behaviour description is relevant when the feature is ready to compose with From Literature survey, Feature modeling using another in order to produce a model.Meta-Model or patterns was found to be optimal andefficient method that supports complex ACPs without 1. In both approaches, the feature is defined a typemuch cost and wastage of time. The Summary table that signifies how the feature adds up to thehighlighted the building blocks of each approach. All variability of the system. This confines thethe proposed ideas are very interesting and they prospects to reuse the same feature in aprovide important contributions to solve the security dissimilar perspective with different variabilityproblem in a methodological approach. Nevertheless, requirements. For E.g.: An Amount transferthey have a series of limitations. The performance of payment feature may be mandatory in oneeach approach is considered by the way, how the context while optional in another [dependingconcept of “Feature” is handled in modeling ACPs upon the target application]. As the type iswith FRs. inextricably associated with the feature, it will not be possible to reuse the feature as it is. The Comparative analysis is made with factorconcerning to the Usability, Applicability and 2. In both the approaches, the variant behaviour ofVerifiability of the approaches. The results are the feature is not explored completely. Theanalyzed with respect to the kind of feature and Feature behaviour is defined statically. Thisrelations defined in the techniques. reduces the purpose of reusability and also the support for variation.A. Feature Behaviour: A feature has the capacity to behave differently in several instances. This was B. Feature Relationships: Within a feature model the well illustrated in [23]. Feature behaviour or type features are structured by relations. Common to all determines the kind of variability provided at the methods mentioned above are hierarchical relations time of assembling with another feature in an between a feature and its sub features. They control www.ijorcs.org
  • 9. Can “Feature” be used to Model the Changing Access Control Policies? 29 the inclusion of features to instances. If an optional VI. CONCLUSION 19B feature is selected for an instance, then all mandatory sub-features have to be included as well, This paper explores the Feature modeling and optional sub-features can be included. approaches used for defining and integrating the ACPs with the functional requirements. Also it surveys the 1. The “Expressiveness” factor in the qualitative related state of the art. A detailed discussion for the comparison entirely depends on the kind of explained approaches was presented. This includes the relationships the approaches support. The concise review and the Comparative analysis of the Complex ACPs could not be expressed approaches. From this paper, it is understood that completely with the relationship set defined in features are efficient in modeling the ACPs when they both the approaches. tend to be complex. Two approaches based on features 2. The dependencies and the refinement were studied and analyzed. They present systematic relationships should be expanded to include the way for representing ACPs, yet have certain complex ACPs. limitations. Based on the limitations, there is a need for complete feature definition including moreC. Feature Conflicts and Interactions: A feature relationships and constraints that represent the real interaction occurs whenever one feature affects the time security requirements and their complexities. behaviour of another. The feature interaction Moreover, the Feature definition should also be able to problem is generally associated with conflicting manage the feature interactions and conflicts to features causing undesirable effects. The feature support the consistency. And, to increase the interaction problem is how to rapidly develop and variability options the type of the features has to be deploy new features without disrupting the defined separately from feature definition. This would functionality of existing features. So this concept support higher level of reusability and variation has direct relationship with Consistency between productions. The Step-wise refinement of features can the ACPs and FRs. From the summary, it was be strongly explored to adapt for complex and found that feature interactions were not handled in dynamic requirements. The main contribution of this both the approaches. Hence the support for work is the study and discussion of two important Consistency check is not completely defined in Feature modeling methodologies used for the both techniques. development of the software systems with the properD. Feature Decomposition: In both the approaches, the and systematic integration of ACPs. The major Features are represented in Top-down approach limitation of this [Hierarchical]. This poses a problem that the Work is the inadequate availability of research problem domain should be fully understood in works based on Feature. We reviewed available works prior, to be able to decompose into smaller in those methodologies and found the certain problems. This needs a combination of Top-down observations that would propel further research. and bottom up approach adaptation that could help in composing and reusing features from an existing and continuously growing storage of features. VII. REFERENCES 20B [1] G Georg, I Ray, and R France, "Using aspects to design aE. Functional and V ariability Decomposition: In the secure system," In Proceedings of the International feature models presented, the top down Conference on Engineering Complex Computing Systems decomposition is implicitly based on Functional (ICECCS 2002), Greenbelt, MD, ACM Press., 2002. doi: and Variability Decomposition. But they are not 10.1109/ICECCS.2002.1181504 clearly distinguished, so the modeling process has become very complex with respect to Consistency [2] T Doan, S Demurjian, C T Ting, and C Phillips, "RBAC/MAC security for UML," in Research factor. Directions in Data and Applications Security XVIII ,IFIPF. Scalability: Feature meta-model approach have International Federation for Information Processing significant characteristics to support Scalability of Volume 144. Catalonia, Spain: Springer, 2004, pp. 189- features, when compared to Pattern based Models. 203. But the tree structure used in Meta-Model based [3] D Kim, I Ray, R France, and N Li, "Modeling Role- ACP modeling would lose the added value of a Based Access Control Using Parameterized UML graphical representation when trees become very Models ," in FASE 2004, LNCS, vol. 2984, 2004, pp. large and easy over viewing is not possible. There 180–193. doi: 10.1007/978-3-540-24721-0_13 is a need for Suitable Abstraction. [4] J Jurjens, "UMLsec: Extending UML for Secure Systems Development," in Proceedings. of the 5th International Conference on t he UML, Dresden, Germany, 2002, pp. 412–425. doi: 10.1007/3-540-45800-X_32 www.ijorcs.org
  • 10. 30 K.Shantha Kumari, Dr T.Chithralekha [5] T Lodderstedt, D Basin, and J Doser, "Secureuml: A Models and Technologies(SACMAT), 2004, pp. 31-40. UML-based modeling language for model-driven doi: 10.1145/990036.990054 security," in Proceedings of the International [19] I Ray, N Li, D. K Kim, and R. B France, "Using Conference on t he Unified Modeling Language, parameterized UML to specify and compose access UML2002, 2002, pp. 426-441. control models," in Proceedings of the 6th IFIP TC-11 [6] T Priebe, E Fernandez, J Mehlau, and G Pernul, "A WG 11.5 Working Conference on Integrity and Internal Pattern System for Access Control," in Proceedings of Control in Information Systems, IICIS03, Lausanne, Conference on Data and Application Security, 2004, pp. Switzerland, (2003)., 2003. doi: 10.1007/1-4020-7901- 22–28. doi: 10.1007/1-4020-8128-6_16 X_4 [7] Steve Barker, "Security Policy Specification in Logic," [20] R Filman, T Elrad, S Clarke, and M. Aksit, Aspect- in Proceedings of the International Conference on Oriented Software Development.: Addison Artificial Intelligence,ICAI2000, Las Vegas, NV, 2000, Wesley.,ISBN-10: 0321219767 | ISBN-13: 978- pp. 143-148. 0321219763., 2000. [8] Steve Barker and Arnon Rosenthal, "Flexible security [21] D R Smith, "A Generative Approach to Aspect- policies in SQL," in Proceedings of the fifteenth annual Oriented Programming," in Proceedings of the Third working conference on D atabase and application International Conference on G enerative Programming security, Niagara, Ontario, Canada, 2001, pp. 167-180. and Component Engineering (GPCE’04), p. 2004. doi: [9] Elisa Bertino, Piero Andrea Bonatti, and Elena Ferrari, 10.1007/978-3-540-30175-2_3 "TRBAC: a temporal role-based access control model," [22] Kyo C. Kang et al., "FORM : A feature-oriented reuse in RBAC 00 Proceedings of the fifth ACM workshop on method,Volume 5," Annals of Software Engineering , Role-based access control, Berlin, Germany, 2000, pp. pp. 143 - 168, 1998. 21–30. doi: 10.1145/501978.501979 [23] L Abo Zaid, F Kleinermann, and O De Troyer, "Feature[10] Fang Chen and Ravi S. Sandhu, "Constraints for role- Assembly Framework: Towards Scalable and Reusable based access control," in RBAC 95 Proceedings of the Feature Models," in Proceedings of the 5th Workshop first ACM Workshop on R ole-based access control , on Variability Modeling of Software-Intensive Systems, 1995, p. Article No. 14. doi: 10.1145/270152.270177 Namur, Belgium, 2011, pp. 1-9.[11] R J Hayton, J M Bacon, and K Moody, "Access control [24] Lianshan Sun and Gang Huang, "Modeling Access in open distributed environment," in In IEEE Control Requirements in Feature Model," in APSEC 09 Symposium on Security and Privacy , Oakland, CA, Proceedings of the 2009 16th Asia-Pacific Software 1998, pp. 3–14. doi: 10.1109/SECPRI.1998.674819 Engineering Conference, Penang, 2009, pp. 241-248.[12] Michael Hitchens and Vijay Varadharajan, "Tower: A doi: 10.1109/APSEC.2009.21 Language for Role-Based Access Control," in POLICY [25] Hong Mei, Wei Zhang, and Haiyan Zhao, "A 01 Proceedings of the International Workshop on Metamodel for modeling system Features and their Policies for Distributed Systems and Networks, Bristol, refinement, constraint and interaction relationships," U.K. , 2001, pp. 88 - 106. doi: 10.1007/3-540-44569- Software and Systems Modeling 5(2), pp. 172-186, 2_6 2006. doi: 10.1007/s10270-006-0004-1[13] S Jajodia, P Samarati, and V S Subrahmanian, "A [26] Dae-Kyoo Kim, Lunjin Lu, and Sangsig Kim, "A Logical Language for Expressing Authorizations," in Verifiable Modeling Approach to Configurable Role- IEEE Symposium on Security and P rivacy, pages , Based Access Control," in Proceedings of Fundamental Oakland, CA, 1997, pp. 31–42. doi: Approaches to Software Engineering (FASE/ETAPS 10.1109/SECPRI.1997.601312 2010), Paphos, Cyprus, 2010, pp. 188-201. doi:[14] R Ortalo, "A Flexible Method for Information Systems 10.1007/978-3-642-12029-9_14 Security Policy Specification," in Proceedings of the [27] S Kim, D. K Kim, L Lu, S Kim, and S Park, "A 5th European Symposium on Research in Computer Feature-Based Approach for Modeling Role-Based Security, Louvain-la-Neuve, Belgium, 1998. doi: Access Control Systems;," Journal of Systems and 10.1007/BFb0055856 Software Vol. 84, No. 12, pp. 2035-2052, 2011. doi:[15] J A Hoagland, R Pandey, and K N Levitt, "Security 10.1016/j.jss.2011.03.084 Policy Specification Using a Graphical Approach," [28] S Kim, D.-K Kim, L Lu, S Park, and S Kim, "A Computer Science Department, University of Feature-Based Modeling Approach for Building Hybrid California, Davis., Technical Report 1998. Access Control Systems," in 5th International[16] OASIS. (2002). Available: http://www.oasis- Conference on Se cure Software Integration and open.org/committees/xacml. Reliability Improvement (SSIRI), Jeju, Korea, 2011, pp. 88-97. doi: 10.1109/SSIRI.2011.16[17] C Ribeiro, A Zuquete, and P Ferreira, "SPL: An Access Control Language for Security Policies with Complex [29] Gail-Joon Ahn and Michael E. Shin, "Role-Based Constraints," in roceedings of the Network and Authorization Constraints Specification Using Object Distributed System Security Symposium, San Diego, Constraint Language," in WETICE 01 Proceedings of CA, 2001. the 10th IEEE International Workshops on E nabling Technologies: Infrastructure for Collaborative[18] I Ray, N Li, R. B France, and D. K Kim, "Using UML Enterprises, Washington, DC, USA, 2001, pp. 157 – to visualize role-based access control constraints," in 162. Proceedings of the Symposium on A ccess Control www.ijorcs.org
  • 11. Can “Feature” be used to Model the Changing Access Control Policies? 31[30] A Khwaja and J Urban, "A Synthesis of evaluation criteria for software specifications and specification techniques," International Journal of Software Engineering and Knowledge Engineering, vol. 12 , no. 5, pp. 581–599, 2002. doi: 10.1142/S0218194002001062[31] C Talhi et al., "Usability of Security Specification Approaches for UML Design: A Survey," Journal of Object Technology, vol. 8, no. 6, pp. 103-122, 2009. doi: 10.5381/jot.2009.8.6.a1 How to cite K.Shantha Kumari, Dr T.Chithralekha, "Can “Feature” be used to Model the Changing Access Control Policies?". International Journal of Research in Computer Science, 2 (6): pp. 21-31, November 2012. doi:10.7815/ijorcs.26.2012.052 www.ijorcs.org