c

 


c 




Submitted for
the partial fulfillment of degree of


 



in


 

 
  !" #
$




% &'(')(($

*+ 
,
*+ *y:
Abhishek Sharma Avikant
Head, Department of ECE VIII Semester (ECE)
Jaipur (Raj.) Roll No.: 07ESTEC019
------------------------------------------- ------------------------------ --
./c 0  %
  % c% 1%%1

c% %c 1 0 1%%1 c.  21" 3c%/ 
. &'(')&'((
4
 


  + 

 3 
All rights reserved.

‘
 c #5.1
‘

‘ ‘
Oy sincere thanks goes to Sh. c2%
2#
2cc (H.O.D, E.C)for his prodigious
guidance, precaution, painstaking, attitude reformative and suggestion throughout my
summer training schedule.

Special thanks goes to OR.c3c # c who helped me a lot in giving minute
details of the ³c 


´ and enlightened me with the knowledge of
essential equipments and their working.

‘ ‘

c!6

7  8 

77 77

/2c1%" 3c%/  c37$

‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘

‘
 ‘

‘
‘

2c/ % ) %. %

2c/ %% ) c 



 /c% ‘

2c/ %%% ) c 



 /

2c/ %9 ) c 



 /1

2c/ 9 ) %.%0% c% c.

c 2% c%

2c/ 9% ) c 

  2%: 

2c/ 9%% ) c/c%%%
c. %%c%

2c/ 9%%% )‘
c0 %%c%
‘

2c/ %; )  
%
 2c/ %
%. %

c 

 is a system which enables an authority to control access to areas and
resources in a given physical facility or computer-based information system. An access
control system, within the field of physical security, is generally seen as the second layer in
the security of a physical structure.

Access control is, in reality, an everyday phenomenon. A lock on a car door is essentially a
form of access control. A PIN on an ATO system at a bank is another means of access
control. Bouncers standing in front of a night club is perhaps a more primitive mode of access
control (given the evident lack of information technology involved). The possession of access
control is of prime importance when persons seek to secure important, confidential, or
sensitive information and equipment.

Item control or electronic key management is an area within (and possibly integrated with) an
access control system which concerns the managing of possession and location of small
assets or physical (mechanical) keys.

Physical access by a person may be allowed depending on payment, authorization, etc. Also
there may be one-way traffic of people. These can be enforced by personnel such as a border
guard, a doorman, a ticket checker, etc., or with a device such as a turnstile. There may
befences to avoid circumventing this access control. An alternative of access control in the
strict sense (physically controlling access itself) is a system of checking authorized presence,
see e.g. Ticket controller (transportation). A variant is exit control, e.g. of a shop (checkout)
or a country.

(Underground entrance to the New York City Subway system

In physical security, the term access control refers to the practice of restricting entrance to a
property, a building, or a room to authorizedpersons. Physical access control can be achieved
by a human (a guard, bouncer, or receptionist), through mechanical means such as locks and
keys, or through technological means such as access control systems like the Access control
vestibule. Within these environments,physical key management may also be employed as a
means of further managing and monitoring access to mechanically keyed areas or access to
certain small assets.
Physical access control is a matter of who, where, and when. An access control system
determines who is allowed to enter or exit, where they are allowed to exit or enter, and when
they are allowed to enter or exit. Historically this was partially accomplished through keys
and locks. When a door is locked only someone with a key can enter through the door
depending on how the lock is configured. Oechanical locks and keys do not allow restriction
of the key holder to specific times or dates. Oechanical locks and keys do not provide records
of the key used on any specific door and the keys can be easily copied or transferred to an
unauthorized person. When a mechanical key is lost or the key holder is no longer authorized
to use the protected area, the locks must be re-keyed.

‘
‘
 2c/ %%

c 



 /c% ‘

‘
‘
When a credential is presented to a reader, the reader sends the credential¶s information,
usually a number, to a control panel, a highly reliable processor. The control panel compares
the credential's number to an access control list, grants or denies the presented request, and
sends a transaction log to a database. When access is denied based on the access control list,
the door remains locked. If there is a match between the credential and the access control list,
the control panel operates a relay that in turn unlocks the door. The control panel also ignores
a door open signal to prevent an alarm. Often the reader provides feedback, such as a flashing
red LED for an access denied and a flashing green LED for an access granted.

The above description illustrates a single factor transaction. Credentials can be passed
around, thus subverting the access control list. For example, Alice has access rights to
the server room but Bob does not. Alice either gives Bob her credential or Bob takes it; he
now has access to the server room. To prevent this, two-factor authentication can be used. In
a two factor transaction, the presented credential and a second factor are needed for access to
be granted; another factor can be a PIN, a second credential, operator intervention, or a
biometric input.

There are three types (factors) of authenticating information:

M‘ something the user knows, eg a password, pass-phrase or PIN

M‘ something the user has, such as smart card
M‘ something the user is, such as fingerprint, verified by biometric measurement

Passwords are a common means of verifying a user's identity before access is given to
information systems. In addition, a fourth factor of authentication is now recognized:
someone you know, where another person who knows you can provide a human element of
authentication in situations where systems have been set up to allow for such scenarios. For
example, a user may have their password, but have forgotten their smart card. In such a
scenario, if the user is known to designated cohorts, the cohorts may provide their smart card
and password in combination with the extant factor of the user in question and thus provide
two factors for the user with missing credential, and three factors overall to allow access.
‘
 2c/ %%%‘

c 



 /
‘

‘
‘
An access control point, which can be a door, turnstile, parking gate, elevator, or other
physical barrier where granting access can be electronically controlled. Typically the access
point is a door. An electronic access control door can contain several elements. At its most
basic there is a stand-alone electric lock. The lock is unlocked by an operator with a switch.
To automate this, operator intervention is replaced by a reader. The reader could be a keypad
where a code is entered, it could be a card reader, or it could be a biometric reader. Readers
do not usually make an access decision but send a card number to an access control panel that
verifies the number against an access list. To monitor the door position a magnetic door
switch is used. In concept the door switch is not unlike those on refrigerators or car doors.
Generally only entry is controlled and exit is uncontrolled. In cases where exit is also
controlled a second reader is used on the opposite side of the door. In cases where exit is not
controlled, free exit, a device called a request-to-exit (RTE) is used. Request-to-exit devices
can be a push-button or a motion detector. When the button is pushed or the motion detector
detects motion at the door, the door alarm is temporarily ignored while the door is opened.
Exiting a door without having to electrically unlock the door is called mechanical free egress.
This is an important safety feature. In cases where the lock must be electrically unlocked on
exit, the request-to-exit‘

‘‘
‘
‘ ‘

‘
‘
‘
‘
‘
‘
‘
‘
‘
‘
‘
‘
‘
‘
÷
 ‘
‘
‘

÷÷ ÷   

‘
‘



‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘ ‘ ‘ ‘ ‘‘

‘
‘


 ‘ ‘ ‘‘‘ ‘‘ ‘
‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘

‘
t l‘
ii‘‘ ‘

‘
 i ‘t ‘
til‘t‘‘

‘
tl‘lit ‘i‘
l‘
‘
‘ ‘
‘ ‘ t‘ ‘ ‘
‘ ‘ 

‘
tl‘ l‘ ‘
‘ ‘ ‘ ‘
l t‘ ‘ 

‘
tl‘ t ‘ ‘ ‘ ‘ t‘ ‘ ‘ t‘ l‘t‘  ‘ ‘

tl‘t‘t‘t‘ ‘‘t‘t ‘‘t‘‘‘ it‘tl ‘
i
‘‘i‘

‘‘‘it‘‘
tl‘l‘‘t‘
‘‘t‘‘‘t‘‘‘l‘‘

tl‘ 
ti‘ ‘
‘ t‘
tl‘ l‘ ‘ ‘
 i
t‘ t ‘ ‘ il‘


ti;‘ll‘R 485‘ ‘ 
t‘‘i ‘t‘
ii‘ i ‘t‘t‘ ‘

‘l
i ‘‘
tll‘t‘t‘‘‘
tll‘‘‘
l‘‘

t‘t‘‘t‘‘
t
‘i ‘t‘t‘
‘

h ‘
 
  ‘‘
‘
Ctll‘‘

t‘t‘‘t‘C‘i‘‘il‘R485‘
 i
ti‘li‘‘i‘
 ‘
t‘ l‘i‘  ‘ l‘ t ‘ !tl‘ R"#485‘
t‘ ‘
itl‘ R485‘
‘ ‘ t‘
‘ itll‘ ‘ t‘ C‘ ‘ t‘ ‘ R485‘

 i
ti‘ t‘ ‘ l ‘ t ‘ ltit‘ il‘ $‘
‘ ‘ ‘%i i‘
ttil‘
i ‘‘‘ t‘l‘ti‘‘

‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘ ‘
‘

   

‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘ ‘  ‘‘  ‘ ‘  ‘

 


M‘ R485‘t‘ll‘l ‘

l‘‘‘t‘4‘t‘&‘ ‘
M‘ Rltil‘ t‘ ‘ ti ‘ ‘ !i  ‘ 
‘ ‘ i
‘ ‘ ‘ R485‘ li‘ i‘
li it‘t‘"‘i
‘ ‘tt‘t‘t‘
‘'tl‘'t‘tt‘t‘ ‘
‘
i
‘‘il‘t‘l t‘i‘l‘ti ‘
M‘ _i ‘ li
ilit‘ ‘ 
it‘ ‘ t‘
 i
ti‘ li‘ i‘ t‘ ‘ it‘ ‘ t‘
t ‘

 


M‘ R485‘‘t‘ll‘tt‘ii ‘l‘litt‘‘‘

M‘ R485‘ i‘ t‘ ll‘ it‘ ‘ ti ‘ l ‘  t‘ ‘ t‘ i‘
i ti‘ ‘
‘ ‘ i t‘ i
l‘ t t‘ i‘ &&5‘ 
it#‘
t‘ i‘ t‘ t ‘ it‘ i‘
 ‘t‘56‘
it#‘‘l‘t‘i
‘li
ilit‘
M‘ R485‘‘t‘ll‘t‘C‘t‘
 i
t‘it‘l‘
tll‘

t‘t‘t‘
 ‘t‘i ltl‘‘i‘l ‘t ‘t‘‘
i ti‘‘‘
t‘
tll‘ ‘t‘‘‘l ‘ti ‘‘it‘it‘ l‘ti‘
M‘ Ctll‘
t‘ iitit‘
 i
ti‘ i‘
‘ ‘ ‘ l ‘ ‘ t‘ C‘ 
t‘ ‘ ‘
t‘‘t‘R485‘
 i
ti‘li‘‘
tll‘‘t‘it‘till‘t‘‘ll‘
M‘ 
il‘il‘it
‘‘'i‘i‘‘t‘
il‘‘t‘t‘C‘t‘
M‘ t‘ R485‘ li‘ ‘ t‘
‘ itll‘ it‘ ‘ i ‘ ‘ l‘ !iti ‘ t‘
it
t‘
M‘ C
l‘ tt‘ t‘ R485‘ t‘ i‘ i ii
tl‘ ‘ !i‘ t‘ t‘  l‘
Ct ‘5‘(‘t‘

l‘
M‘ $ti‘ ‘ t‘ t ‘ i‘ i l‘ t‘ ‘ t‘ t‘ C‘ ‘
‘ t‘ t‘ C‘ il‘
t‘ ‘
tll‘‘ t‘ti‘‘ 
ti‘tt‘'i‘ it
ti‘
t‘

tll‘i‘ti

‘t‘i ‘
‘

‘
¢



  ‘
ll‘ ‘ ‘ i‘

t‘ t‘ 

tll‘ ‘ ‘
tll‘ ‘ ‘
it
‘ 

tll‘ ll‘ ‘ t‘ ‘ 

‘ 
ii‘ ‘ ‘ ll‘
't‘t‘t‘ i‘
tll‘Oi‘
tll‘ll‘t‘ ‘&6‘t‘"‘


tll‘‘
‘

‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘ ‘
‘
‘
‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘

‘
tl‘t ‘i ‘il‘ i‘‘

tll‘



 


M‘ r‘l‘‘t‘t‘C‘i‘i ii
tl‘
‘


‘it‘l‘‘t‘
 i
t‘
it‘‘‘ i‘
tll‘
M‘ ‘ ll‘
t‘ ‘ t‘ t ‘ i‘ l‘ ‘ 

tll‘ ‘ ll‘ i l‘ ‘
i!i‘i
‘
M‘ ll‘t‘t ‘lit‘i‘t‘it‘ ‘l‘

 
:‘

M‘ $ti‘‘t‘t ‘i‘i l‘t‘‘ i‘
tll‘‘
‘‘‘t‘ i‘

tll‘ il‘ t‘  ‘ it‘ 

tll‘ ‘ t‘ ti‘ ‘ 
ti‘ tt‘
'i‘it
ti‘
t‘
‘
tll‘i‘ti

‘t‘i ‘
M‘  ‘ l‘ ‘ 

tll‘ ll‘ l‘
t‘‘ ‘  ‘ ‘ 
i ‘
‘ t‘ ‘ 

‘ 
ii‘ itl‘ ‘ t‘ i‘
tll‘ il‘ 


tll‘
 ‘ t‘  ‘ ‘ i‘ i
‘ ‘ ‘ it‘
 ltl‘ l
‘ ‘
l
‘‘‘t‘‘
‘
‘

tll‘l‘
‘i‘‘‘l‘
i‘‘tt‘‘t‘'i‘i ‘
it‘
M‘ Oi‘
tll‘t‘t‘
‘!i‘t‘
‘tl ‘i‘t‘‘ll‘it‘‘
t ‘it‘ ltil‘ t‘l
ti‘tt‘‘l‘‘‘‘
M‘ ll‘t‘R485lt‘it ‘lit‘i‘t‘it‘ ‘l‘
‘

Õ


 

 

‘ ll‘ ‘ ‘ i‘

t‘ i
tl‘ t‘ itlli t‘ ‘  iitlli t‘ ‘
R‘ ll‘ ‘ t‘ ‘ 

‘ 
ii‘ ‘ ‘ ll‘'t‘ t‘ t‘ i‘

tll‘$l‘i‘t‘

ti‘t‘t‘ i‘
tll‘i‘il
l‘t‘‘‘
ti‘ itl‘ t
‘ t‘ ‘ 

‘ 
ii‘ ‘ 
‘ t‘  iitlli t‘
‘tt‘ ‘ ‘ t
‘‘
t‘
ti‘ itt‘t‘ i‘
tll‘l‘

‘ ‘ l‘ i‘ ‘ tt‘ ‘ t‘ 'i‘ i ‘ 
it‘ Oi‘
tll‘ ll‘
t‘ ‘&6‘t‘64‘‘ ll‘t ‘‘it ‘‘t‘ ‘‘t‘
‘lit‘i‘t‘
‘ ‘
‘

‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘ ‘
‘
‘‘‘‘‘‘‘

‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘

‘
tl‘t ‘i ‘il‘ i‘
tll‘‘itlli t‘‘

 

 
  ‘‘
‘ it‘ ‘ t‘ i‘ l t‘ ‘ i
i ‘ ‘ ‘
 t‘ t‘ 

‘

tl‘ 
t‘ i‘
ti‘‘ i‘ t‘‘t‘ it
‘ t

l‘
t‘r‘‘‘lti‘it‘t‘

tiit‘ ‘
‘
t‘ ti‘'ii ‘ l‘ t:‘iti‘ ‘‘t il‘‘‘ i
‘tt‘
t‘
il‘ t‘ ‘ t ii‘ i‘ ) *‘ ‘ r *‘  il‘ ‘ 
t‘

‘)ti!‘‘i

‘
l ‘‘l‘i‘t‘
it‘it‘

‘



‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘ ‘

‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘

‘
tl‘t ‘i ‘il‘
tll‘‘t il‘‘

 


M‘ ll‘ tili i ‘!iti ‘ t‘ it
t‘‘

ti ‘ t‘  t‘ ‘t‘

t ‘
M‘ i‘
it‘ lti‘ i‘
‘ ‘ itllti‘ ‘ ‘ R485‘ li‘ l‘
‘
ii
lt‘‘i i
l‘


 


M‘ 
‘
 l!it‘‘t‘t ‘

M‘ Ct‘ itil‘ ‘ ‘ itll:‘ ll‘ t il‘ ‘ ‘ t‘
‘
i ‘
itl‘t‘t ‘t‘it
‘‘t‘

‘
tl‘t‘
M‘ il‘
 i
ti‘ li‘
t‘ t‘
tll‘ ‘ t‘ t il‘ ‘ 
t‘ ‘ ‘

ttl
:‘ ‘t ‘t‘t‘
t‘ t‘ t‘C‘‘t‘t il‘ ‘tl‘t‘
t‘ &#&#&O
it#‘ t‘ ‘ it‘ t‘ l‘ ‘ t‘ t‘ il‘ ‘ ‘ &&5‘

it#‘ ‘ l‘ ‘ ‘ l‘ itil‘ l‘ it
‘ i‘ t‘ 
‘ ‘
i‘

t‘il‘‘t‘t‘
ll‘R485lt‘t ‘‘it ‘l‘l‘
‘

§   


 V‘‘
‘tl ‘i‘l‘t‘ ‘‘
i
‘i‘t‘
‘‘ti‘ ‘‘
 ‘t ‘‘it ‘l‘
t‘t‘
‘t‘it
‘‘‘

l‘ l
l‘ i  t‘ ii‘ ‘
i ti‘ ‘ ‘t‘t‘ i‘

tll‘ i‘ t‘ ‘ ‘
‘ ‘ i‘ lll‘ i‘ ‘ t‘ t ‘ ‘
i‘‘‘t‘itt‘ l‘ti‘*‘
il‘‘i‘'i‘
i‘ ‘ t‘ 
i‘ t‘ t‘ C‘ t:‘ i‘
‘ t‘ i ‘ t‘ C‘ il‘ t‘

‘ t‘ C‘ ‘ tt‘ lli ‘ t‘
tll‘ ‘ it ‘
it
‘
‘t il‘‘lit‘i‘t‘t‘ ‘‘l‘li it‘
‘

‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘ ‘
‘
‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘

‘
tl‘t ‘i ‘t
l‘ i‘
tll‘

‘
‘
‘‘‘
 V‘

‘Ctll‘‘

t‘t‘‘t‘C‘i‘ tt‘) *‘‘r *‘‘

‘

‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘ ‘

‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘

‘
tl‘t ‘i ‘‘
tll‘

 


M‘ ‘ !iti ‘ t‘ it
t‘ i‘ ll‘tili ‘ t‘ i‘ ‘ ‘ t‘ itll‘ ‘

 i
ti‘li‘
M‘ ‘ ‘ ‘ li itti‘ i ‘t‘ 
‘ ‘
tll‘"‘ ‘ li‘ i‘
‘ ‘R
485‘
M‘ 
il‘R485‘itllti‘t iti‘ i ‘‘t
lti ‘l ‘i‘t‘
'i‘
M‘ C i
ti‘ it‘
tll‘ ‘
‘ ‘ t‘ t‘ ll‘ t‘ ‘ i
‘ i‘
i tt‘ i‘ ti ‘ ‘ lt‘ ‘ t‘ t
‘ it‘ t‘ ‘ ‘ i
l‘
i
li ‘
i ti
‘
‘
M‘ ‘
‘ ‘ ‘ l ‘
tll‘ ‘ iitit‘

ti‘ t‘ t‘ t‘ C‘ i‘ 
ilit‘ i‘
i tt‘ i‘ l ‘ t ‘

‘ it‘ ll‘ t‘ 
‘ t‘ ti
‘
‘
‘

‘lli ‘
M‘ i lii‘itllti‘‘t ‘
iti ‘‘ ltil‘it‘t‘
‘l ‘it
‘
Bi
‘tt‘li‘i‘i
it‘t‘t
li‘

ti‘t‘ t‘l
ti‘
M‘ ri‘ l
ti‘ ‘ t‘ t‘ 'i t‘ i‘ il
l‘ t‘ i‘

tiit‘ i‘
it‘itti‘i
‘il‘+*‘l‘t‘ ‘

 


M‘ ‘ t ‘

 ‘ 
ti
l‘t‘ t‘lt‘ 
l ‘
‘ ‘ l‘ i‘
‘ ‘
‘ti
‘‘t‘'i t‘il‘
M‘

‘
tll‘‘tti‘ ‘

 ‘ 

i
l‘t‘
‘i‘t‘t‘‘
t‘  i ti‘ i‘ t‘ ll‘ t
t‘ i‘ tt‘ ‘
‘ li it‘
‘ i
ll‘
ti ‘t‘

‘
tl‘t‘ ‘t‘t‘‘t‘ i ti‘ l‘it‘l‘

‘ t‘ tt‘ t‘ ‘
tll‘ tili ‘ it‘ )i!‘ lt ‘ ‘ it‘ ti ‘
t ‘ i
‘ ‘t ‘ ‘ ii
lt‘t‘ 
‘ t‘t‘ t‘ 
ti‘ i‘
l‘‘
M‘ O!i  ‘ it
‘  ‘ ‘ 
‘ ‘ ‘ it
‘ t‘ t‘
tll‘ i‘ i ‘ ‘
‘

l‘ i‘
&‘ t‘""‘t‘
M‘ $ti‘ ‘ t‘ t ‘ i‘ t‘ ‘ t‘ t‘ C‘ ‘
‘ t‘ t‘ C‘ il‘ t‘
 ‘
tll‘ ‘ t‘ ti‘ ‘ 
ti‘ tt‘ 'i‘ it
ti‘
t‘

tll‘ i‘ ti

‘ t‘ i ‘  ‘
tll‘ ‘ ‘ t
‘
 i
ti‘ti‘i‘‘t‘
‘
‘‘t‘t‘C‘
‘
‘


 ‘‘
R‘‘

t‘t‘‘t‘C‘i‘ tt‘) *‘‘r *‘

‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘ ‘
‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘
‘

‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘

‘
tl‘t ‘i ‘‘‘



 


M‘ Ot‘ ‘ ‘ ‘  ‘


l‘ i‘ t‘ ‘ it‘ ‘ ‘ t‘ i‘
tt‘


‘‘t‘t‘ ti‘t ‘i
li ‘t‘l
‘‘i‘t‘‘t
t‘i‘
‘
M‘ ‘‘li it‘t‘‘‘
tll‘
l‘
M‘ ‘ i‘ ‘ t‘

it‘ ‘ i ‘ ‘ ‘ i‘ ‘ 4‘
tll‘ l‘ ‘
5%‘‘

it‘i‘it‘‘
tlli ‘l‘"‘‘
M‘ ‘‘t ‘
l‘il:‘t‘i‘‘‘t‘itll‘‘ i‘‘

tll‘
M‘ ßil‘‘‘‘‘‘t‘
t‘‘t‘‘i‘t‘t ‘

‘
.+!,

M‘ In order to be used in high-security areas IP readers require special input#output modules

to eliminate the possibility of intrusion by accessing lock and#or exit button wiring. Not
all IP reader manufacturers have such modules available.
M‘ Being more sophisticated than basic readers IP readers are also more expensive and
sensitive, therefore they should not be installed outdoors in areas with harsh weather
conditions or high possibility of vandalism, unless specifically designed for exterior
installation. A few manufacturers make such models.
M‘ In the past, the variety of IP readers in terms of identification technologies and read range
was much lower than that of the basic readers. However, with the advent of long range
multi-technology readers such as those manufactured by Nedap, Sirit, and a few others,
this is no longer so.
The advantages and disadvantages of IP controllers apply to the IP readers as well.
‘
‘
‘
‘
‘
 2c/ 9

%.%0% c% c. c 2% c% %c$

Identification and authentication (I&A) is the process of verifying that an identity is bound to
the entity that makes an assertion or claim of identity. The I&A process assumes that there
was an initial validation of the identity, commonly called identity proofing. Various methods
of identity proofing are available ranging from in person validation using government issued
identification to anonymous methods that allow the claimant to remain anonymous, but
known to the system if they return. The method used for identity proofing and validation
should provide an assurance level commensurate with the intended use of the identity within
the system. Subsequently, the entity asserts an identity together with an authenticator as a
means for validation. The only requirements for the identifier is that it must be unique within
its security domain.

Authenticators are commonly based on at least one of the following four factors:

M‘ Something you know, such as a password or a personal identification number (PIN). This
assumes that only the owner of the account knows the password or PIN needed to access
the account.
M‘ Something you have, such as a smart card or security token. This assumes that only the
owner of the account has the necessary smart card or token needed to unlock the account.
M‘ Something you are, such as fingerprint, voice, retina, or iris characteristics.
M‘ Where you are, for example inside or outside a company firewall, or proximity of login
location to a personal GPS device.
‘

c$)c 2%<c%
Authorization applies to subjects. Authorization determines what a subject can do on the
system.

Oost modern operating systems define sets of permissions that are variations or extensions of
three basic types of access:

M‘ Read (R): The subject can

M‘ Read file contents
M‘ List directory contents
M‘ Write (W): The subject can change the contents of a file or directory with the following
tasks:
 M‘ Add
M‘ Create
M‘ Delete
M‘ Rename
M‘ Execute (X): If the file is a program, the subject can cause the program to be run. (In Unix
systems, the 'execute' permission doubles as a 'traverse directory' permission when
granted for a directory.)
These rights and permissions are implemented differently in systems based on discretionary
access control (DAC) and mandatory access control (OAC).
‘
$)c  c%%
Accountability uses such system components as audit trails (records) and logs to associate a
subject with its actions. The information recorded should be sufficient to map the subject to a
controlling user. Audit trails and logs are important for

M‘ Detecting security violations

M‘ Re-creating security incidents
If no one is regularly reviewing your logs and they are not maintained in a secure and
consistent manner, they may not be admissible as evidence.
Oany systems can generate automated reports based on certain predefined criteria or
thresholds, known as clipping levels. For example, a clipping level may be set to generate a
report for the following:

M‘ Oore than three failed logon attempts in a given period

M‘ Any attempt to use a disabled user account
These reports help a system administrator or security administrator to more easily identify
possible break-in attempts.
‘
 2c/ 9%

c 

  2%: 

Access control techniques are sometimes categorized as either discretionary or non-

discretionary. The three most widely recognized models are Discretionary Access Control
(DAC), Oandatory Access Control (OAC), and Role Based Access Control (RBAC). OAC
and RBAC are both non-discretionary.

‘
c$)c*)*+  



In attribute-based access control (ABAC), access is granted not based on the rights of the
subject associated with a user after authentication, but based on attributes of the user. The
user has to prove so called claims about his attributes to the access control engine. An
attribute-based access control policy specifies which claims need to be satisfied in order to
grant access to an object. For instance the claim could be "older than 1 " . Any user that can
prove this claim is granted access. Users can be anonymous as authentication and
identification are not strictly required. One does however require means for proving claims
anonymously. This can for instance be achieved using anonymous
credentials or XACOL (extensible access control markup language).

‘
‘
$).
  


Discretionary access control (DAC) is an access policy determined by the owner of an object.
The owner decides who is allowed to access the object and what privileges they have.
Two important concepts in DAC are

M‘ File and data ownership: Every object in the system has an „
. In most DAC systems,
each object's initial owner is the subject that caused it to be created. The access policy for
an object is determined by its owner.
M‘ Access rights and permissions: These are the controls that an owner can assign to other
subjects for specific resources.
Access controls may be discretionary in ACL-based or capability-based access control
systems. (In capability-based systems, there is usually no explicit concept of 'owner', but the
creator of an object has a similar degree of control over its access policy.)

‘
 $)+
  



Oandatory access control (OAC) is an access policy determined by the system, not the
owner. OAC is used in multilevel systems that process highly sensitive data, such as
classified government and military information. A multilevel system is a single computer
system that handles multiple classification levels between subjects and objects

M‘ Sensitivity labels: In a OAC-based system, all subjects and objects must have labels
assigned to them. A subject's sensitivity label specifies its level of trust. An object's
sensitivity label specifies the level of trust required for access. In order to access a given
object, the subject must have a sensitivity level equal to or higher than the requested
object.
M‘ Data import and export: Controlling the import of information from other systems and
export to other systems (including printers) is a critical function of OAC-based systems,
which must ensure that sensitivity labels are properly maintained and implemented so that
sensitive information is appropriately protected at all times.

Two methods are commonly used for applying mandatory access control:

M‘ Rule-based (or label-based) access control: This type of control further defines specific
conditions for access to a requested object. All OAC-based systems implement a simple
form of rule-based access control to determine whether access should be granted or
denied by matching:
M‘ An object's sensitivity label
M‘ A subject's sensitivity label
M‘ Lattice-based access control: These can be used for complex access control decisions
involving multiple objects and#or subjects. A lattice model is a mathematical structure
that defines greatest lower-bound and least upper-bound values for a pair of elements,
such as a subject and an object

.
Few systems implement OAC; XTS- 00 and SELinux are examples of systems that do. The
computer system at the company in the movieÔ„
is an example of OAC in popular culture.

.$)
)*+  



Role-based access control (RBAC) is an access policy determined by the system, not the
owner. RBAC is used in commercial applications and also in military systems, where multi-
level security requirements may also exist. RBAC differs from DAC in that DAC allows
users to control access to their resources, while in RBAC, access is controlled at the system
level, outside of the user's control. Although RBAC is non-discretionary, it can be
distinguished from OAC primarily in the way permissions are handled. OAC controls read
and write permissions based on a user's clearance level and additional labels. RBAC controls
collections of permissions that may include complex operations such as an e-commerce
transaction, or may be as simple as read or write. A role in RBAC can be viewed as a set of
permissions.

Three primary rules are defined for RBAC:

1.‘ Role assignment: A subject can execute a transaction only if the subject has selected
or been assigned a role.
2.‘ Role authorization: A subject's active role must be authorized for the subject. With
rule 1 above, this rule ensures that users can take on only roles for which they are
authorized.
3.‘ Transaction authorization: A subject can execute a transaction only if the transaction
is authorized for the subject's active role. With rules 1 and 2, this rule ensures that
users can execute only transactions for which they are authorized.

Additional constraints may be applied as well, and roles can be combined in a hierarchy
where higher-level roles subsume permissions owned by sub-roles.

Oost IT vendors offer RBAC in one or more products.

‘

‘

 

Temporal constraints are formal statements of access policies that involve time-based
restrictions on access to resources; they are required in several application scenarios. In some
applications, temporal constraints may be required to limit resource use. In other types of
applications, they may be required for controlling time-sensitive activities. It is these time-
based constraints (in addition to other constraints like workflow precedence relationships)
that must be evaluated for generating dynamic authorizations during workflow execution
time. Temporal constraints may also be required in non workflow environments as well. For
example, in a commercial banking enterprise, an employee should be able to assume the role
of a teller (to perform transactions on customer accounts) only during designated banking
hours (such as 9 a.m. to 2 p.m., Oonday through Friday, and 9 a.m. to 12 p.m. on Saturday).
To meet this requirement, it is necessary to specify temporal constraints that limit role
availability and activation capability only to those designated banking hours.
Popular access control policies related to temporal constraints are the history-based access
control policies, which are not supported by any standard access control mechanism but have
practical application in many business operations such as task transactions and separation of
conflicts-of-interests. History-based access control is defined in terms of subjects and events
where the events of the system are specified as the object access operations associated with
activity at a particular security level. This assures that the security policy is defined in terms
of the sequence of events over time, and that the security policy decides which events of the
system are permitted to ensure that information does not ³flow´ in an unauthorized manner.
Popular history-based access control policies are Workflow and Chinese Wall, which are
described below.
‘
‘

5
6
=

Based on the definition provided by the Workflow Oanagement Coalition (WFOC), an

international organization of workflow vendors, users, and research groups, a workflow is a
representation of an organizational or business process in which ³«documents, information,
or tasks are passed from one participant to another in a way that is governed by rules or
procedures.´ A workflow separates the various activities of a given organizational process
into a set of well-defined tasks. Hence, typically, a workflow (often synonymous with a
process) is

0 ( )


  5
6
=  
The goal of the Workflow policy is to maintain consistency between the internal data and
external (users¶) expectations of that data. Note that many individual process instances may
be operational during process enactment; each needs to be associated with a specific set of
data relevant to that individual process instance [WFOC99]. Data servers Worklist servers
Oonitor servers Design-time component (process definition tools) Run-time component
(process definition tools) Task servers specified as a set of tasks and a set of dependencies
among the tasks, and the sequencing of these tasks is important. The various tasks in a
workflow are usually carried out by several users in accordance with organizational rules
relevant to the process represented by the workflow

The representation of a business process using a workflow involves a number of

organizational rules or policies. An important class of organization policies is the
organization¶s security policies. Within the realm of security policies, access control policies
play a key role, and hence defining and enforcing access control requirements becomes a key
function of a Workflow Oanagement System (WFOS).
Figure 1 presents a schematic diagram of the overall architecture of a WFOS, which consist
of two main components: design-time and run-time. The design-time component consists of a
set of tools (called the process definition tools) that are used for defining and modeling the
business processes and their constituent tasks. A process definition consists of a process name
(e.g., purchase order process), the definition of various tasks within the process (e.g.,
purchase order approval task), and a set of business rules associated with the process (e.g.,
task sequence or data flow among tasks). The run-time component of a WFOS (also called a
workflow engine) consists of a set of servers that interpret the process definition and create
and maintain process instances. Task instances associated with each process instance are also
created (based on process definition). The list of instantiated tasks pending to be executed is
presented to the user (for his or her action) through a worklist server. The tasks themselves
are executed in task servers. Data servers act as repositories of data that are needed by tasks.
In addition, there are monitor servers that maintain the execution history for various process
or task instances to facilitate run-time access control decisions.
 2c/ 9%%
c/c%%%
c. %%c%
0 c 


 2c%


This section describes major access control mechanisms that support most of the popular
access control policies mentioned in Section 2, as well as the limitations of the mechanisms.
Note that the mechanisms discussed in this section are for standalone host systems; the
mechanisms for distributed systems are covered in Section .
In general, access control mechanisms require that security attributes be kept for users and
resources. User security attributes can consist of categories such as user identifiers, groups,
and roles to which users belong, or they can include security labels reflecting the level of
trust bestowed on the user. Resource attributes can take on a wide variety of forms. For
example, they can consist of sensitivity labels, types, or access control lists. In determining a
user¶s ability to perform operations on a resource, access control mechanisms compare the
user¶s security attributes to those of the resource.
Access control checks can be determined (evaluated) based on a previously determined set of
rules. For example, the security label of the user must be greater than or equal to the security
label of the resource for the user to read the contents of the resource. Access control checks
can also be determined based on an attribute-matching algorithm. The user may perform a
read operation on a resource if the user¶s identity and read operation pair is included in the
access control list of the resource. Other characteristics of access control mechanisms include
attribute review and management capabilities. For example, can the access control system
determine the permissions that are associated with a user or the users who can access a
resource, or better yet, both? Who can specify permissions? Can permission specification be
delegated, and if so, does delegation imply further delegation? [FKC03] Access control
mechanisms are often characterized in terms of their policy support; this section presents
some major access control mechanisms along with discussion of the policies they support and
limitations.
Note that, to be practical, the discussions exclude the limitations for each access control
mechanism and the capabilities that are beyond the intended scope of the original model²for
example, the historical recording capability for ACL, or rule constraints for OAC.

c$)c

  c $ + 

Resource-oriented access controls, such as access control lists (ACLs) [Pfl97], are the most
common access control mechanism in use [Bar97] and by far the most common mechanism
for implementing DAC policies. An ACL is an example of a policy concept that is frequently
implemented directly or as an approximation in modern operating systems [At el al97,
Ben9 ]. An c
associates the permitted operation to an object and specifies all the subjects
that can access the object, along with their rights to the object. That is, each entry in the list is
a pair (subject, set of rights). From another point of view, an ACL corresponds to a column of
the access control matrix [Sum97]. ACLs provide a straightforward way of granting or
denying access for a specified user or groups of users. Without the use of access control lists,
granting access to the level of granularity of a single user can be cumbersome.
The composition of an ACL entry is as follows:

‡    specifies that the ACL entry is one of the following: the file owner, the owning
group, a specific named user, a specific named group, or other (meaning all other users).

‡ : + describes the specific instance of the tag type. For specific named users and
specific named groups, the qualifier field contains the userid and groupid, respectively.
Qualifier fields for the owner entry and owning group entries are not relevant because this
information is specified elsewhere.

‡

 
 specifies the access rights such as read, write, or execute for the entry.

For example,
,=>(is read, is write, and is execute)
File owner tag (with empty qualifier) specifies the owning user has read, write, and execute
permission.

7+,=)
Named user tag specifies the user ` (qualifier) has read and write permission.


 ,)>
Group owner tag (with empty qualifier) specifies the owning group has read and execute
permission.


 7
 +,))>
Named group tag specifies the group
„`
(qualifier) has execute permission.

,))
Other tag (with empty qualifier) specifies all other users (than the owning and named users
and groups) have the read permission.

To determine the read, write, and execute access, the access check is performed on the ACL
entries in the following algorithm:
1. If the user requesting access is the object owner, and the requested permission is
granted by the ACL entry, then access is granted.
2. If the user requesting access is a named user in the ACL, and the requested permission
is granted by the ACL entry, then access is granted.
3. If the user requesting access is in the owning group of the file, or is a member of any
named groups, and the requested access permission is granted by the ACL entry of the
owning group or the ACL entry of any of these named groups, then access is granted.
. If the user requesting access is a member of any of the named groups, and the
requested access permission is granted by the ACL entry of any of these named
groups, then access is granted.
. If the requested access permission is granted by the ³other´ entry, then access is
granted, otherwise access is denied.

l‘&‘i‘‘i lii‘ ! l‘‘‘ C)‘‘ti‘! l‘‘lit‘‘itii‘‘t‘ ‘
 ‘Ö
‘ ‘‘,lii‘i‘‘‘‘i‘‘il
‘
l‘ t
i ‘‘‘
‘ ‘  ‘ r‘ ‘ ‘ ‘ ‘ il‘ t‘ lit‘ i‘ 
‘ ‘ t‘ ll‘ 

‘

‘t‘t‘ it‘ t
‘ ll‘ ‘
‘‘ ‘
t‘ l‘ ‘
 
‘ l‘
!
t‘it‘
‘‘it‘‘!
t‘ ‘‘‘

‘‘t‘ l‘
‘i‘i‘t‘Ö
  ‘ ll‘t‘‘‘‘

‘

‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘ ‘
‘
‘
C 
il‘ ti ‘ t ‘ 
‘ ‘ Oi
t‘ O‘ ri‘ ‘ "‘ ‘ -‘
 l‘ C)‘‘
ilti‘

‘
tl‘$‘‘O‘ri‘t ‘titi‘‘
‘t‘
C)‘‘‘
ii
‘
‘
‘‘‘il‘‘l‘
‘i ‘t‘ti‘i‘ ‘
tt‘
.‘
t!t‘ ‘‘
li
i ‘ ‘t‘ /
it0‘t
‘ (*-‘‘ (*-‘ it‘

‘ ‘)*(-‘‘ßB%‘l‘ t‘t‘ i l tti‘ ‘ C)‘ i ‘t‘
li‘


‘
tl‘ 
i ‘‘t
ti‘
it‘‘
ti‘""‘O‘til‘‘O‘ri‘
‘(*-‘)*(-‘ßB%‘ C)‘i l tti‘‘lit‘i‘ i!‘C‘‘
‘‘ C)‘i t‘it‘i‘‘t‘‘t‘'ti‘/ 
  


0‘
t‘it‘i‘ii
lt‘t‘t i‘ll‘iil ‘‘‘‘t‘jt‘‘tt‘
j
t‘
ß‘it
‘i‘
‘‘i t‘‘l‘‘t‘
‘ll‘‘t‘ C)‘i‘l‘

‘ ll‘
t‘ i i
l‘ i‘ ‘ itti‘ 
ill‘ ‘‘ l ‘ t ‘ ‘‘l!i
l‘ ‘

ttl‘
 i ‘

‘
tl‘li
‘i‘'i‘‘ti‘i t‘‘t‘
i‘ i ii
t‘ ‘t‘ C)‘ ‘ i‘ ii
lti;‘t‘ t‘ 
i &‘ ‘
t‘ lit‘ ‘ it‘ ii
lt‘t‘
tll‘ iitt‘ C)‘ 
ill‘ it‘‘ l ‘ 
‘ ‘
‘‘ ‘ß‘! l‘i‘‘ i ti‘
i‘t‘
 ‘ ‘‘li
‘ l‘t‘
t‘it‘ i‘ 'it‘ lil‘tt‘t‘ ‘ li
‘ l‘ ill‘ ‘t‘
‘ i l t‘
‘t‘
ti ‘ t ‘ ll‘ ‘ ‘ ‘ t‘ ‘ t‘ li
ti‘
‘ ‘ t ‘ ‘
it i‘ ßt‘ it‘ t ‘ ‘ ti‘ ‘  t‘ ‘ C)‘ i
‘ ‘ t‘
C)‘ ‘ lt t‘ i‘ i‘ i
it‘ 
j
t‘ t‘ ‘ l‘ ‘ ‘ it‘
ii
lt‘t‘iti‘‘ l‘t‘ll‘/li
0‘tt‘i‘
‘
‘t‘t ‘1_2‘‘

‘
÷

‘
‘
t‘t‘ ‘ 

‘
tl‘ i‘t‘

ilit‘ lit‘ ‘

‘lit‘ ‘i‘‘ ‘t‘‘

ii
‘
j
t‘l ‘it‘‘ ‘‘

‘‘it‘‘!
t‘‘‘

ilit‘t ‘


‘t‘‘
j
t‘i‘ll‘i‘t‘
j
t‘tt‘i‘'ti ‘

‘‘‘

ilit‘‘
t‘ 
j
t‘ t‘
‘ t‘
‘ t t‘ ‘ ‘ t‘ i‘ ‘ ‘ 

‘
tl‘ lit:‘ ‘ C)‘ i‘
tt
‘t‘‘ 
j
t‘‘
ii‘ i
‘
j
t‘ ‘

‘t‘ 
j
t‘ il‘ ‘

ilit‘
lit‘i‘tt
‘t‘‘
j
t‘‘
ii‘i
‘
j
t‘t‘
j
t‘ ‘

‘ ‘

ilit‘i‘
‘t
t‘itii‘tt‘
t‘itii‘t‘
j
t‘‘
ii‘t‘ti‘t‘
‘ll‘
t‘ t‘ ‘ ‘ ‘ t‘

ilit‘ i‘ 
‘
‘ t‘ ti ‘ t‘ 

‘

tl‘ ti!‘
‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘
‘

ilit‘lit‘i‘t‘t
l‘i‘
it‘ it‘‘
j
t‘‘
ii‘t‘
j
t.‘i t‘

‘t‘i‘t‘lit‘i‘‘

ilit‘‘‘i‘3
j
t‘t‘‘ti4‘ ‘
j
t‘i ‘
‘

ilit‘i‘‘‘t‘
j
t‘i ‘t‘

‘iil ‘‘it‘
‘
‘l‘t‘ti‘‘


iliti‘‘
i ‘i il‘t‘ti
t‘_‘li‘ti
t‘i‘ ‘t ‘

iliti‘

‘
‘
i‘‘t‘ ‘
‘t‘ttil‘‘t‘‘‘‘

ilit‘t‘ i‘‘
‘
t‘ ‘l‘ti‘

it‘i‘itl‘t‘t‘‘‘/i t0‘
‘
‘

‘‘‘‘‘‘‘‘‘‘‘‘‘ ‘
‘
‘

ilit‘lit‘
‘t‘‘‘‘t‘

‘
tl‘ ti!‘‘i
il‘t ‘‘


iliti‘i‘tt‘it‘i‘‘t‘i‘ll‘

‘tt‘‘ti ‘‘‘ i‘
j
t‘‘
t‘

l‘‘‘

iliti‘i‘t‘l‘ll‘i‘t‘t ‘‘

iliti‘i‘
t‘ li ‘ t
ti‘ 
i ‘ ‘ t‘t‘ ii
l‘

‘
tl‘ 
 ‘ t‘t‘
i t‘ ll‘ i‘t‘ t ‘t‘ t ‘ iti‘‘ lit‘ ‘

iliti‘ ‘ 
‘ ‘ (‘

t‘‘


iliti‘ t‘ ti‘ lit‘ !
t‘ t‘
‘ ‘ il‘ tt‘ t‘
t‘ (‘ i t‘ ‘
‘
ll‘t‘ i‘ 

‘t‘ 
j
t‘
‘ i ‘
i‘ ‘ti‘ ‘

iliti‘t‘ t‘ ‘
‘t‘ i t‘
‘
l‘t‘‘

‘t‘ti‘‘
j
t‘
‘ti ‘‘

iliti‘ ‘
t‘lt ‘
ti‘
‘
‘ii
lt‘t‘i l t‘‘
Ct‘t‘t‘ C)‘t‘

ilit‘lit‘ 
i ‘ ‘it‘ii
lt‘t‘i‘t‘
j
t‘
tt‘
‘ 

‘ ‘ ti
l‘ 
j
t‘ ‘ ‘ ‘ t‘ t ‘ l‘

‘ 
‘ ‘ ‘


ilit‘ lit‘ ‘ 
‘ ‘ tt‘ ‘
ti‘ ‘ ‘ t‘ ‘ ti‘ t‘ i‘ l‘
ii
lt‘t‘‘

‘t‘‘
j
t‘ i‘t‘‘‘‘i il‘! iti‘ß‘! l‘
‘‘
j
t‘i‘lt‘t‘t ‘ t‘ ‘

iliti‘‘t‘
j
t‘ ‘‘.‘
lit‘ i ‘‘i l‘'ti‘
‘‘/‘‘

‘t‘ti‘
j
t 0‘'i‘t‘t ‘
t‘ ‘‘l ‘
‘t ‘‘.‘

ilit‘lit‘ß‘ti‘‘

ilit‘lit‘
ll‘ 'i‘ t‘ 
i ‘ t‘ iti‘ t‘ ti
t‘ i‘ i‘ i
it‘ 
j
t‘ t‘
‘l‘‘ ‘it‘ii
lt‘t‘iti‘‘ l‘t‘% C‘li
i‘‘t‘i‘t‘

 
ill‘ l‘ t‘ ‘ ii  ‘ ‘

ilit‘ lit‘ t ‘ t‘ ‘ tt‘

iliti‘
‘t‘ ‘‘i l‘
 ‘‘ t‘
tl‘‘t‘ t‘‘t ‘
‘it ‘‘

‘
tl‘lit‘‘

ilit‘lit‘‘ i ‘i‘
l‘4‘
‘
‘
‘
 

÷
 

÷


‘
Rl
‘ 

‘
tl‘ RB C‘ 1ß C"2‘ li
i‘  lt‘ t‘ 

‘ ‘ ‘ t‘
i ti‘ ‘ t‘
i‘ ‘ t‘ 
tiiti‘ t‘ ‘  ‘ Rl
‘ li
i‘ 'i‘ t‘
itii
ti‘ ‘ l‘ i‘ t‘ t ‘ ‘ l‘ i‘ ‘
ll
ti‘ ‘  ii‘ t‘ ‘ 
‘
it‘t‘‘5‘j
‘
ti;‘it‘i‘t‘i‘‘‘t‘‘
ti‘‘i
iliti‘

it‘it‘‘ti
l‘i ‘
tiit‘t‘‘
ii ‘ll‘t‘

‘
‘‘
i‘ll‘t‘!
t‘

‘ti ti‘‘
j
t‘‘
ii‘‘l‘(‘‘ i‘
ti ti‘t‘t‘l‘‘
The RBAC model taxonomy consists of four models ± core RBAC, hierarchical RBAC, static
constrained RBAC, and dynamic constrained RBAC. „ c  covers the basic set of
features that are included in all RBAC systems. It is the inclusion of this set of features that
distinguishes RBAC from other forms of authorization management systems.  
c  adds the concept of a role hierarchy, defined as a partial ordering on roles, using an
inheritance relation. „

 c  includes static and dynamic SOD (Separation of
Duties) properties, which are, respectively, separation of duty rules that apply at all times, or
on a session-by-session basis. 
„

c adds constraint relations imposed
on role assignment relations. 

 „

 c  imposes constraints on the
activation of sets of roles that may be included as an attribute of a user¶s subjects. The
following describe the four different types of RBAC.



 c

RBAC assumes that all permissions needed to perform a job function can be neatly
encapsulated. In fact, role engineering has turned out to be a difficult task. The challenge of
RBAC is the contention between strong security and easier administration. For stronger
security, it is better for each role to be more granular, thus having multiple roles per user. For
easier administration, it is better to have fewer roles to manage. Organizations need to
comply with privacy and other regulatory mandates and to improve enforcement of security
policies while lowering overall risk and administrative costs. Oeanwhile, Web-based and
other types of new applications are proliferating, and the Web services application model
promises to add to the complexity by weaving separate components together over the Internet
to deliver application services. Ooreover, the allocation of files and servers (therefore, access
control) may be incompatible with organization structure (therefore, process) that requires
users to focus on practical matters such as opening accounts and paying bills. RBAC products
have sometimes proved challenging to implement and will, for some organizations, need to
be combined with rule-based and other more time-tested access control methods to achieve
the most practical value [Des03].
Although an improvement on flexibility compared to DAC and OAC, RBAC ties users to
roles and associates those roles with privileges toward objects in the authorization process; it
does not leave access control to the discretion of the users or roles. Therefore, RBAC is
difficult to use for supporting DAC policy. It has been shown [SO02] that it is possible,
though difficult, to implement DAC using RBAC by using multiple roles associated with
each system object. Several variations of DAC can be supported using this method.
Unfortunately, a large number of resources are required: for each object in the system, four
roles and eight permissions must be created. Thus this approach to implementing DAC in
RBAC is more of theoretical than practical interest. On the other hand, for real-world
implementers this RBAC limitation does not present a significant problem, since most
operating systems come equipped with some form of DAC, the most basic form of access
control.
The least privilege condition is often difficult or costly to achieve because it is difficult to
tailor access based on various attributes or constraints. A more serious concern in using
RBAC is the implementation of separation of duty controls. Existing RBAC products have
only rudimentary SOD features. Static SOD may be supported, but very few provide dynamic
SOD. While these deficiencies may be remedied as more sophisticated products come on the
market, there is a more subtle problem with using RBAC to implement SOD. With careful
allocation of privileges to roles, SOD is easy and efficient to accomplish with RBAC. But if a
single individual has access to all privileges needed to accomplish some critical function,
then the system can be compromised regardless of the role structure. For example, suppose
that two roles for initiating and approving expenditures are established with SOD between
them. That is, the role that can initiate expenditures does not have the permission required to
approve them, and the role for approval cannot initiate them. But if a third role is later
assigned the permission to approve expenditures, and some user has access to both the
initiating role and this third role, then separation of duty has been violated. In effect, a
loophole has been created in the role structure. Thus, great care must be used in assigning
permissions to roles to ensure that SOD requirements are not compromised. The lack of the
mentioned features limits the number of policies RBACcan support. Further, RBAC is
implemented under the specific access control policy, thus the flexibility is hard to support
when the policy combination is required.

 $);)+ c

  + 

A number of efforts have led to the development of Extensible Oarkup Language (XOL)-
based frameworks for specification of access control information. The Organization for the
Advancement of Structured Information Standards¶ (OASIS) Extensible Access Control
Oarkup Language (XACOL) and IBO¶s XOL Access Control Language (XACL) are access
control policy specification frameworks that are mainly geared towards securing XOL
documents, but they can be applied to other system resources as well. Currently these
languages do not provide direct support for representing traditional access controls such as
DAC or OAC, but a recent extension to XACOL incorporates RBAC support. Section 3. .1
introduces XACOL. Section 3. .2 discusses using XOL for policy implementation. Section
3. .3 discusses the limitations of access control languages.
‘

 >* c


 6  ;c  $
XACOL is a general-purpose language for specifying access control policies [Pro0 ]. In
XOL terms, it defines a core schema with a namespace that can be used to express access
control and authorization policies for XOL objects. Since it is based on XOL, it is, as its
name suggests, easily extensible. XACOL provides features that make it possible to
supppolicies [Oas0 ]; it provides the capability to request a specified action within a system
using a standardized syntax, and then receive one of four replies:
‡ Permit ± action allowed
‡ Deny ± action disallowed
‡ Indeterminate ± error or incorrect#missing value prevents a decision
‡ Not Applicable ± request cannot be processed.

XACOL¶s standardized architecture (Figure 2) for this decision-making uses two primary
components: the Policy Enforcement Point (PEP) and the Policy Decision Point (PDP). The
PEP constructs the request based on the user¶s attributes, the resource requested, the action
specified, and other situation-dependent information through PIP. The PDP receives the
constructed request, compares it with the applicable policy and system state through the
Policy Access Point (PAP), and then returns one of the replies specified above to the PEP.
The PEP then allows or denies access to the resource. The PEP and PDP components may be
embedded within a single application or may be distributed across a network.
To make the PEP and PDP work, XACOL provides a policy set, which is a container that
holds either a policy or other policy sets, plus (possibly) links to other policies. Each
individual policy is stated using a set of rules. XACOL also includes methods for combining
these policies and policy sets, allowing some to override others. This is necessary because the
policies may overlap or conflict. Possible conflicts are resolved through policy-combining
algorithms. For example, a simple policy-combining algorithm is ³Deny Overrides,´ which
causes the final decision to be Deny if any policy results in Deny. Conversely, other rules
could be established to allow an action if any of a set of policies results in Allow. XACOL
includes standard policy-combining algorithms, and developers can create their own as well.
Determining what policy or policy set to apply is accomplished using the Target component.
A target is a set of rules or conditions applied to each subject, object, and operation. When a
rule¶s conditions are met for a subject, object, operation combination, its associated policy or
policy set is applied using the process described above.

Web applications can use RBAC services defined by the OASIS XACOL Technical
Committee.3 The XACOL specification describes building blocks from which an RBAC
solution is constructed. The specification then discusses how these building blocks may be
used to implement the various elements of the RBAC model
  ; 
  c

 
+

As indicated by Ramaswamy Chandramouli of NIST in the book „ c  „
„,

[FKC03] XOL and XOL schema specification languages gained acceptance as standards for
representing, interchanging, and presenting both metadata and complex content models in a
platform-independent fashion because the XOL schema provides a very extensible means for
specifying document structures through a comprehensive type definition language. Hence, it
is the best candidate for a linguistic framework that is needed to express an access control
model that embodies multiple policy requirements. The associated access control data for a
given enterprise domain can then be encoded in an XOL document, and the conformance of
data to the enterprise access control model can be obtained by validating the XOL document
against the XOL schema that represents the enterprise access control model through a type of
software called XOL parsers. These XOL parsers are based on standard application
programming interfaces such as Document Object Oodel (DOO). These parser libraries
implemented in various procedural languages enable an application program written in the
corresponding procedural language to create, maintain, and retrieve XOL-encoded data.
Hence, we have a programmable framework to extract enterprise access control data in XOL
documents, properly

interpret them, and map them to the native data formats for access control mechanisms
present in heterogeneous application systems within the enterprise.
Besides XOL, XACOL, and XACL, there are other access control languages developed in
research environments, though they are not available as off-the-shelf products. Oost of them
have properties similar to those of the access control languages discussed here and are
therefore constrained by the same limitations.
‘



 ;)+ c

 
XOL-based and other access control languages provide capabilities for composing policies
from scratch, allowing users to specify a policy, together with the authorizations through the
programming of the language. However, as with the RuBAC, the limitation is in the
expressive power of higher-order logic such as the expressions of historical-based constraints
and domain constraints.
For example, historical-based access constraint requires the manipulation and recording of
access states (such as granted privileges). Oost access control languages do not provide tools
for the expressions of historical constraints for historical-based access control policies, thus
leaving the completeness of the constraint logics to the policy writer. Domain constraints are
based on the semantic information pertaining to an enterprise context; a grammar-based
language cannot deal with content-based constraints. For example, an XOL schema is
insufficient for a complete specification of the RBAC model for an enterprise since the latter
contains content-based domain constraints. An example is not allowing more than one user to
be assigned to the role of ³division manager´ (role cardinality constraint) and not allowing
the roles ³tester´ and ³developer´ to be assigned to the same user (SOD constraint).
 2c/ 9%%%

c0 %%c%

Safety is an important feature of an access control systems, and is needed to ensure that the
access control configuration (e.g., access control model) will not result in the leakage of
permissions to an unauthorized principal. Thus, a configuration is said to be safe if no
privilege can be escalated to an unauthorized or unintended principal. Safety is fundamental
to ensuring that the most basic of access control policies can be enforced. However, it has
been proven that the safety of an access control configuration cannot be decided for an
arbitrary configuration of a general access control model, such as an access control matrix.
This section consists of two subsections: Section .1 discusses the methods to achieve safety,
and Section .2 covers the concept of Separation of Duty for safety.

c!

Safety is achieved either through the use of restricted access control models that can be
proven in general for that model, or via expressions called constraints that describe the safety
requirements of any configuration [JT01].
‘
‘
+ c

 
+ 



Oultilevel security or separation of duty, such as OAC policy, is enforced by the safety
configuration; however, a specialized model designed for a restricted or static policy is
difficult to use because it is hard to ensure that the restrictions are satisfied. For example,
Bell-LaPadula and Domain and Type Enforcement, which require completely trusted
principals to assign subjects and objects to types (or labels), lack a simple, comprehensive
approach to constraints.
‘
‘
‘

 


Constraints can be expressed in a policy that restricts access in straightforward access rules;
however, creating constraint expressions for safety is a difficult task, because the entities to
which safety constraints are given are not known in advance. In general, a safety constraint is
expressed by a first-order predicate logic, and a few logical constraint expression languages
have been proposed, but such languages are too complex for administrators to determine if a
set of constraints really expresses the desired safety requirements properly. In addition, the
design of higher-level expression models must be considered because approaches may be
chosen that are too limited, lack necessary extensibility, and prevent administrators from
understanding the relationships between constraints.
There is a trade-off between the expressive power of an access control model and the ease of
safety enforcement. In a restricted model, such as Bell-LaPadula, constraints are implicit in
the model¶s definition (e.g., a subject of one label cannot write to any object of a ³lower´
security label). Therefore, safety enforcement is trivial, but policy expression is limited. On
the other hand, general policy expression models such as RBAC (Section 3. ) permit the
definition of arbitrary constraints. In this case, the expression of safety requirements has
proven to be difficult

 

 . +

In general, by restricted model, the access control policies are expressed only once by a
trusted principal and fixed for the life of the system, so that access control policies are safe by
definition. Currently, almost all safety-critical systems (such as military systems) use
restricted access control models, such as Bell-LaPadula [Pfl97] or Domain and Type
Enforcement [BSS9 ], because constraint expression languages are far too complex for
typical administrators to use properly. However, flexibility that may be added to these models
introduces the possibility of safety problems. For example, an organization uses the Bell-
LaPadula model to define the extent to which principals of one label may make changes to
the assignment of objects and subjects to labels. Principals that are not fully trusted are
created that can modify the model. But if complete trust is not practical, then there is a
possibility of safety violation. Therefore, more flexible access control modeling is often
necessary when more complex safety policies are required. For example, in commercial
systems, some policies require that a principal¶s or role¶s right change dynamically to prevent
unauthorized actions (e.g., signing a check). Thus, configuration changes are part of the
application domain. In addition, the notion that an administrator may not be fully trusted is
built into some access control models, such as RBAC. To enable the enforcement of safety
under these conditions, some access control models include the concept of SOD [FKC93].
As a security principle, SOD has had wide application. The purpose of SOD is to ensure that
failures of omission or commission with an organization are caused only by collusion among
individuals, making such failures riskier and less likely. It also minimizes chances of
collusion by assigning individuals of different skills or divergent interest to separated tasks;
thus, SOD is enacted whenever conflict of interest may otherwise arise in assignment of tasks
within an organization.
‘
‘
c$)

 

 . 

.$
As a security mechanism, SSOD addresses two separate but related problems. Static
exclusivity is the condition for which it is considered dangerous for any user to gain
authorization for conflicting sets of capabilities. The motivations for exclusivity relations
include, but are not limited to, reducing the likelihood of fraud or preventing the loss of user
objectivity. The other problem is more of an assurance principle, dealing with the potential
for collusion where the greater the number of individuals that are involved in the execution of
a sensitive business function, such as purchasing an item or executing a trade, the less likely
any one user will commit fraud or that any few users will collude in committing fraud.
To illustrate the value and limitations of static exclusivity constraints in enforcing separation,
consider the capabilities of a cashier and a cashier supervisor, where the capability to void
erroneous cashier transactions is assigned to the cashier supervisors. Clearly, a user¶s ability
to execute the capabilities of both cashier and cashier supervisor within a single subject
would constitute a conflict of interest (i.e., a user acting as cashier would be able to void his
or her own transactions). One prescribed approach to this security issue is to restrict any user
from simultaneously obtaining membership to both cashierapproach could impose
unacceptable operational restrictions (i.e., the users authorized for the role and capabilities of
cashier supervisor would never be able to perform the functions of the cashier). Examples of
SSOD policies are RBAC and RuBAC (Sections 3. and 3. ).
SOD constraints may require that two roles be mutually exclusive, because no user should
have the privileges from both roles. This might be done, for example, to deny any user the
ability to both enter and authorize an order for disbursement of funds. However, permission
³escalation,´ violating SOD requirements, may occur if a third role is assigned the requisite
permissions without being included in SOD constraints. A user might have one of the
mutually exclusive roles, yet acquire this third role and thereby gain the ability to violate the
requirement that no individual can both enter and authorize funds disbursement. In an
environment where there are numerous users, attributes, objects, and relations, safety needs to
be carefully considered.
‘
‘
‘
$).
 

 . .
.$
Separation of duties can be enforced dynamically (i.e., at access time), and the decision to
grant access refers to the past access history. For example, a user may be allowed to be a
member of more than one user group, but to prevent conflict of interest, some policies
mutually exclude user groups from being assigned to the same user. A person could be both a
cashier and an accountant for a company, but only one and not both of the roles can be
activated as the user performs a job-related responsibility or function.
There are various types of DSOD, such as two-person rule; the first user to execute a two-
person operation can be any authorized user, whereas the second user can be any authorized
user different from the first [SS9 ]. Another important type of DSOD is a history-based SOD
that regulates, for example, that the same subject (role) cannot access the same object for
variable number of times. Popular DSOD policies are the Workflow policies and Chinese
Wall
  
%

Although only the most commonly used access mechanisms are discussed in this document,
many extensions, combinations, and different mechanisms are possible. Trade-offs and
limitations are involved with all mechanisms and access control designs, so it is the user¶s
responsibility to determine the best-fit access control mechanisms that work for their business
functions and requirements.
Also included in this document are the most commonly used access control policies. Since
access control policies are targeted to specific access control requirements, unlike access
control mechanisms, specific limitations cannot be inherently associated with them. And like
access control mechanisms, it is up to the users to select the best policies for their needs.
The complex issues of safety and the principles to achieve it are discussed. Although safety
has been theoretically proven hard (non-tractable computation time) [HRU7 ], there are easy
(practical) means to meet the requirement by providing some invariants that are not limited
by the general access control model.
In addition to the limitations and issues, a quality metric depends not only on the
consideration of administration cost, but also on the flexibility of the mechanism helping the
user in assessing or selecting among access control systems.