Behavior-aware Service Access Control Mechanism using Security Policy Monitoring for SOA Systems

Changbo Ke; Guohua Shen; Senzhang Wang; Yunfei Meng; Yu Zhou; Zhiqiu Huang

REVIEW 4 major objections 5 minor 24 references

Behavior-aware Service Access Control Mechanism using Security Policy Monitoring for SOA Systems

T0 review · 4 major / 5 minor · reviewed 2026-08-14 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read A SOA system can stop insider attacks by checking every service call against a per-user trustful behavior model and ending sessions once measured risk crosses a threshold.

desk verdict A readable runtime-monitoring design for SOA access control whose central security claim is unsupported: the behavior elements are assumed trustworthy and the experiments only show thresholds firing as coded. read the letter →

arxiv 1908.10201 v1 pith:VVA4FI5Z submitted 2019-08-23 cs.CR

Yunfei Meng , Zhiqiu Huang , Senzhang Wang , Yu Zhou , Guohua Shen , Changbo Ke This is my paper · ORCID

classification cs.CR

keywords service-orientedarchitectureaccesscontrolruntimemonitoringtrustfulbehaviormodelsecuritypolicyinsiderattackriskmeasurementSOA

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper tries to establish that a SOA system can defend against insider attacks—authorized users who abuse their access—by monitoring behavior at runtime, not just checking identity at login. It proposes a monitor that receives behavior elements collected by checkpoints embedded in service interfaces, and it converts the service provider's release policy into per-user trustful behavior models (TBMs). If a consumer's request does not match their TBM, the monitor denies it; if measured unauthorized-access risk or access-frequency risk crosses a threshold, the session is terminated early, and simultaneous UAR and AFR trigger blacklisting. A prototype with JSP services and a Java Session Bean monitor shows that only TBM-matching requests are answered, that threshold crossings stop access, and that adding rules to the TBM grows response time roughly linearly.

What carries the argument

The central mechanism is the trustful behavior model (TBM), a set of rules $\langle Id, Src, Dst \rangle$ generated from the service releasing model: each rule says that a consumer with a given identity may move from a current service URI to a target service URI. Alongside the TBM, checkpoints embedded in each service interface collect behavior elements (identity, current URI, target URI, timestamps, access counts) and send them to the monitor. The behavior-aware access control algorithm checks each request against the TBM, then evaluates risk measurement functions—unauthorized access risk (UAR), access retention risk (ARR), and access frequency risk (AFR)—and uses a threshold comparison $PF(R(e_i, t_i)) \in \{0,1\}$ to decide between returning the service interface, denying the request, terminating the session, or blacklisting the consumer.

What would settle it

Set up the same prototype with a consumer who can call a sensitive service's endpoint directly, bypassing the checkpoint JSP, or who can replay another consumer's behavior elements; if such requests are served and the monitor logs nothing, the claim that the mechanism can effectively monitor consumer behaviors at runtime is refuted.

Watch

Extended reading notes

Core claim

On the paper's own terms, the central claim is that adding a monitor—fed by checkpoints embedded in every service interface—to a single-trust-domain SOA system lets the service provider enforce per-consumer trustful behavior models: a request that does not match the consumer's TBM is denied, and when accumulated unauthorized-access risk (UAR) or access-frequency risk (AFR) exceeds a provider-set threshold, the consumer's session is terminated early. A consumer who crosses both UAR and AFR at the same time is added to a blacklist and barred from future sessions. The prototype evaluation is presented as evidence that the mechanism can monitor consumer behaviors in run time, respond when malicious behavior really occurs, and still perform acceptably as the TBM rule count grows.

Load-bearing premise

The mechanism assumes that every service invocation flows through the checkpoint scripts and that the behavior elements they collect (identity, current URI, target URI, timestamps, access counts) are authentic and cannot be spoofed, replayed, or bypassed.

Editorial extensions

If this is right

If the mechanism works as claimed, a service provider can set per-consumer release policies and have them enforced continuously at runtime, so an authorized user who tries to reach a service outside their TBM gets no response.
Once a consumer's unauthorized-access attempts or request frequency exceeds the provider-set threshold, the session is cut short before further damage, stopping high-frequency scraping or repeated probes of sensitive services mid-session.
A consumer who simultaneously exceeds both unauthorized-access and frequency thresholds is blacklisted permanently, preventing repeat insider attempts in later sessions.
Because TBM growth causes only a near-linear increase in response time, the mechanism can scale to larger SOA systems with more services and routes without a dramatic slowdown.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

The same checkpoint-and-TBM pattern could extend to multi-trust-domain SOA by having each provider publish its own TBM and having monitors validate cross-domain calls, though the paper explicitly leaves multi-domain monitoring as future work.
The risk model only counts unauthorized attempts and access frequency; adding behavior elements such as data volume or operation type would catch slow, low-frequency data exfiltration that the current thresholds miss.
Because non-matching requests are denied before being served, each UAR increment can double as forensic evidence: repeated failed attempts reveal which sensitive services a consumer probes, even when no single threshold is crossed.

Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

Dear colleague,

The paper proposes a runtime monitoring mechanism for SOA access control. The genuinely new part is converting a P-Spec service releasing policy into per-user transition rules (TBM) and then checking every request against those rules. That idea is legible, and the prototype demonstrates that requests are blocked when they do not match the TBM, provided they actually go through the checkpoint path. The performance scaling test is a reasonable microbenchmark.

The problems are in the security claims. The biggest one, correctly flagged by the stress-test note, is that the behavior elements the monitor trusts are never authenticated or bound to server-side state. Checkpoints are scripts embedded in service interfaces; the collection and transmission of {eid, esrc, edst} is assumed reliable. Since the attack model is an authorized insider, that assumption is exactly what you cannot make. A user who can call a service endpoint directly, or spoof the current-service URI, bypasses the monitor entirely. The evaluation never tries that; it only sends requests through the happy path.

Second, the detection logic is circular. Definitions 14 and 15 define malicious behavior as accumulated risk exceeding a manually set threshold, and Section 4.2.2 shows that when the threshold is exceeded, the session terminates. That is the mechanism working as coded, not evidence that it detects misuse. There is no baseline, no attack scenario, no comparison with existing monitoring approaches.

There are also smaller issues a referee would flag: inconsistent terminology (UAF vs UAR), equation (4) is a placeholder, and the figure numbering is off (text cites Figures 7–12 while captions say Figure 1–6). These are fixable but show the paper was not polished.

The citation pattern is fine; it correctly surveys BPMN monitoring, BAM, interceptors, and framework-based approaches, and the self-citation to P-Spec is legitimate since that policy language is reused.

Who is this for? A reader interested in a concrete TBM-based access control design and a prototype might get something, but the paper's central claim about effective runtime response is not established. I would not cite it as a security solution.

Recommendation: reject. If the authors add an explicit trust/integrity model for the behavior elements (e.g., collecting data at the container level, authenticating requests) and evaluate against adversarial scenarios, it could become a solid workshop paper, but the current version does not support the headline claim.

Referee Report

4 major / 5 minor

Summary. The paper proposes a behavior-aware access control mechanism for single-trust-domain SOA systems. The service provider defines a service releasing policy (SRM), which is converted into per-consumer trustful behavior models (TBM) consisting of allowed transitions between service URIs. A monitor receives behavior elements collected by checkpoint scripts embedded in service interfaces, denies requests that do not match TBM, and computes risk scores UAR and AFR; if the risk evidence PF equals 1, the consumer's session is terminated or the consumer is blacklisted. The authors implement a Java/Tomcat prototype and report experiments on user-behavior supervision, dynamic access authorization, and response-time scaling with TBM size, concluding that the mechanism effectively monitors consumers and responds to malicious behavior in run time.

Significance. The TBM idea of converting a releasing policy into explicit allowed-transition rules is a reasonable and potentially useful way to express fine-grained behavioral policy for SOA, and the paper gives a systematic formal apparatus for that conversion. The prototype and the basic observation that response time grows roughly linearly with TBM size are also useful. However, the central claim that the mechanism can effectively detect and respond to malicious insider behavior is not established: the threat model is incomplete, the risk evaluation is definitionally tied to the enforcement threshold, and the formal definitions contain gaps that prevent verification. If the trust and evaluation issues were fixed, the contribution could be a solid systems paper on threshold-based behavioral enforcement; as submitted, the evidence supports only the narrower claim that requests outside TBM are refused and sessions are terminated after a preset counter or frequency threshold is exceeded.

major comments (4)

[§3.1, §3.5] The runtime detection depends entirely on behavior elements collected by checkpoint scripts embedded in service interfaces and sent to the monitor, but the paper never specifies how these elements are authenticated, bound to server-side state, or protected from forgery. A malicious consumer could invoke a service endpoint directly without passing through the checkpoint, or could supply forged eid/esrc/edst values, and the monitor would see nothing or see a compliant transition. The single-trust-domain restriction in Section 2 does not remove this threat because the adversary the mechanism is designed to police is the authorized insider. The paper needs an explicit trust and integrity model, and the evaluation in Section 4 needs at least one scenario that attempts to bypass or forge the collected behavior elements.
[§3.4, §4.2.2] Risk evaluation is defined in Definitions 14 and 15 and Equation (10) so that PF=1 exactly when accumulated risk exceeds a preset threshold, and the dynamic-authorization evaluation in Section 4.2.2 sets theta(UAR)=1000 and theta(AFR)=350/min and then reports that the session is terminated when those thresholds are crossed. The 'detection' experiment therefore verifies the enforcement predicate by construction rather than testing whether malicious behavior is recognized. The paper should either evaluate against independently labeled attack behaviors and report false positives and false negatives, or explicitly reframe the contribution as threshold-based behavioral enforcement rather than malicious-behavior detection.
[§3.4, §3.5] The risk model is not fully specified and contains inconsistencies that prevent a correctness check. Equation (4) defines the new risk as F(e_i, t_i) without ever defining F; Definition 11 defines UAF while the algorithm in Section 3.5 uses UAR without giving its definition; Section 3.5 contains the malformed expression 'P F(R(AF R)' rather than PF(AFR); and initial values for R(A, t_0) and R(e_t, t_0) are never given. A complete and computable definition of each risk measure, including initial conditions and update rules, is needed before the algorithm's behavior can be verified.
[§4.2] The experimental evaluation exercises only the normal request path within the prototype: requests are generated against the intended interfaces, and no test tries to spoof behavior elements, call a service directly, replay another user's session, exceed permissions in a realistic attack pattern, or otherwise evade the checkpoint. Consequently the experiments cannot support the abstract's claim that the mechanism 'can effectively monitor consumer's behaviors and make effective responses when malicious behaviors really occur in run time.' In addition, the figure captions in Section 4 are numbered Figure 1-6 while the text refers to Figures 7-12, and the performance evaluation in Section 4.2.3 uses five repeats without reporting variance or confidence intervals.

minor comments (5)

[§4.1] The text refers to 'the behavior-aware access control algorithm mentioned in section 4.5'; the algorithm is actually in Section 3.5.
[Definition 9] Definition 9 says behavior elements are 'environment variables' but does not explain how these variables are populated, which of them come from the client, and which are determined by the server; this is directly relevant to the trust-model concern.
[Definition 11] There is a typo in Definition 11: 'eid is SC's identify' should be 'eid is SC's identity.'
[Section 5] Reference [16] appears twice in the same sentence, and several references, including [8], are incomplete or missing author information.
[Equation (2)] The symbol t_i is used for both a transition and a time index in Definitions 7 and 10, which makes the formalism harder to follow and should be disambiguated.

Circularity Check

1 steps flagged · score 6.0 of 10

The 'malicious behavior detection' result reduces by construction to a hand-set threshold, making the central evaluation claim definitional rather than empirical.

self definitional [Section 3.4 (Definitions 14-15, Eq. (9)-(10)), Section 3.5 algorithm, Section 4.2.2 evaluation]
"E(R(ei, ti)) = 1 − θ(ei)/R(ei, ti) (9) ... P F(R(ei, ti)) = { 1, E(R(ei, ti)) > 0; 0, E(R(ei, ti)) ≤ 0 } (10). ... We set the threshold of UAR to 1000 times, i.e., θ(UAR)=1000, which implies that the SC's access authorization will be early terminated in this session when his or her unauthorized access times exceeds 1000 times."

By Eq. (9)-(10), PF(R)=1 is algebraically equivalent to R(ei,ti)>θ(ei); the access-control algorithm terminates the session exactly when PF(UAR)=1 or PF(AFR)=1. The experiment defines 'malicious behavior' as the condition that the unauthorized-access count exceeds the hand-set threshold of 1000 (or the frequency exceeds 350/min). Observing termination under that condition is therefore a restatement of the defining equation, not an independent empirical confirmation that the mechanism detects malicious behavior. The conclusion that the mechanism 'can effectively detect malicious behaviors' reduces to the threshold chosen by the designer.

full rationale

The paper's derivation chain for the risk-evidence predicate is self-contained but definitional: risk R is accumulated by the formulas in Definitions 11-13, and risk evidence PF is defined via a threshold comparison, so the algorithm's response is determined by the same inequality used to define 'malicious'. Consequently, the Section 4.2.2 results demonstrate that the prototype implements Eq. (10), but they cannot validate the stronger claim of effective detection of malicious insider behavior independently of the hand-set thresholds. The TBM-based request filtering in Section 4.2.1 is likewise an enforcement check of the algorithm's own deny rule, although this is a normal conformance test. The self-citation of P-Spec [11] in Section 3.2 is a minor reuse of the authors' own policy language; since Definition 4 supplies the actual grammar used, this citation is not load-bearing for the result. No fitted parameters are passed off as predictions, and no uniqueness theorem is imported from the authors' prior work. Overall, the central 'detection' claim is partially circular because the measured outcome is equivalent by construction to the threshold input, warranting a score of 6 rather than a higher score.

Assumptions & free parameters 2 free parameters · 5 assumptions · 0 invented entities

The central claim rests on a single trust domain, tamper-proof behavior collection, reliable consumer authentication, and hand-set risk thresholds. The TBM conversion assumes the route graph captures all legitimate usage. The most consequential ledger item is the threshold set, because 'malicious' is defined by crossing it and the evaluation only demonstrates that crossing a threshold triggers termination.

free parameters (2)

UAR threshold theta(UAR) = 1000 unauthorized accesses
Set by hand in Section 4.2.2; no derivation or sensitivity analysis, and 'malicious' is defined by crossing it.
AFR threshold theta(AFR) = 350 accesses per minute
Set by hand in Section 4.2.2; no basis in workload or attack model; detection depends entirely on this value.

assumptions (5)

domain assumption Single trust domain: one service provider owns and defines security policy for the entire SOA system
Section 2 opens with this restriction; the conclusion acknowledges multi-domain case is future work.
domain assumption Service calls are routed through embedded check points and the monitor sees all behavior elements
Section 3.1 describes check point script in each service interface; no mechanism to prevent direct invocation, proxy bypass, or spoofed identity/location/IP.
domain assumption Consumer identity and private key CK_i provide reliable authentication
Definitions 1-4 assume SC identity and private key; no key management or replay protection is specified.
ad hoc to paper The TBM conversion from SRM to transition rules preserves all relevant allowed behavior
Definition 7 builds rules from routes I0 to Xk; if legitimate usage requires routes not captured by the graph, those uses are incorrectly denied. The conversion assumes the route set is complete and unique.
ad hoc to paper Risk thresholds theta(ei) can be set to separate malicious from benign behavior
Definitions 14-15 define malicious as risk above threshold; selecting thresholds in the experiments sets the outcome by construction.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Behavior-aware Service Access Control Mechanism using Security Policy Monitoring for SOA Systems." pith.science (2026). https://pith.science/paper/VVA4FI5Z

@misc{pith2026190810201,
  author       = {Pith},
  title        = {Pith review of: Behavior-aware Service Access Control Mechanism using Security Policy Monitoring for SOA Systems},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/VVA4FI5Z}},
  note         = {Machine review of arXiv:1908.10201}
}

read the original abstract

Service-oriented architecture (SOA) system has been widely utilized at many present business areas. However, SOA system is loosely coupled with multiple services and lacks the relevant security protection mechanisms, thus it can easily be attacked by unauthorized access and information theft. The existed access control mechanism can only prevent unauthorized users from accessing the system, but they can not prevent those authorized users (insiders) from attacking the system. To address this problem, we propose a behavior-aware service access control mechanism using security policy monitoring for SOA system. In our mechanism, a monitor program can supervise consumer's behaviors in run time. By means of trustful behavior model (TBM), if finding the consumer's behavior is of misusing, the monitor will deny its request. If finding the consumer's behavior is of malicious, the monitor will early terminate the consumer's access authorizations in this session or add the consumer into the Blacklist, whereby the consumer will not access the system from then on. In order to evaluate the feasibility of proposed mechanism, we implement a prototype system. The final results illustrate that our mechanism can effectively monitor consumer's behaviors and make effective responses when malicious behaviors really occur in run time. Moreover, as increasing the rule's number in TBM continuously, our mechanism can still work well.

Figures

Figures reproduced from arXiv: 1908.10201 by the authors.

**Figure 2.** User behavior supervision evaluation under [PITH_FULL_IMAGE:figures/full_fig_p011_2.png] view at source ↗

**Figure 3.** Dynamic access authorization evaluation under [PITH_FULL_IMAGE:figures/full_fig_p012_3.png] view at source ↗

Figures from the paper (3 more)

**Figure 4.** Figure 4: Dynamic access authorization evaluation under [PITH_FULL_IMAGE:figures/full_fig_p013_4.png]

**Figure 5.** Figure 5: Dynamic access authorization evaluation under [PITH_FULL_IMAGE:figures/full_fig_p013_5.png]

**Figure 6.** Figure 6: Performance evaluation of accessing Service 1 und [PITH_FULL_IMAGE:figures/full_fig_p014_6.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

24 extracted references · 24 canonical work pages

[1]

Arsanjani, L

A. Arsanjani, L. J. Zhang, M. Ellis, A. Allam, K. Channabasavaiah, A service-oriented reference architecture, It Professional 9 (3 ) (2007) 10–17

work page 2007
[2]

C. Momm, M. Gebhart, S. Abeck, A model-driven approach for mo nitor- ing business performance in web service compositions, in: Internat ional Conference on Internet and Web Applications and Services, 2009. 16

work page 2009
[3]

Guinard, V

D. Guinard, V. Trifa, S. Karnouskos, P. Spiess, D. Savio, Inter acting with the soa-based internet of things: Discovery, query, selectio n, and on-demand provisioning of web services, IEEE Transactions on Ser vices Computing 3 (3) (2010) 223–235

work page 2010
[4]

I. R. Chen, J. Guo, F. Bao, Trust management for soa-based io t and its ap- plication to service composition, IEEE Transactions on Services Com puting 9 (3) (2017) 482–495

work page 2017
[5]

X. Ning, J. Ma, S. Cong, Z. Tao, Decentralized information ﬂow ve riﬁ- cation framework for the service chain composition in mobile computin g environments, in: IEEE International Conference on Web Service s, 2013

work page 2013
[6]

W. J. Tolone, G. J. Ahn, T. Pai, S. P. Hong, Access control in colla borative systems, Acm Computing Surveys 37 (1) (2005) 29–41

work page 2005
[7]

Wonohoesodo, Z

R. Wonohoesodo, Z. Tari, A role based access control for web s ervices, in: IEEE International Conference on Services Computing, 2004

work page 2004
[8]

M. B. Salem, S. Hershkop, S. J. Stolfo, A Survey of Insider Atta ck Detection Research, 2008

work page 2008

Show all 24 references

[9]

T. S. Cook, D. Drusinksy, M. T. Shing, Speciﬁcation, validation an d run- time monitoring of soa based system-of-systems temporal behav iors, in: IEEE International Conference on System of Systems Engineerin g, 2007

2007
[10]

Drusinsky, G

D. Drusinsky, G. Watney, Applying run-time monitoring to the de ep- impact fault protection engine, in: Software Engineering Workshop , 2003

2003
[11]

Y. Meng, Z. Huang, Z. Yu, C. Ke, Privacy-aware cloud service s election approach based on p-spec policy models and privacy sensitivities, Fu ture Generation Computer Systems 86 (2018) 1–11

2018
[12]

URL http://www.omg.org/spec/BPMN/2.0/

OMG, Business process model and notation (bpmn) version 2.0 ( 2011). URL http://www.omg.org/spec/BPMN/2.0/

2011
[13]

Rademakers, R

T. Rademakers, R. V. Liempd, Activiti in action: Executable bus iness processes in bpmn 2.0
[14]

Baresi, S

L. Baresi, S. Guinea, O. Nano, G. Spanoudakis, Comprehensive monitoring of bpel processes, IEEE Internet Computing 14 (3) (2010) 50–5 7

2010
[15]

Zhang, Z

H. Zhang, Z. Shao, Z. Hong, Runtime monitoring web services imp lemented in bpel, in: International Conference on Uncertainty Reasoning an d Knowl- edge Engineering, 2011

2011
[16]

G. Wu, J. Wei, T. Huang, Flexible pattern monitoring for ws-bpel through stateful aspect extension, in: IEEE International Conference on Web Ser- vices, 2008. 17

2008
[17]

M. Asim, A. Yautsiukhin, A. D. Brucker, B. Lempereur, Q. Shi, S ecurity Policy Monitoring of Composite Services, 2014

2014
[18]

Wetzstein, S

B. Wetzstein, S. Strauch, F. Leymann, Measuring performan ce metrics of ws-bpel service compositions, in: International Conference on N etworking and Services, 2009

2009
[19]

T. Ou, S. Wei, C. Guo, L. Jing, Visualized monitoring of virtual bus iness process for soa, in: IEEE International Conference on E-busine ss Engineer- ing, 2008

2008
[20]

Barbon, P

F. Barbon, P. Traverso, M. Pistore, M. Trainotti, Run-time mo nitoring of instances and classes of web service compositions, in: IEEE Intern ational Conference on Web Services, 2006

2006
[21]

Baresi, S

L. Baresi, S. Guinea, Dynamo: Dynamic monitoring of ws-bpel pr ocesses, in: International Conference on Service-oriented Computing, 20 05
[22]

Zmuda, M

D. Zmuda, M. Psiuk, K. Zielinski, Dynamic monitoring framework fo r the soa execution environment, Procedia Computer Science 1 (1) (201 0) 125– 133
[23]

N. E. Ioini, A. Garibbo, A. Sillitti, G. Succi, An Open Source Monitor ing Framework for Enterprise SOA, 2013

2013
[24]

C. Chen, A. Zaidman, H. G. Gross, A framework-based runtime monitoring approach for service-oriented software systems, in: Internat ional Workshop on Quality Assurance for Service-based Applications, 2011. 18

2011

Pith tools

Reviewed August 14, 2026 · model on record in the stance chip above.

[1] [1]

Arsanjani, L

A. Arsanjani, L. J. Zhang, M. Ellis, A. Allam, K. Channabasavaiah, A service-oriented reference architecture, It Professional 9 (3 ) (2007) 10–17

work page 2007

[2] [2]

C. Momm, M. Gebhart, S. Abeck, A model-driven approach for mo nitor- ing business performance in web service compositions, in: Internat ional Conference on Internet and Web Applications and Services, 2009. 16

work page 2009

[3] [3]

Guinard, V

D. Guinard, V. Trifa, S. Karnouskos, P. Spiess, D. Savio, Inter acting with the soa-based internet of things: Discovery, query, selectio n, and on-demand provisioning of web services, IEEE Transactions on Ser vices Computing 3 (3) (2010) 223–235

work page 2010

[4] [4]

I. R. Chen, J. Guo, F. Bao, Trust management for soa-based io t and its ap- plication to service composition, IEEE Transactions on Services Com puting 9 (3) (2017) 482–495

work page 2017

[5] [5]

X. Ning, J. Ma, S. Cong, Z. Tao, Decentralized information ﬂow ve riﬁ- cation framework for the service chain composition in mobile computin g environments, in: IEEE International Conference on Web Service s, 2013

work page 2013

[6] [6]

W. J. Tolone, G. J. Ahn, T. Pai, S. P. Hong, Access control in colla borative systems, Acm Computing Surveys 37 (1) (2005) 29–41

work page 2005

[7] [7]

Wonohoesodo, Z

R. Wonohoesodo, Z. Tari, A role based access control for web s ervices, in: IEEE International Conference on Services Computing, 2004

work page 2004

[8] [8]

M. B. Salem, S. Hershkop, S. J. Stolfo, A Survey of Insider Atta ck Detection Research, 2008

work page 2008