CHAPTER 6 A FLEXIBLE ACCESS CONTROL MECHANISM FOR WEB
6.4 I MPLEMENTATION R ESULTS
6.2 System Architecture
In this section, the framework of the proposed flexible access control mechanism is described. Figure 16 illustrates the proposed framework. The system encompasses two security functions: authentication and access control. In the authentication part, the proposed system implements mutual authentication between web server and requester. In the access control part, a new model is introduced. This model incorporates the RBAC model and a user profile-based access control model.
Figure 16. The framework of the proposed flexible access control mechanism
6.2.1 System Components
The system consists of three components: servers, databases, and subsystems.
There are two servers in the system. The web server provides all the services requested by the requesters. The certificate/role management server (C-RMS) is used to manage the security requirements for the web services. There are four types of databases. The certificate database (CERTDB) on the C-RMS is used to store the participants‟ certificates; the role database (ROLEDB) on the C-RMS is responsible for storing the roles associated with the participants; the user profile database
(PROFDB) on the web server is responsible for keeping the records related to the requesters‟ behavior; and the resources database (RESDB) on the web server is responsible for storing all the resources. In addition, there are six subsystems: the certificate management subsystem (CMS), the role management subsystem (RMS), the user authentication subsystem (UAS), the resource access control subsystem (RACS), the trust evaluation subsystem (TES), and the service provision subsystem (SPS).
(1) CMS: CMS is used to generate, revoke, and maintain certificates. A new user must register with C-RMS to get his/her certificate. Anyone querying others‟
certificates from the CERTDB does so via this subsystem. A certificate associated with a specific requester will be revoked if it is lost or expires.
(2) RMS: Users‟ roles are assigned after registration. RMS is responsible for generating, deleting, and maintaining the roles with respect to the corresponding users. The RBAC model is used to define the access policies for each role.
(3) UAS: UAS is used to authenticate the identities of communicators. It provides mutual authentication. It provides mutual authentication when a requester issues an access request to the web server. Both the requester and service provider exchange their certificates and verify the validity of the certificates exchanged. In this way, end to end authentication is confirmed, securing the system against forgery attacks.
(4) RACS: RACS is responsible for delivering a requester‟s access request, collecting the trust evaluation information, and sending evaluation results, which may cause an access privilege lower than his/her original, or may deny the access request if this request conflicts with the evaluation result after trust assessment. In addition, XACML is used to store the access policies.
(5) TES: TES is responsible for determining the requester‟s reputation value. The reputation value and its functions about the requester are calculated by the number of attacks, the number of failure requests, and the number of large packet deliveries.
(6) SPS: SPS is used to deliver the resources to the requesters according to the access policies kept in ROLEDB and PRFDB.
6.2.2 The System Workflow
The system workflow of the proposed mechanism has five steps: registration, role assignment, user authentication, resource access control and trust evaluation, and service delivery.
(1) Step1: Firstly, a user must register with C-RMS to get his/her certificate.
(2) Step2: The role is assigned according to the user‟s registration information.
(3) Step3: The user roams to a new location or domain, and he/she issues a request to access resources in the web service. The SSL-based authentication service is executed for confirming the identities of the two parties. In addition, if the requester has never been assigned a role, then step2 is executed.
(4) Step4: RACS collects the requester‟s profile including the requester‟s information and its location, etc. The subsystem asks the domain brokers that the requester has visited (current and prior) to calculate the requester‟s reputation information by using TES. RACS calculates the trust value of the requester according to the feedback reputation values from the domain brokers, and the trust values of the domain brokers. RACS writes them into PRFDB and adjusts the requester‟s access privileges according to the role and trust evaluation result.
(5) Step5: Web server adjusts the requester‟s access privileges according to its assigned role and trust evaluation result. SPS sends the resources complying with the current access policy.
6.3 The Proposed Flexible Access Control Mechanism
Both authentication and access control are security issues while designing web services. This section introduces how the proposed dissertation addresses these two areas.
The proposed mechanism supports mutual authentication. Mutual authentication is an authentication protocol which provides bidirectional identity verification. By this method, two communicators are able to confirm the identities of each other. In the proposed mechanism, certificate-based mutual authentication protocol is used.
Certificates are exchanged for authentication purposes. These certificates are signed and are verified by C-RMS and anyone.
Access control is an important mechanism which provides the right people with the right access to resources according to predefined access policies. XACML is one of the access control mechanisms, especially for XML security. Current XACML approaches do not consider location information, except GeoXACML [26]. However, the author does not take the reputation and trust value of the routing path into consideration. Therefore, this dissertation introduces a mechanism to incorporate the RBAC model, user profile, and XACML into web services. The locations in the proposed paper are separated by the routing domain. In other words, each cluster is a routing domain. Each domain has a broker to manage the reputation information about the users. Definition 6.1 shows that the network domains are completely separated and disjoined.
Definition 6.1: A group of domain set,
D{d1,d2,...,dk} , where k1 i
di
D
and
j
i d
d if i j.
In addition, each domain has a domain broker, bi, used to collect the distributed reputation ratings. A user provides the transaction rating to its broker after every transaction with any service in order to build up the reputation database on all services.
All users in the domain return observation results about others. By delegating trust management to brokers, the web service provider only needs to ask the brokers about the reputation of a requester before a transaction with it.
6.3.1 Reputation Management
A reputation management system can be classified by the following groups [58]:
Subjective vs. Objective, Transaction-based vs. Opinion-Based, Complete information vs. Localized information, and Rank-based vs. Threshold-based. This dissertation adopts hybrid subjective and objective, transaction-based, hybrid complete and localized information, and threshold-based in designing the reputation system. In addition, a successful reputation system should make it hard to build up good reputation so that a user is less likely to abuse his/her hard-earned reputation.
In this dissertation, there are three reputation functions that must be calculated:
the number of attacks (calculated by F(A) ), the number of failure requests (calculated by F(FR)), and the number of large packets delivery (calculated by
) PD (
F ). Reputation calculation for a transaction comes from two parts: direct
observation by the domain broker and indirect observation feedback from the domain users. Eq. (6.1) illustrates the reputation calculation for a single transaction about Ui
in domain di. Eq. (6.2) illustrates the reputation calculation about Ui in domain di. Eq. (6.3) illustrates the aggregated reputation about Ui. A threshold value is used to filter the aggregated reputation. If the value of the aggregated reputation is larger than that of the threshold, the web service provider will deny the request.
) reputation ratio, is a value which ranges from 0 to 1. If the value of q approaches 1, it implies that Ui loses his/her reputation rapidly if Ui does something bad. n is a parameter used for counting the number of events in any reputation function.
) same as the one in AREP, except with different functions. In RPTdi, the trust functions consists of the number of failure packets forwarded (calculated by F(FPF)), the number of incorrect routes (calculated by F(IR)), and the number of failure protections (calculated by F(FP)). Eq. (6.4) illustrates the reputation calculation for a single transaction about di by a web service. Eq. (6.5) illustrates the reputation calculation about di by a web service.
)
Finally, the trust value of the routing path, named RPT hereafter, is equivalent to
i di
RPT .
6.3.2 Flexible Access Control
The proposed flexible access control mechanism incorporates the RBAC and user profile-based access control models into a new model, which guarantees that any requester in any domain gains the appropriate access privilege when issuing a resource request. Definitions 6.2 to 6.5, define the relevant relation sets and the relationships among users, roles, and permissions. By these definitions, the access policies are generated and are parsed by XACML.
Definition 6.2: A group of role scheme set,
RS{RS1,RS2,...,RSm}Here, SLV, which ranges from 0 to 1, is the security level of the correspondence domain and determined by the web service provider; REP the reputation information;
AREPthe aggregated reputation information from the domains where the requester has been; and RPT the trust value of the routing path. Finally, a requester‟s profile is calculated by Eq. (6.4).
PRF RPT SLV ARET }
RPT , AREP , REP , SLV , Domain , User
{
(6.4)
Definition 6.5:
PRA is a relation, PRAPRMSROLESPRF . Relation PRAindicates that PRMSAssp(r,prf ){pPRMS|(p,r,prf)PA}.
Here, ROLESPRF is a role instance for a user. This definition defines the final permission for a requester while asking for a resource.
6.4 Implementation Results
In this section, both the implementation environment and results are described.
The OpenCA project [33] is used to generate, distribute, and maintain certificates.
Sun's XACML Implementation [50] is used to parse XACML. The JSP programming language is used to implement the system. Moreover, glassfish v3 is used as a container for web services. Figure 17 illustrates the implementation environment.
Figure 17. The implementation environment
We assume that there are five domains and twenty users in the environment.
Detailed implementation steps are presented in section 6.2.2. Figure 18 illustrates the table which the requester wants to access. In this table, there are seven fields. Figure 19 illustrates the implementation results after applying the RBAC model. This result shows that the requester in the fourth domain could gain access to all the fields in
Human Resource Database except the PWD field. Figure 20 illustrates the implementation results after applying the proposed flexible access control mechanism.
The requester now is in the second domain and he/she could gain access to four fields.
Obviously, the proposed mechanism has changed the requester‟s access privilege.
Figure 21 illustrates the system denying the requester‟s request when the reputation value is too low.
Figure 18. A table with 7 columns
Figure 19. The columns that the requester can get after applying the RBAC model
Figure 20. The columns that the requester can get after applying the flexible access control model
Figure 21. The requester‟s request is denied. (Threshold is 0.3)
6.5 Conclusion
To enable secure web service transactions to occur, an authentication protocol and access control mechanism must be added. This dissertation has shown that mutual authentication and a flexible access control mechanism can create a secure environment for web services. To provide flexible access control, the proposed mechanism integrates the RBAC model and a user profile-based access control model to dynamically adjust the requester‟s access privileges. A user‟s profile includes the reputation about the requester in the current domain, the aggregated reputation of the requester, the trust value of the route path, and the security level of the requester‟s current domain. Each domain has a broker to collect feedback from its users on past
transactions. The web service provider gathers these reputation values from the domains the requester has previously visited. It then determines the final access privilege using the proposed flexible access control mechanism. Finally, the requester receives the resources according to the new access policy. The implementation results show that the proposed mechanism is feasible.