A REUSABLE INTELLIGENT AUTHORIZATION DESIGN FOR
WEB SERVICES SOFTWARE SECURITY
Weider D. Yu, Archana Mansukhani
Computer Engineering Department, San Jose State University, San Jose, California, 95192-0180, USA
Keywords: Web Services, authorization layer, security, inference engine, reusability, Service Oriented Architecture
(SOA), expert system rules.
Abstract: Web services are a new way of thinking in distributed computing. They are an important step towards
service-oriented architecture (SOA). Web services are used to obtain service in an open, platform
independent way. Recent focus on web services has been in the area of security, which is an ongoing
concern in many areas and is very pertinent to web services technology. This paper describes the design of a
reusable authorization layer for web services software. This layer resides separate from the web services
themselves and uses a rule based inference engine for determining authorization and access rights. It also
uses different types of access control to formulate feature-rich rules.
1 INTRODUCTION
The industry has seen a rapid growth in web services
security since the beginning of 2004. Many new
standards have been established to deal with various
aspects of security. OASIS (Organization for the
Advancement of Structured Information Standards)
has defined several standards for web services
security. Two of the standards are relevant to
authorization: XACML (XML Access Control
Markup Language) which is a language for
specifying access control rules and policies, and
SAML (Security Assertions Markup Language),
which is a protocol for specifying authentication and
authorization. However, there are no standards exist,
for defining an authorization framework for web
services. The expected WS-Authorization standard
is still under observation.
This paper proposes a reusable authorization
layer, which is separate from the web services
themselves. All web services requests pass through
the authorization layer. An authorization decision is
made at this layer and passed onto the web services
(Alotaiby, Chen, 2004), (Chaari, 2004).
This paper proposes to use logic rules in
determining access rights. A logic based inference
engine is used in determining the outcome of each
authorization decision. Rules are fired depending on
the facts and conditions for an authorization request.
Using this approach effectively establishes a
separate authorization layer at which authorization
decisions are made. Furthermore, the framework of
the authorization layer can be reused in multiple web
services in order to service various authorization
needs.
2 AUTHORIZATION LAYER
The purpose of this research work is to design a new
architectural framework to provide authorization
functionality. Although authentication is an
important step towards authorization, strict
authentication is assumed to be available and it is
outside of the scope of this paper.
Figure 1 shows an overview of the architectural
framework of the system. It is assumed that web
services requests are authenticated before being
processed by the authorization layer. The main goal
of this design is to separate all authorization related
functionalities so that they can be designed and
implemented independently from the rest of the web
services implementation. This enables the reusability
of authorization functionality.
The authorization layer parses the incoming web
service request and produces various parameter data
required for authorization. It then formats the input
data into the appropriate type required by the
inference engine. The inference engine uses the
input and its authorization rules to determine the
298
D. Yu W. and Mansukhani A. (2005).
A REUSABLE INTELLIGENT AUTHORIZATION DESIGN FOR WEB SERVICES SOFTWARE SECURITY.
In Proceedings of the Second International Conference on e-Business and Telecommunication Networks, pages 298-303
DOI: 10.5220/0001408202980303
Copyright
c
SciTePress
appropriate access rights for the request. A set of
authorization rules is used to determine which user
or service can access what component or service
(Chandramouli, 2001), (Indrakanti, 2004).
2.1 Language syntax for specifying
Authorization rules
The authorization rules in the approach are specified
using a special functional language of predicate
calculus type. Some common notations are used.
is the universal qualifier and indicates for all or for
every instance. is the existential qualifier and
indicates that there exists at least one instance. The
symbol indicates that there is an if-then
relationship.
Figure 1: System Architecture
If a company employee as a client user wants to
connect to his/her company computer from outside
the company environment, then the client’s role is
changed from on_site employee to off_site employee,
and the client’s access rights to certain resources are
modified based on the policy of the company’s off-
site employee access rights. These policies are
company dependent. The rules for specifying such
access restriction are expressed as:
x [on_site_emp(x) access(E)]
x [off_site_emp(x) access(E’)]
where on_site_emp(x) is a predicate for x is an
on_site employee. access(E) is a relationship
between the employee x and the component E that
implies that the employee x is authorized to access
the resource component E (and the resource
component E’ is a subset of E). In this case, the
resources in the company are represented by
components.
The factual data required to support the predicate
must be analyzed and the employee status is
determined during the authentication stage. This
information is passed on to the authorization layer or
it must be included in the SOAP (Simple Object
Access Protocol) request received at the
authorization layer.
In another example, the rule below is for some
off_site employees who have unrestricted access
rights to the resource component E:
y [off_site_emp(y) access(E)]
2.2 Data for Authorization
Certain client or user related data are required from a
web service request to make authorization decisions.
Such data may be user or service id, role used for
accessing the service, team to which the user
belongs, task being worked on by the user, and
certain other data related to the particular service.
The data required depends on the authorization
types supported. This kind of data may be either
directly obtained from the requesting client or
obtained via an XML schema for the clients web
service SOAP request. The security of the data must
be enforced against malicious intruders.
3 MAJOR DEVELOPMENT
BENEFITS
Several major benefits can be achieved with the
approach:
Using an expert systems shell allows greater
flexibility in defining rules. Authorization
designers can use rule-oriented facilities
provided by the shell to define and manage
authorization rules. Without this, it is a
cumbersome task to manage rules using a
database and no tools.
HTTP/SOAP
Parser &
Parameters
Authorization Rules
Web Services
Methods
Web Service
Inference Engine
Authorization Layer
Main Functions
A REUSABLE INTELLIGENT AUTHORIZATION DESIGN FOR WEB SERVICES SOFTWARE SECURITY
299
Access control using rules fits naturally into
the conceptual framework of the expert
system shells whereby rules are “fired”
depending on existing facts. These facts can
relate to roles, location, user, requesting
service, task, context, team, time and so on
(Mattas, 2003), (Motta, Furuie, 2003),
(Moyer, Abamad, 2001).
Authorization rules become portable. They
can easily be ported and used in other web
services for similar types of access.
Separating the rule definitions as well as
execution from the underlying services
effectively separates the authorization layer
thus rendering it reusable and extendable.
4 ARCHITECTURAL DESIGN
AND IMPLEMENTATION
The web services example described in section 2.1
was implemented using the proposed architectural
design. A short description of the web services
example is given below.
4.1 Resource Components Used in a
Case Study
A company, AMS Inc., wants to use the Service
Oriented Architecture (SOA) concept to deploy
certain internal intra-company services as well as its
external commercial services via web services. The
company also wants to make part of its ERP
(Enterprise Resource Planning) system available in
the web services.
Figures 2 and 3 show detailed resource
components for some subsystems of the ERP system
that must be exposed as web services. The resource
components are typically structured to form various
resource component hierarchies. As the scope of an
ERP system is large, only the following subsystems
are shown in the paper: Project Management (PM)
and Human Resource Management (HRM).
Figure 2: Components of Project Management
Figure 3: Components of Human Resource Management
4.2 Resource Component Access
Requirements Analysis
A special requirement analysis is conducted to
provide a detailed requirement specification
document regarding various authorized access rights
to the resource components. Some of the
requirements defined for the resource components
include:
A product engineer in a team is allowed to
access resource components managed by
that product team only.
A quality assurance engineer has access
rights to all the resource components for
which he/she is responsible, which may span
multiple teams.
All employees can access the resource
components, which are directly related to
themselves, such as company policy and
employee benefits.
Project
Management
Requirement
Planning/
Tracking
Time
Sheet
Project
Accounting
Expense
Reporting
Approval
Project Life
Cycle
Testing
Human
Resource
Management
Human
Resource
Account
Employee
Benefits
Payroll
Employee
Information
ICETE 2005 - SECURITY AND RELIABILITY IN INFORMATION SYSTEMS AND NETWORKS
300
A manager can access any resource
components for all the teams managed by
him/her.
4.3 Inference Engine Used
CLIPS, a well-known rule based expert system tool,
is used as the inference engine in the implementation
of the authorization layer. Rule-based knowledge
representation scheme is used to represent the
specific knowledge of resource access rights. The
system performs reasoning capabilities based on
pattern matching.
The inference engine and the rules constructed by
using CLIPS and other program components for the
authorization layer can be easily integrated in C/C++
programming environment. This is a major
advantage achieved by using CLIPS as the inference
engine tool.
4.4 Authorization Rules
Specifications Using ARS
Authorization Rule Specifier (ARS) is a new special
purpose language, designed to be used for specifying
authorization rules in the system.
It is required during the requirement analysis
stage to define a set of meaningful shorthand
notations for expressing the resource components to
be used. Some of the examples are shown:
PM stands for Project Management. And
PM-PA-TS means that Time Sheet (TS),
which is a part of the Project Accounting
(PA), which is in turn a part of Project
Management (PM).
PM-PLC-[DEV | PT | RM | T] means that
[Development | Planning & Tracking |
Requirement | Testing] component, which is
a part of Project Life Cycle (PLC), which is
a part of Project Management (PM).
HRM stands for Human Resource
Management, and HRM-[EI | EB] means
that [Employee Information | Employee
Benefits] is a part of Human Resource
Management (HRM).
The authorized access right granted at a certain
level of an organizational resource component
hierarchy does not imply the access rights to the
resource components at its lower level. It simply
means that the user can be considered for giving
access rights to the components at the lower level.
All the required authorization rules are specified
using the language ARS. Other than the quantifiers,
logical connectives are also available in ARS, such
as (AND), (OR), and ¬ (NOT), which can be
used to specify logical expressions in authorization
rules.
Some authorization rules for the example are
shown below:
1. (x)[loc-secure(x) context-teamtask(x)
access(PM)]
2. (x)[access-PM(x) ¬ (role-user(x) role-
customer(x)) access(PM-PA-TS)]
3. (x)[access-PM(x) team-A(x) role-
engineer(x) task-dev(x) access(PM-
PLC-DEV)]
4. (x)[access-HRM(x) role-employee(x)
time-office_hours(x) ¬ (role-user(x)
role-customer(x)) access(HRM-EI)
access(HRM-EB)]
5. (x) (y)[access-PM(x) role-manager(y)
task-dev(x) role-direct_support(y, x)
access(PM-PLC-PT) access(PM-PLC-
RM) access(PM-PLC-DEV)]
4.5 Semantic Interpretations of the
Rules
The semantic interpretations of the above rules are
stated below:
1. Any client user (x) who would like to be
granted with access rights to resource
components from a secure location, and the
client user (x) is in a context environment
involving team tasks, then the client user
(x) can access those resource components
of Project Management (PM).
2. There exists someone (x) who is specially
authorized to access the resource
components of Project Management (for
x’s team) and the person’s (x’s) role is
neither a customer nor a user, then the
person (x) can access the Time Sheets (TS)
component which is a part of Project
Accounting (PA) of PM.
3. There exists someone (x) who is in a team
A and has access to resource components of
Project Management for the team. If the
A REUSABLE INTELLIGENT AUTHORIZATION DESIGN FOR WEB SERVICES SOFTWARE SECURITY
301
person (x) is an engineer and involved in a
development task, then the person (x) can
access the development component portion
in Project Management-Project Life Cycle
(PM-PLC) for the team A.
4.
Any employee (x) (not an user or a
customer) who has access rights for the
resource components of Human Resource
Management (HRM) can access their
information and benefits during office
hours by accessing Employee Benefits (EB)
and Employee Information (EI)
components in HRM. A person who is not
an employee cannot access this
information.
5.
For any person (x) who has access right for
the resource components of Project
Management and whose task involves
development, if there exists a person (y)
who is a manager and the person (x) is
directly supported by the person (y), then
the person (x) can access the resource
components: planning and tracking (PM-
PLC-PT), requirement (PM-PLC-RM) and
development (PM-PLC-DEV) for the
teams project.
4.6 Implementation Architecture
The authorization layer of the web service was
implemented in .NET using managed C++
extensions. A CLIPS
wrapper was compiled as a
separate module and linked with the web service.
This wrapper contains the authorization layer, as
shown in Figure 1.
The data required for authorization may be obtained
in various ways. For example, location of a user may
be obtained by modifying the SOAP header to
retrieve the IP address of the user, which is used for
performing location based access control. The
authentication module, based on the user account,
may be used to specify roles.
Once information about the user such as role,
location, context, task, team etc. is obtained, the
authorization layer uses that information and
contacts the inference engine. Depending on the
facts asserted about the user, certain rules will fire.
As each rule fires, it leaves a fact in the working
memory of the inference engine. After all possible
rules have fired; the facts remaining in the working
memory determine what access rights the user
should be granted.
5 COMPARISON WITH
RELATED WORK
There is no standard that exists for specifying how to
implement authorization for a web service. However
OASIS has defined two standards related to
authorization and access control. XACML is a
language for specifying access control policies and
rules. SAML is a framework for communicating
user authentication and authorization information in
the form of assertions. The .NET framework also
provides a way of authorizing web services requests.
A comparison with these three authorization
approaches is presented in this section.
Flexibility: In the inference engine based
authorization approach, different types of
authorization may be used depending on the
application. The case used has demonstrated the use
of role based, team based, task based, user based,
time based, and context based among others. Other
forms of access control, not covered here, may be
added.
.NET based authorization approach only allows
user or role based access control. This limits the
application flexibility and requires defining
everything in terms of roles and users. In addition,
.NET based authorization does not provide fine-
grained control. The XACML based approach does
not prescribe any particular type and is as flexible as
the inference engine based authorization. SAML
supports attribute based authorization, and is
typically used to support authentication in a limited
way.
Extensibility: The inference engine based
authorization can be extended with ease. It is not
limited to role based or location based access control
only. As new access control models are introduced
in the future, the new rules provided can be
integrated into the system without requiring too
much effort.
In the .NET approach, this advantage is harder to
achieve. XACML and SAML are both extensible as
a new XML schema may be easily defined to
support a new authorization type.
Maintainability: In the inference engine based
authorization approach, there is only one
authorization layer at the organization level and the
access control rules are stored at one location, thus
the maintenance tasks become easier and simpler.
ICETE 2005 - SECURITY AND RELIABILITY IN INFORMATION SYSTEMS AND NETWORKS
302
In the other approaches, authorization must be
specified for each web service and implemented
along with the web services.
Testability: The inference engine based
authorization approach provides an interactive
specification and testing environment to test the
access control rules before their deployment. CLIPS
provides a command line tool and the web services
administrator can use the tool to enter rules, assert
facts, define functions, define global variables and
thus test the rules.
In .NET SAML and XACML based
authorizations, there is no such capability.
Reusability: The access control rules used in an
inference engine based authorization can be easily
reused for other web services using a similar access
control policy. The rules can be either ported to or
shared with other web services.
In all the other approaches, the access control
mechanism is embedded in each web service
individually. Even if the same access control rules
are to be used in each web service, the same
programming effort is repeated to engineer the rules
into every web service.
6 CONCLUSIONS
This paper presents an approach to designing a
reusable authorization layer that may be used for
web services software
authorization. Access rights
may easily be defined by a set of rules.
Authorization may be granted or denied depending
on these rules defined for the application. Rules can
be specified in a language of predicate calculus type.
The design is based on using multiple
authorization methods to construct rules. Rules may
also be constructed hierarchically. The access
control of authorization types can be role-based,
location-based, context-based, task-based, or team-
based.
The design meets all the goals originally envisioned.
Separating the authorization into a layer that resides
above the normal web services makes the system
reusable. It can be easily plugged into another
system.
Adding an expert system adds several
advantages; rules become easily maintainable and
reusable. Flexible and rich rules may now be
composed and the result is obtained by executing the
authorization rules in the inference engine. The
abilities of composing and testing rules are available
before applying them in the system.
REFERENCES
Alotaiby, F.T., Chen, J.X. 2004. “A Model for Team-
based Access Control (TMAC2004),” Proc. Of
IEEE Information Technology: Coding and
Computing, pp. 450-454.
Chaari, S. et al., 2004. “An authorization and access
control model for workflow,” Proc. Of IEEE
Control, Comm. and Signal Processing, pp. 141-
148.
Chandramouli, R., 2001. “A framework for multiple
authorization types in a healthcare Application
system,” Proc. Of Computer Security Applications
Conference, pp. 137-148.
Indrakanti, S. et al., 2004. “Authorization service for web
services and its Implementation,” Proc. Of IEEE
International Web Services Conference, 2004. pp.
774 – 777.
Mattas, A.K. et al., 2003. “Towards dynamically
administered role-based access control,” Proc. Of
14
th
International Workshop in Database and
Expert Sys. Applications, pp. 494-498.
Motta, G.H. Furuie, S.S., 2003. “A contextual role-based
control authorization model for electronic patient
record,” IEEE Trans. on Inform. Technology in
Biomedicine, vol. 7, no. 3, 202 – 207.
Moyer, M.J., Abamad, M., 2001. “Generalized role-based
access control, Proc. Of 21
st
International
Conference on Distributed Computing Systems, pp.
391-398.
http://www.ghg.net/clips/CLIPS.html.
http://www.oasis-open.org/committees/
download.php/2406/oasis-xacml-1.0.pdf.
http://www.oasis- open.org/committees/
download.php/11902/saml-2.0-os.zip
A REUSABLE INTELLIGENT AUTHORIZATION DESIGN FOR WEB SERVICES SOFTWARE SECURITY
303