![](bg6.png)
the proposed service specification. Embedding each role inside the service entry al-
lows for the automatic pairing between service and role
ids (i.e, the (s,n) pairs identi-
fying the globally unique role
r). A status attribute is supported for each role, allow-
ing its enablement or disablement on-demand. The
role is also the entity, which con-
tains the actual association with the users (i.e. the
role assignment that was defined in
the formal model). In order to avoid duplicate
member entries for each role, the corre-
sponding element is marked as unique. The values of the
member elements corre-
spond to the
ids of the users as the latter are defined inside the registry.
<?xml version="1.0" encoding="utf-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="addresses">
<xs:complexType>
<xs:all maxOccurs="unbounded">
<xs:element name="address" type="xs:string" minOccurs="0"/>
</xs:all>
</xs:complexType>
</xs:element>
<xs:element name="user">
<xs:complexType>
<xs:all>
<xs:element name="username" type="xs:string"/>
<xs:element name="password" type="xs:string"/>
<xs:element name="name" type="xs:string"/>
<xs:element name="surname" type="xs:string"/>
<xs:element name="
certificate" type="xs:string" minOccurs="0"/
<xs:element name="otherinfo" type="xs:string" minOccurs="0"/>
<xs:element ref="addresses" minOccurs="0"/>
</xs:all>
<xs:attribute name="id" type="xs:string" use="required"/>
</xs:complexType>
</xs:element>
<xs:element name="users">
<xs:complexType>
<xs:all maxOccurs="unbounded">
<xs:element ref="user" minOccurs="0"/>
</xs:all>
</xs:complexType>
<xs:key name="idUniqueness">
<xs:selector xpath="user"/>
<xs:field xpath="@id"/>
</xs:key>
<xs:key
name="usernameUniqueness">
<xs:selector xpath="user"/>
<xs:field xpath="username"/>
</xs:key>
</xs:element>
</xs:schema>
"[POYHUVLRQ HQFRGLQJ 87)"!
[VVFKHPD [POQV[V KWWSZZZZRUJ;0/6FKHPD!
[VLPSRUW VFKHPD/RFDWLRQ DFFHVV&RQWURO[VG!
[VLPSRUW VFKHPD/RFDWLRQ UROHV[VG!
[VVLPSOH7\SH QDPH V6WDWXV!
[VUHVWULFWLRQ EDVH [V1072.(1!
[VHQXPHUDWLRQ YDOXH 67$57('!
[VHQXPHUDWLRQ YDOXH 67233('!
[VUHVWULFWLRQ!
[VVLPSOH7\SH!
[VHOHPHQW QDPH VHUYLFH!
[VFRPSOH[7\SH!
[VDOO!
[VHOHPHQW QDPH GHVFULSWLRQ W\SH [VVWULQJ PLQ2FFXUV !
[VHOHPHQW QDPH XUO W\SH [VVWULQJ!
[VHOHPHQW QDPH UHIHUHQFH$GGUHVV W\SH [VVWULQJ!
[VHOHPHQW QDPH GHSOR\PHQW'DWH
W\SH [VGDWH7LPH!
[VHOHPHQW QDPH FUHDWRU W\SH [VVWULQJ!
[VHOHPHQW QDPH RWKHULQIR W\SH [VVWULQJ PL Q2FFXUV !
[VHOHPHQW UHI UROHV PL Q2FFXU V !
[VHOHPHQW UHI DFFHVV&RQWURO PLQ2FFXUV !
[VDOO!
[VDWWULEXWH QDPH LG W\SH [VVWULQJXVH UHTXL UHG!
[VDWWULEXWH QDPH VWDWXV W\SH V6WDWXV XVH RSWLRQDO GHIDXOW 67233('!
[VFRPSOH[7\SH!
[VHOHPHQW!
[VHOHPHQW QDPH VHUYLFHV!
[VFRPSOH[7\SH!
[VDOO PD[2FFXUV
XQERXQGHG!
[VHOHPHQW UHI VHUYLFH PLQ2FFXUV !
[VHOHPHQW UHI DFFHVV&RQWURO PLQ2FFXUV !
[VDOO!
[VFRPSOH[7\SH!
[VNH\ QDPH VHUYLFH,'8QLTXH!
[VVHOHFWRU [SDWK VHUYLFH!
[VILHOG [SDWK #L G!
[VNH\!
[VHOHPHQW!
</xs:schema>
Fig. 2.
User entry specification
Fig. 3.
Service entry specification
The service specification contains also the appropriate information needed by the
framework’s access control mechanisms. Linking to these mechanisms is achieved
through the defined
accessControl element. The aforementioned element appears in
two different levels within the service specification (see figure 3); one at the
services
level, which intends to cover low-level access to all possible resources (i.e., to the
whole protected system) and a second one at the
service level. The latter realises the
service eligibility association, defined in our model, thus implementing the high-level
access control that was defined in the beginning of the section.
The defined schema for the
accessControl element is presented in figure 5. In or-
der to support a flexible definition framework, the schema has the option of choosing
between specifying either a list of users eligible to access the controlled resource or a
list of non-eligible users. The appropriate information is stored under the
allowed or
notAllowed elements respectively, in the form of sets of user ids. The proposed
scheme validates that the same
user does not appear sin two different areas inside the
same
accessControl element, thus avoiding erroneous situations, where two conflict-
ing restrictions apply to a single user.
232