Z
´
AS - ASPECT-ORIENTED AUTHORIZATION SERVICES
Paulo Zenida, Manuel Menezes de Sequeira, Diogo Henriques and Carlos Serr
˜
ao
ISCTE - Instituto Superior de Ci
ˆ
encias do Trabalho e da Empresa
Av. das Forc¸as Armadas, Lisboa, Portugal
Keywords:
JAAS, RBAC, authorization, Java, AspectJ, AOP, Zs.
Abstract:
This paper proposes Z
´
as, a novel, flexible, and expressive authorization mechanism for Java. Z
´
as has been in-
spired by Ramnivas Laddad’s proposal to modularize Java Authentication and Authorization Services (JAAS)
using an Aspect-Oriented Programming (AOP) approach. Z
´
as’ aims are to be simultaneously very expres-
sive, reusable, and easy to use and configure. Z
´
as allows authorization services to be non-invasively added to
existing code. It also cohabits with a wide range of authentication mechanisms.
Z
´
as uses Java 5 annotations to specify permission requirements to access controlled resources. These require-
ments may be changed directly during execution. They may also be calculated by client supplied permission
classes before each access to the corresponding resource. These features, together with several mechanisms for
permission propagation, expression of trust relationships, depth of access control, etc., make Z
´
as, we believe,
an interesting starting point for further research on the use of AOP for authorization.
1 INTRODUCTION
This paper proposes a novel, flexible, and expressive
authorization mechanism. Its advantages stem mainly
from the fact that an AOP approach is used, allowing
it to address some of the problems found in indus-
try standards like JAAS (Lai et al., 1999; Cot
´
e, 2006;
Oaks, 2005). AspectJ (AspectJ Team, 2006) has been
used to develop the proposal.
AOP is strong in terms of reduction of code scatter-
ing and tangling, provides for the separation of cross-
cutting concerns from the core code, and nicely inte-
grates with the expressiveness of Java 5 annotations.
This, together with our practical interest in authoriza-
tion services for Java applications, led us to attempt
to develop a new, aspect-oriented authorization mech-
anism, called Z
´
as. Our aims were to make Z
´
as si-
multaneously very expressive, allowing programmers
to state very clearly what they mean, and indepen-
dent from the business context, though being possi-
ble to make it business aware, allowing the separation
of particular permission specifications from the au-
thorization concerns embedded into the code by pro-
grammers. Another of our goals was to make the ap-
plication of Z
´
as to already existing code as simple as
possible and, if necessary, totaly non-invasive.
Expressiveness requires code which is as clear and
simple as possible. We do not want to tangle busi-
ness code with code related to the checking of user
permissions. We also do not want permission check-
ing code scattered all over the application, in every
method requiring verification of authorized access. In
other words, we want to modularize, into aspects, the
crosscutting concerns related to authorization. On the
other hand, the programmer should be able, though
not required, to guide the application of the autho-
rization concerns to his own code. In this sense, one
might say that one of the tenets of AOP, viz. obliv-
iousness (Filman and Friedman, 2005), is violated.
However, annotations may be though of as allowing
the programmer to express in the code its required se-
mantics, still oblivious of the exact way in which this
semantics will actually be implemented.
According to (Clifton and Leavens, 2002), aspects
can be divided into two categories: assistants and
spectators. They suggest that assistance should be ex-
plicitly accepted by a module. Once a module accepts
assistance of an aspect, then the aspect is allowed to
advise that module. Annotations can be seen as a way
to express assistance acceptance. Authorization an-
notations, as proposed by Z
´
as, will thus acknowledge
specific semantics for, say, a method, and implicitly
46
Zenida P., Menezes de Sequeira M., Henriques D. and Serrão C. (2006).
ZÁS - ASPECT-ORIENTED AUTHORIZATION SERVICES.
In Proceedings of the First International Conference on Software and Data Technologies, pages 46-53
DOI: 10.5220/0001320600460053
Copyright
c
SciTePress
accept (or rather, require) assistance of a correspond-
ing aspect implementing that semantics.
In (Recebli, 2005), Recebli proposes a different
classification related to the role of aspects in soft-
ware systems from a higher-level engineering point
of view. He proposes the division into integral and at-
tachable aspects. According to him, we can say that
the aspects within our approach are attachable, since
they can be removed from an application, without in
any way changing the correctness of its business im-
plementation (except, of course, in what concerns au-
thorization).
The JAAS authentication service, based on
PAM
1
(Samar and Lai, 1996), provides an abstraction
layer that greatly simplifies changes in the actual au-
thentication method used. However, since this work
was motivated by the need to add authorization to
the Heli
´
opolis Web application,
2
which already pos-
sessed its own authentication code, our main focus
was solely on authorization concerns. Nevertheless,
the developed solution can be seamlessly integrated
with a wide range of authentication mechanisms.
This work was inspired by Laddad’s proposal (Lad-
dad, 2003) to use AOP to modularize JAAS-based au-
thentication and authorization. The main interest of
his proposal, at least from our point of view, is related
to the authorization concerns. Our work is thus based
in Laddad’s, extending further the modularization of
authorization concerns, thus reducing code tangling
and scattering, and reducing the configuration effort
required from the programmers.
This paper is structured as follows. The next sec-
tion will review some of the existing Java-based au-
thorization mechanisms. It is followed by a detailed
description of the requirements that have been used
as guidelines to develop Z
´
as. And finally, conclusions
will be drawn and some possible directions for further
work will be pointed to.
The Z
´
as source code and related projects can
be downloaded from https://svn.ci.iscte.pt/zenida,
namely the Z
´
as source code and the Web application
used as a case study for this research. Further details
about Z
´
as, its implementation and the case study re-
sults can be found in (Zenida et al., 2006).
2 AUTHORIZATION SOLUTIONS
IN JAVA
Authorization is not a new research topic. There are
many different proposals and tools readily available,
ranging from ad hoc solutions, where the developer
1
Pluggable Authentication Modules
2
See http://heliopolis.iscte.pt/ (the source code uses Z
´
as
and is available in https://svn.ci.iscte.pt/Heliopolis/trunk/).
implements everything from scratch, to complete so-
lutions like JAAS, and from OOP approaches to ap-
proaches where the power of AOP is leveraged.
Our main interest while studying existing authen-
tication and authorization mechanisms was JAAS,
since it is a standard for authentication and authoriza-
tion services in Java (Sun Microsystems, Inc., 2006)
and an integral part of the JDK.
JAAS is not as flexible as we would like it to be. Its
use requires considerable configuration effort (Oaks,
2005). For example, security policy files have to be
used in order to specify the principals and what they
are permitted to do. For example:
grant Principal
sample.principal.Principal "user" {
permission test.Permission "perm";
};
Besides, and importantly, the permissions can not
be changed at runtime. This is a serious restriction for
dynamic applications, where an administrator must be
able to add users and their corresponding permissions
during the operation of the system. It is possible to
use a database for this task, as in the example pro-
vided in (Cot
´
e, 2006), increasing the flexibility of the
system by allowing the privileges of the principals to
be specified at runtime. However, such a solution re-
quires the use of a specific database model that, for
already existing systems, may not be easy to accom-
plish.
The original JAAS model is implemented with an
OO approach, thus being prone to the common prob-
lems of code scattering and tangling: code must be
added to the business classes in order to implement
authorization.
public class MyClass {
public void businessMethod() {
AccessController.checkPermission(
new MyPermission("aPermission")
);
// business code
}
public static
void main(String args[]) {
// authentication code
MyClass a = new MyClass();
Subject authenticatedSubject =
lc.getSubject();
Subject.doAsPrivileged(
authenticatedSubject,
new PrivilegedAction() {
public Object run() {
a.businessMethod();
}
},
null
);
}
}
Clearly, the authorization code is entangled with
business code, both in the code requesting access to
ZÁS - ASPECT-ORIENTED AUTHORIZATION SERVICES
47
the resource (the caller code) and in the resource code
itself (the callee code). Moreover, authorization code
will be scattered through the application, since it must
be used wherever access control is required. Both
problems can be fixed using AOP, as shown in (Lad-
dad, 2003). Laddad proposes an aspect-oriented ap-
proach to the application of JAAS that significantly
simplifies the code required for access control, though
only at the caller:
public class MyClass {
// as before
public static
void main(String args[]) {
MyClass a = new MyClass();
a.businessMethod();
}
}
We still need to call the checkPermission()
method in the business methods. This can be avoided
if we use the expressiveness of Java 5 annotations and
modularize that call into an aspect responsible for au-
thorization verification:
@AccessControlled(
requires = "aPermission",
permissionClass = MyPermission.class
)
public void businessMethod() {
// business code
}
The use of annotations clearly improves the qual-
ity of the code, augmenting its expressiveness while
reducing scattering and entanglement. However, by
itself it does not decrease the required configuration
effort nor makes access control dynamic. Z
´
as, as will
be seen in the next sections, does.
3 REQUIREMENTS
Originally, the implementation of authorization in
Heli
´
opolis was a clear case of a simplistic implemen-
tation of Yoder’s “Limited View” pattern (Yoder and
Barcalow, 1997), where appropriate menu options
were hidden from non-authorized users. Our aim was
thus to solve the authorization problem not by merely
limiting the view of each user to whatever she is al-
lowed to view or manipulate, but mainly by making
sure, at the business layer itself, that no user can ever
gain unpermitted access to any resource that is out-
side the privileges associated with his roles within the
system.
For the reasons stated in the previous section, we
were not satisfied with the available solutions to this
problem. Z
´
as, as described in this paper, was thus de-
veloped as a non-ad hoc solution to the authorization
problem fulfilling the following broad requirements:
1. It should be independent and compatible with the
simultaneous use of JAAS, especially with its au-
thentication services.
2. Its authorization services should require no more
from the application model than access to the cur-
rent principal’s permissions. It should thus support
the RBAC (Ferraiolo et al., 2006; Sandhu et al.,
1996) model, though never dealing directly with
roles itself.
3. It should greatly simplify the code of client appli-
cations, as compared with alternative solutions.
4. It should be as non-invasive as possible, allowing
business code to concentrate on the business logic,
allowing the programmer to specify access require-
ments within the code, if she so desires, but also to
completely separate access control from the busi-
ness logic code.
5. It should require less configuration effort than the
alternatives.
6. It should allow dynamic changes to the resources’
access requirements.
Since Z
´
as was meant to be a Java/AspectJ library
of classes and aspects for use in Java applications, the
requirements above were further refined into the fol-
lowing detailed requirements:
1. The access requirements for each such resource
should be specifiable using Java 5 annotations.
2. The resources whose access should be controlled
are represented by constructors, methods, and at-
tributes.
3. It should be possible to force the propagation of the
access requirements of a resource to all its mem-
bers. For instance, from a package to all its types
and nested packages, and from a class to all its
(non-private) methods and attributes.
4. It should not be possible to propagate access con-
trol specification to resources explicitly marked as
having no access control.
5. It should be possible to define access requirements
either next to the corresponding resource defini-
tion (invasive usage), centralized in a single or in
several access requirement definition aspects (non-
invasive), or both.
6. It should be possible to use outside sources of per-
mission requirements, such as property files. Per-
mission requirements should be possible to change
dynamically.
7. It should allow the definition of access require-
ments using boolean expressions involving permis-
sion names.
8. It should allow the quantification of the definition
of access requirements using wildcards.
ICSOFT 2006 - INTERNATIONAL CONFERENCE ON SOFTWARE AND DATA TECHNOLOGIES
48
9. It should allow the specification of the required
depth of access control as either deep or shallow.
10. When shallow access control is required, it should
be possible to specify the degree of suspiciousness
of a resource.
11. Special cases should be provided to bypass access
control, viz. using privileged methods and trusted
classes.
12. It should be easy to add authorization features to
existing projects.
The next sections go through several of these re-
quirements, exemplifying their impact in the client
code, and thus clarifying the importance of the re-
quirements themselves. Notice, however, that at the
current state not all requirements have been imple-
mented and some are only partially implemented. The
status of development will be stated wherever appro-
priate.
3.1 Annotations (1 and 2)
Z
´
as should allow the programmer to guide the appli-
cation of aspects through the annotation of the non-
private
3
resources where access control is required:
import pt.iscte.ci.zas.authorization.
*
;
public class MyClass {
@AccessControlled(
requires = "aPermission"
)
public void foo() {}
}
The previous code explicitly states that ac-
cess to method foo(), that is, calling permis-
sion, is restricted to principals having permission
aPermission. When not specified in the annotation,
the access requirements correspond to a single per-
mission whose name is the signature of the method
without the return type.
4
Hence, the permission re-
quired to call foo() as defined in
package mypackage;
public class MyClass {
@AccessControlled
public void foo() {}
}
is mypackage.MyClass.foo().
It should also be possible to annotate attributes,
similarly to what happens for methods.
5
Access requirements should always be filtered by
method getRequirements() of the Permission
class:
3
Private “resources´´ are implementation details.
4
Using complete signatures as permission names guar-
antees that overloaded resources are distinguished.
5
The current version of Z
´
as does not distinguish be-
tween sets and gets, as it should.
package pt.iscte.ci.zas.authorization;
public class Permission {
public String getRequirements(
String currentRequirements,
JoinPoint joinPoint,
JoinPoint.StaticPart
enclosingStaticPart) {
return currentRequirements;
}
}
Before each access to a protected resource, this
method shall be passed the current access require-
ments, which the default implementation will simply
return, as well as the execution context of the access,
including the caller and callee objects.
It should be possible to provide access control spec-
ifications with client classes extending Permission
and overriding getRequirements():
package mypackage;
public class MyClass {
@AccessControlled(
permissionClass = MyPermission.class
)
protected void foo() {}
}
Hence, arbitrary client code may be executed during
access control, making it possible to add business spe-
cific access control methods to Z
´
as.
3.2 Propagation (3 and 4)
Z
´
as should provide a mechanism allowing access con-
trol specifications to be propagated to members of the
corresponding resource, if any. For instance, in
@AccessControlled(
requires = "aPermission",
depth = Depth.SHALLOW
)
public class MyClass {
public void foo() {}
@AccessControlled
public void bar() {}
@NotAccessControlled
public void baz() {}
}
foo() would inherit its access control specifications
from class MyClass: the permission aPermission
and the depth (see Section 3.6) verification as shal-
low. However, bar(), while access controlled, would
not inherit required permissions from MyClass, and
baz() would remain free of any access controls.
By default, non-private resources should not be
access controlled, except when propagation is being
used.
Notice that there should be two different effects
in propagation. The first one is static, and leads to
all non-private members of an access controlled re-
source, with the exception of those marked with an-
notation @NotAccessControlled, to also be access
ZÁS - ASPECT-ORIENTED AUTHORIZATION SERVICES
49
controlled. The second one is dynamic, and leads to
all non-private members of an access controlled re-
source that have not been explicitly marked as being
either access controlled or not access controlled to
dynamically inherit the required permissions from the
enclosing resource (see Section 3.4).
The current version of Z
´
as still does not provide
the same mechanisms in the case of attributes. This
problem will be solved in the near future.
Also, since the current version of AspectJ (AspectJ
Team, 2006) does not allow the capture of package
annotations, Z
´
as still does not provide the inheritance
mechanism for packages from the source code.
6
3.3 Location (5)
Usually resources requiring access control are di-
rectly annotated as such, i.e., their definition is di-
rectly annotated. This requires source code invasion
and leads to scattering the meta-information related to
access control concerns, which in some cases may be
considered a bad practice.
7
It is possible to use AspectJ ITDs
8
to inject anno-
tations in types, methods, attributes, etc. Hence, it
is possible to modularize all access control specifica-
tions in a single aspect, solving the problem of scat-
tering meta-information.
Just as Java prohibits double annotations, As-
pectJ prohibits the injection of an annotation already
present in the source code, next to the resource defini-
tion. Hence, the two approaches may be used together
without any problem: the compiler will issue an error
in case of a collision.
3.4 Dynamic Permissions (6)
Access control specifications should specify initial
permissions, changeable at runtime. That is, permis-
sion requirements should be dynamic, while the ac-
cess control character of resources should be static.
In conjunction with the ability to use wildcards (see
Section 3.5) both to specify permissions and to spec-
ify the resources to which the permissions apply, this
requirement makes it possible to dynamically load
permissions specification from a generic input stream
(connected to, e.g., access control property files), thus
allowing permissions to be changed dynamically and
easily by a system operator. For instance,
package mypackage;
public class MyClass {
@AccessControlled
6
However, we will soon open an AspectJ feature re-
quest.
7
The authors consider this use of annotations to be ad-
visable, however, since it leads to improved source expres-
siveness without hampering abstraction.
8
Inter-Type Declarations
public void foo(String s) {}
}
specifies that foo is access controlled and ini-
tially requires permission mypackage.MyClass.
foo(String). It should be possible to change the
required permission using a properties file:
mypackage.MyClass.foo(String) = foo
In this case, after loading the properties file, the
required permission for calling foo() is no longer
mypackage.MyClass.foo(String), but foo. Of
course, the same effect should be obtained by directly
calling a permission changing method of Z
´
as:
import pt.iscte.ci.zas.authorization;
...
AccessController.addAccessControl(
"mypackage.MyClass.foo(String)",
"foo"
);
The use of external sources of permission require-
ments allows them to be provided at the appropriate
granularity level. For example,
mypackage.MyClass.foo() = foo || bar
mypackage.MyClass.
*
= bar
mypackage.
*
() = foo
which might be found in an access control prop-
erty file, states that all access controlled methods
without any parameters within package mypackage
will require permission foo, with the exception of
those within class MyClass, which require permis-
sion bar. Again, method MyClass.foo() is an ex-
ception, since it requires either permission foo or per-
mission bar (see Section 3.5). The order is relevant
because Z
´
as will always look for the first occurrence
of a matching signature and load the corresponding
permission specification.
3.5 Expressions (7 and 8)
It should be possible to compose Boolean permis-
sion expressions, both in-code as initial permission
requirements, and dynamically (e.g., inside property
files). For instance, in the access control specifica-
tion
@AccessControlled(
requires =
"aPermission || !anotherPermission"
)
public void foo() {}
the permission expression requires any principal call-
ing foo() either to have permission aPermission
or to lack permission anotherPermission.
Currently, Z
´
as supports operators || (“or”), &&
(“and”), and ! (“not”), as well as the use of paren-
theses to control evaluation order.
Regular expressions should also be possible in per-
missions expressions. For example, using
ICSOFT 2006 - INTERNATIONAL CONFERENCE ON SOFTWARE AND DATA TECHNOLOGIES
50
@AccessControlled(requires = "perm
*
")
public void foo() {}
any call to foo() would require a principal having
at least one permission whose name starts with perm
(e.g., perm or permission). Notice that regular ex-
pressions introduce a form of quantification into Z
´
as.
In this case they introduce existential quantifiers into
permission requirements.
Wildcards should also be possible when dynami-
cally specifying permission requirements, of course.
In this case, however, they can also be used to specify
multiple resources in a single step, as shown in the last
example of Section 3.4. This introduces the notion of
universal quantifiers into Z
´
as.
3.6 Depth (9 and 10)
By default, access control should be applied for all
accesses to access controlled resources, regardless of
the context. Regardless, namely, of the controls which
have already been performed in upper levels of the
current call stack. This is usually the safest option
and thus the most desirable default. However, occa-
sionally it may be necessary to turn off access control
in the control flow of a given method execution.
The @AccessControlled annotation’s element
depth represents the level of access control. In a way
reminiscent of copy depth, access control is applied
to method execution either in a Depth.SHALLOW or
in a Depth.DEEP manner. Shallow access control
means that if access to a method is granted to a prin-
cipal, it will also be granted to its complete flow of
control, effectively turning off access control during
its execution. On the contrary, if access to a method
specifying deep access control, which is the safe de-
fault, is granted to a principal, it will not be automat-
ically granted to all other accesses to resources in the
method’s control flow.
For example, in
public class A {
@AccessControlled
public void foo() {
new B().bar();
}
}
public class B {
@AccessControlled
public void bar() {}
}
a call to foo() will be possible only if the prin-
cipal has both permission A.foo() and permission
B.bar(). Changing the depth to Depth.SHALLOW in
the annotation of foo(), access control will not be
applied during the execution of foo():
@AccessControlled(
depth = Depth.SHALLOW
)
public void foo() {
new B().bar();
}
Using shallow access control should generally be
considered dangerous. Hence, a mechanism should
be devised to short-circuit the consequences of shal-
low access control. If a given method declares itself to
be suspicious, its access control specification should
not be turned off in the flow of a shallowly access
controlled method. For instance, in
public class A {
@AccessControlled(
depth = Depth.SHALLOW
)
public void foo() {
new B().bar();
new C().baz();
}
}
public class B {
@AccessControlled
public void bar() {
new C().baz();
}
}
public class C {
@AccessControlled(suspicious = true)
public void baz() {}
}
a call to foo() will fail if the principal does not have
permission C.baz(): it is not sufficient for him to
have permission A.foo(), since baz() is suspicious.
On the other hand, permission B.bar() is not neces-
sary when the call is performed in the flow of control
of foo(), since bar() is unsuspecting and foo()s
access control is shallow.
3.7 Bypasses (11)
Z
´
as should provide two methods to bypass access
control. The first is more dangerous, and should be
used with care: it should be possible to annotate some
methods as privileged, i.e., as turning off access con-
trol to calls within their control flow. The difference
between calling a privileged method and calling a
method with shallow access control is that the first
call always succeeds, while the success of the second
one depends (solely) on the current principal having
permission to make the call.
The second required bypassing mechanism, trust, is
more disciplined and less dangerous. Instead of being
used in a method to bypass access control during its
entire execution, regardless of the access control spec-
ifications of the intervening resources, trust in speci-
fied classes is explicitly acknowledged by the callee
method. For example, given
public class A {
@AccessControlled(
requires = "aPermission",
ZÁS - ASPECT-ORIENTED AUTHORIZATION SERVICES
51
trusts = { B.class }
)
public void foo() {}
}
public class B {
@AccessControlled(
requires = "anotherPermission"
)
public void bar() {
new A().foo();
}
}
any call to bar() will require a principal with per-
mission anotherPermission, as usual, but the call
to foo() from within bar() will not be subject to
access control, since foo() declared its trust in class
B. Notice, however, that calls from within the flow of
control of foo() will in general be access controlled,
since trust does not propagate. This will improve even
further the safety of trust relationships.
3.8 Ease of Use (12)
Z
´
as should be easily integrated into an existing
project. Indeed, if the requirements illustrated in the
previous sections are fulfilled, particularly the ability
to use ITDs to modularize access control specifica-
tions, little or no changes will be required in existing
code.
Z
´
as integration shall simply require
1. adding the zas.jar Java archive into the class path
of the application;
2. defining a concrete aspect that extends the provided
abstract aspect AccessController; and
3. adding the access control specifications either di-
rectly to the resources requiring authorization, or
using ITDs concentrated in, e.g., the concrete as-
pect defined.
These steps are quite straightforward, with the pos-
sible exception of the definition of the concrete as-
pect. Access control is only possible if the cur-
rent principal’s set of permissions is available. How-
ever, Z
´
as should be as independent as possible both
of the authentication mechanism used in the ap-
plication, and of the roles existing in the appli-
cation and their corresponding permissions. How
and where to find the permissions associated with
(the roles of) the current principal is not Z
´
as’ prob-
lem. AccessController simply declares an ab-
stract method currentPrincipalPermissions()
which the concrete aspect, defined in the client code,
should implement.
For example, the definition of the concrete aspect
for a simple desktop application should be as simple
as:
package pt.iscte.ci.myapp;
import pt.iscte.ci.zas.authorization.
*
;
public aspect MyController
extends AccessController {
private User user;
public Set<String>
currentPrincipalPermissions() {
// get and return permissions
// from the roles of "user".
}
before() :
accessToControlledResources(
AccessControlled
) {
// if necessary, authenticate user.
}
}
4 CONCLUSIONS
A new aspect-oriented authorization package, Z
´
as,
has been proposed which leverages AspectJ to make it
possible to add authorization concerns to existing ap-
plications in a simple, non-invasive way. The model
used is both independent of the authentication mecha-
nism used, and of the specific way permissions are at-
tached to principals. Hence, while supporting RBAC,
Z
´
as is not strictly speaking RBAC-based.
Even though in its early stages of development, Z
´
as
has shown the potential of aspect-oriented approaches
to authorization concerns, making them simpler to
implement, support, and configure. Z
´
as is also dy-
namic, allowing runtime changes to the permission
requirements associated with access controlled re-
sources. The use of Z
´
as, which builds on a previ-
ous proposal by Laddad (Laddad, 2003), greatly re-
duces the scattering of authorization code and its en-
tanglement with business code. The use of Java 5
annotations led to a model where Z
´
as’ client code
is not explicitly guiding advice introduction (Clifton
and Leavens, 2002), but augmenting the expressive-
ness of the code by annotating it with authorization
meta-information that is then taken into account by
Z
´
as’ aspects. If this is deemed unacceptable, or if it
is impossible in practice, then authorization concerns
can be concentrated in a single module, thus free-
ing business code not only from authorization-related
code but also from scattered meta-information.
Z
´
as is, in certain cases, a good alternative to JAAS:
it behaves much like JAAS, though with some impor-
tant limitations. For instance, unlike JAAS, it can not
be used to add access control concerns to resources in-
side JDK classes, since AspectJ does not allow ITDs
to add annotations to code inside JDK’s archives.
9
9
An interesting extension point for Z
´
as would be the cre-
ation of an alternative to annotations to be used in such sit-
uations.
ICSOFT 2006 - INTERNATIONAL CONFERENCE ON SOFTWARE AND DATA TECHNOLOGIES
52
However, Z
´
as’ aim is not to replace JAAS, since Z
´
as
can be used together with JAAS-based authorization
and, in a future version, Z
´
as may even leverage JAAS
authorization services.
Even though Z
´
as is still in its infancy, we plan to
revise and improve it regularly. Some possible next
steps to the improvement of Z
´
as are described next.
4.1 Further Work
In the near future we intend to improve Z
´
as, especially
taking into account the insight gained by its use in a
large scale Java-based Web application.
10
Nevertheless, some points requiring further re-
search have already been identified. Should the ba-
sic concepts of authorization be extended such that
each domain object is considered a principal, with its
own set of permissions and its own set of trust rela-
tionships with other objects? What is the connection
between trust and the composition, aggregation, and
association relations? Should a distinction be some-
how drawn between query and modifier methods, in
the same way we need to distinguish sets and gets in
the case of attributes? How do contracts relate to au-
thorization and access control? What does this tell
us regarding the relation between the runtime permis-
sion requirements of a method and the method it over-
rides? What if other crosscutting concerns of the ap-
plication are implemented using aspects? How do we
deal with potential conflicts that may arise (including
the possibility of overriding authorization controls)?
Nakajima and Tamai (?) proposed an analysis tech-
nique to assess the coherence between authorization
policies and application code. The proposal, however,
assumes the authorization policies are static. How
could their analysis technique be applied in the case
of dynamic policies, as allowed by Z
´
as?
ACKNOWLEDGEMENTS
Special thanks to Professor Dulce Domingos for her
important suggestions and for trying to make sure we
would not miss the most important authorization ref-
erences.
REFERENCES
AspectJ Team ([April 16th, 2006]). The AspectJ project at
Eclipse.org. http://www.eclipse.org/aspectj/.
Clifton, C. and Leavens, G. T. (2002). Spectators and as-
sistants: Enabling modular aspect-oriented reasoning.
10
Namely F
´
enixEDU
R
. See http://
fenix-ashes.ist.utl.pt/FrontPage/.
Technical Report 02-10, Iowa State University, De-
partment of Computer Science.
Cot
´
e, M. ([April 16th, 2006]). JAAS book: Java authenti-
cation and authorization. Originally written for publi-
cation by Manning, http://www.jaasbook.com/.
Ferraiolo, D. F., Kuhn, D. R., Chandramouli, R., and
Barkley, J. ([8th March, 2006]). Role Based Access
Control (RBAC). http://csrc.nist.gov/rbac/.
Filman, R. E. and Friedman, D. P. (2005). Aspect-
oriented programming is quantification and oblivi-
ousness. In Aspect-Oriented Software Development,
chapter 2, pages 21–35. Addison-Wesley, Boston,
Massachusetts.
Laddad, R. (2003). AspectJ in Action. Manning, Green-
wich, Connecticut.
Lai, C., Gong, L., Koved, L., Nadalin, A., and Schemers,
R. (1999). User authentication and authorization in
the Java
TM
platfom. In Proceedings of the 15th Annual
Computer Security Applications Conference, Phoenix,
Arizona.
Oaks, S. (2005). Java Security. O’Reilly, 2nd edition.
Recebli, E. A. (2005). Pure aspects. Master’s thesis, Uni-
versity of Oxford, Computing Laboratory.
Samar, V. and Lai, C. (1996). Making login services in-
dependent of authentication technologies. In Pro-
ceedings of the SunSoft Developer’s Conference.
http://java.sun.com/security/jaas/doc/pam.html.
Sandhu, R., Coyne, E. J., Feinstein, H. L., and Youman,
C. E. (1996). Role-based access control models. IEEE
Computer, 29(2):38–47.
Sun Microsystems, Inc. ([April 16th, 2006]). Java
technology: Security and the Java platform.
http://java.sun.com/security/.
Yoder, J. and Barcalow, J. (1997). Architectural patterns for
enabling application security. In PLoP’97, Proceed-
ings of the 4th Conference on Patterns Language of
Programming.
Zenida, P., Menezes de Sequeira, M., Henriques, D.,
and Serr
˜
ao, C. (2006). Z
´
as - Aspect-Oriented
Authorization Services (first take). Technical Re-
port CI-2006-01, CI, ISCTE, Lisboa, Portugal.
http://ci.iscte.pt/publicacoes/relatorios
tecnicos/CI-
2006-01.pdf.
ZÁS - ASPECT-ORIENTED AUTHORIZATION SERVICES
53