GCT6

1
????(2)

• GCT???6?
• 2002?12?

2
????

• ??? OGSA Security
• ??? Akenti
• ??? CAS
• ??? GAA
• ? ? Web Service Security

3
OGSA Security Consideration
Libingchen_at_ict.ac.cn
18 December 2002
4
Globus and OGSA
Our immodest goal is to become the Linux of
distributed computing
Ian Foster
The industrial uptake is also an important
factor, because academia alone was in history
never strong to establish new standards.
5
Whats OGSA
Grid computing
Web Service
Grid Service
Service Grid
OGSA
SOAP
WSDL
UDDI
XML
Resource Grid
Network
Storage
Computing

6
Security in OGSA
the details of security are out of scope of
this specification. Instead, security should be
addressed in related specifications that defined
how the abstract interactions are bound to
specific communication protocols, and to specific
programming environments.
OGSA Specification
7
OGSA Security Roadmap
The relationship between OGSA Security
Specification and Web Service Security
Specification

• OGSA Security specification leverage heavily
  existing and emerging Web Service Security
  Specification, build in particular on the
  framework described in the Web Service Security
  Architecture.
• The Web Service Specification will serve as
  building blocks for the OGSA security
  Specification.

8
Grid Security Service
9
OGSA Security Specification
Proposed Specification
Naming Translating between Security
Realms Authentication Mechanism
Agnostic Pluggable Session Security Pluggable
Authorization Service Authorization Policy
Management Trust Policy Management
Privacy Policy Management VO Policy
Management Delegation Firewall "Friendly" Security
Policy Expression and Exchange Secure Service
Operation Audit and Secure Logging
10
The Security Architecture for Open Grid Service
Abstract
It defines a comprehensive Grid security
architecture that supports, integrates and
unifies popular security models, mechanisms,
protocols, platforms and technologies in a way
that enables a variety of systems to interoperate
securely. This security architecture is intended
to be consistent with the security model that is
currently being defined for the Web services
framework used to realize OGSAs service-oriented
architecture. The document presents a security
model, describes a set of security components
that need to be realized in the OGSA security
architecture, and presents a set of use patterns
that show how these components can be used
together in a secure Grid environment.
11
Security Challenges in a Grid Environment

• The Integration Challenge
• The Interoperability Challenge
• The Trust Relationship Challenge

12
Categories of security challenges in a Grid
environment
(a) integration solutions where existing services
needs to be used, and interfaces should be
abstracted to provide an extensible
architecture (b) interoperability solutions so
that services hosted in different virtual
organizations that have different security
mechanisms and policies will be able to invoke
each other and (c) solutions to define, manage
and enforce trust policies within a dynamic Grid
environment.
13
Categories of security challenges in a Grid
environment
Integrate Extensible architecture Using existing
services Implementation agnostic
Interoperate Secure interoperability Protocol
mapping Publishing QoP Federation
Trust Trust relationships Trust
establishment Presumed trust Assertions
14
Grid Security Requirements

• Authentication.
• Delegation.
• Single Logon.
• Credential Lifespan and Renewal.
• Authorization.
• Privacy.
• Confidentiality.

• Message integrity.
• Policy exchange.
• Security logging.
• Assurance.
• Manageability.
• Firewall Traversal
• Securing the OGSA infrastructure.

15
Grid Security Model Principles

• Security Invocation of Grid ServicesGrid service
  security requirements highlight the need for
  establishing standard mechanisms for conveying
  and enforcing the quality of protection, security
  attributes and access policies associated with
  services and requesters.
• Grid Security ServicesThe suite of security
  services and the primitives, which are required
  as building blocks, provide a rich set of
  services to application logic hosted in an OGSA
  environment.

16
Grid Security Model
17
Grid Security Model and WS security
18
Security as Services
Including

• An authentication service
• Identity mapping service
• Authorization service
• VO Policy service
• Credential Conversion service
• Audit Service
• Profile Service
• Privacy Service

19
Referrence
1 Grid Service Specification Open Grid Service
Infrastructure (OGSI) 2 Concepts and
Technologies for a Worldwide Grid
Infrastructure 3 The Anatomy of the Grid
Enabling Scalable Virtual Organizations. 4 The
Physiology of the Grid An Open Grid Services
Architecture for Distributed Systems
Integration. 5 The Security Architecture for
Open Grid Services 6 OGSA Security Roadmap
20
Security requirements

• Before we dive into the 10 most critical factors
  determining security requirements, lets briefly
  discuss Web services security requirements. The
  key Web services security requirements are
  authentication, authorization, data protection,
  and nonrepudiation.

21
Web Services Security

• Yang Ning

22
Authorization

• Authorization determines whether the service
  provider has granted access to the Web service to
  the requestor. Basically, authorization confirms
  the service requestors credentials. It
  determines if the service requestor is entitled
  to perform the operation, which can range from
  invoking the Web service to executing a certain
  part of its functionality.

23
Authentication

• Authorization determines whether the service
  provider has granted access to the Web service to
  the requestor. Basically, authorization confirms
  the service requestors credentials. It
  determines if the service requestor is entitled
  to perform the operation, which can range from
  invoking the Web service to executing a certain
  part of its functionality.

24
Data Protection

• Data protection ensures that the Web
  servicerequest and response have not been
  tampered with en route. It requires securing both
  data integrity and privacy. Its worth mentioning
  that data protection does not guarantee the
  message senders identity.

25
Nonrepudiation

• Nonrepudiation guarantees that the message
  sender is the same as the creator of the message.
  Now that we have an idea of what constitutes Web
  service security, well examine the top ten
  security factors affecting Web service
  implementation.

26
Top 10 Web service security requirements

• 1. Is the Web service being used for EAI or B2Bi?
• 2. What's the purpose of the Web service?
• 3. Who are the subscribers of the Web service?
• 4. Can the service be invoked over the Internet?
• 5. How secure is the underlying application?

• 6. Is the Web service transaction-oriented?
• 7. What protocol is utilized?
• 8. Is there a need to verify sender/recipients?
• 9. Who is involved in the service?
• 10. Is component chaining used?26

27
1. Is the Web service being used for EAI or B2Bi?

• Web services can be used for two distinct
  domainsenterprise application integration (EAI)
  and business-to-business integration (B2Bi).

28
2. What's the purpose of the Web service?

• If the Web service exposes just public
  information-oriented business process or data,
  such as todays weather in a city or a stock
  quote for a company, the security requirements
  are looser than those for a Web service that
  exposes private business information.

29
3. Who are the subscribers of the Web service?

• Knowing who a Web services subscribers are is
  important for determining the authorization and
  authentication features of the Web service.

30
4. Can the service be invoked over the Internet?

• Is the Web service restricted to trusted trading
  partners, or can any company invoke the Web
  service over the Internet? This is critical to
  the authorization and authentication features of
  the Web service, apart from data protection and
  nonrepudiation features.

31
5. How secure is the underlying application?

• What level of access does the Web service
  provide to the underlying application? Should the
  access be based on authorization and
  entitlements? The greater the access to
  underlying applications, the greater the
  authorization and authentication security
  requirements.

32
6. Is the Web service transaction-oriented?

• The security threats will be higher if the
  transaction is distributed across multiple
  entities.

33
7. What protocol is utilized?

• What network protocol handles the authentication
  and data transmission between the service
  requestor and provider? Its important to know if
  theres a need for data security since anyone can
  sniff the Web service request and response, which
  would be carried over the network as plain XML
  documents. If it is HTTPS, then there is no need
  for any additional encryption/decryption
  algorithms since HTTPS provides it.

34
8. Is there a need to verify sender/recipients?

• Is there a need to guarantee that the sender of
  the Web service request and response message is
  the same as the creator of the message? This
  information might be needed for auditing purposes
  and ensuring that the sender and creator are the
  same entity. Nonrepudiation security requirements
  will typically be needed if the Web service is
  being used for B2Bi.

35
9. Who is involved in the service?

• How many distinct entities are involved in the
  usage of the Web service i.e., does the Web
  service have an entity-chaining feature? If there
  is more than one entity, it will require higher
  security features.

36
10. Is component chaining used?

• Is there an application- and component-chaining
  feature in the implementation code of the Web
  service? If the application chaining spans the
  corporate firewall, the security requirements
  become stingier.

37
XML security
38
XML ????

• XML??(Xenc)
• XML??(XML-SIG)
• XML??????(XKMS)
• XML????????(XACML)
• ????????(SAML)
• ?????????(XrML)

39
XML??(Xenc)

• XML??(Xenc)?????XML???????????,W3C?IETF???????????
  ?XML??????????????????,????????????????????,??????
  ??????????????????????????????,????????XML????????
  ??,????????????????

40
XML??(XML-SIG)

• XML???XML????????????????,XML??????XML????????????
  ????????????????????,XML????????(canonicalization
  )?????XML??????XML????????????

41
XML??????(XKMS)

• XKMS?W3C?????????????????XML????????????????XKMS??
  ????XML????????(X-KRSS)?XML????????(X-KISS)?X-KRS
  S??????????,?X-KISS???XML??????????

42
XML????????(XACML)

• XACML?OASIS????????????(??IBM?????)????????????SAM
  L(??????)????,?????????XML????????????XACML???????
  ????????????,????????????,????,???????????

43
????????(SAML)

• SAML????OASIS,?XACML??,?????/?????/????????SAML???
  HTTP????SOAP??????????????????

44
?????????(XrML)

• ????????????? XrML ???????????????????????????????
  ????XrML???????????????????,??????????????????????
  ????????????

45
???????????????Akenti

• Supported by the U.S. Dept. Of Energy
• Information and Computing Sciences Division
• Ernest Orlando Lawrence Berkeley National
  Laboratory, University of California

46
Motivation

• ?????????????(Distributed computing environments,
  collaborative research environments)
• ????????????????(Resources, stakeholders and
  users are all distributed)
• ????????(Spanning organizational as well as
  geographical boundaries, e.g., DOE
  Collaboratories)
• ?????????????(Requires a flexible but secure way
  to identify users)
• ??????????????????????(Requires a flexible and
  secure way for stakeholders to remotely specify
  access control for their resources)

47
Goals

• ???????????????(Access based on policy statements
  made by stakeholders)
• ????????????????????(Handle multiple independent
  stakeholders for a single resource)
• ??????????????,??????????(Use Public Key
  Infrastructure standards to identify users and
  create digitally signed certificates)
• ?????(Emphasize usability )

48
Required Infrastructure

• Certificate Authority to issue identity
  certificates (required)
• SSLeay provides simple CA for testing
• Netscape CA - moderate cost and effort
• Enterprise solutions - Entrust, Verisign,
• Method to check for revocation of identity
  certificates (required)
• LDAP server - free from Univ. of Mich.. Or comes
  with Netscape CA
• Certificate Revocation lists - supported by most
  CAs
• Network accessible ways for stakeholders to store
  their certificates (optional)
• Web servers
• MSQL web accessible data bases

49
????????

• Use-condition certificates,????????????,??????????
  ??????
• ?????????????????????????
• ??????????????
• ????????????????CA
• use-condition??????
• Attribute certificates,????????????????,??????????
  ?
• ???????????????????(??)????CA
• Attribute certificate???????CA
• Attribute certificate???????
• ????(X.509),????????,?CA?????
• Policy file ????????????????????????(???????),????
  ????????,??use-condition?Attribute?

50
Common Societal Access Control Model
51

AKENTI ??
Cache Manager
Fetch Certificate
DN
Resource Server
Client
Akenti
DN
DN
Identity (X509) certificate on behalf of the user.
Log Server
Internet

Use condition or attribute certificates
LDAP
File Servers
Database Server
Web Server
DN
Identity certificates
Certificate Servers
52

AKENTI ????
Stakeholders
S3
S4
S1
S2
Certificate Generator
C4(S4)
C1(S1)
C2(S2)
C3(S3)

Certificate Servers
Akenti
Hash Generator
Search based on resource name, user DN, and
attribute
53
???????
54
???????
55
????
56
From Li Dongdong Begin
57
(No Transcript)
58
(No Transcript)
59
Akenti ????

• ??????????????,????????
• ??????????????????
• ???????????
• ????

60
Akenti ????
61
Akenti ????
62
Akenti ????
63
Akenti ????
64
Akenti ??
65
Akenti ??
66
Akenti ??
67
Akenti API

• C auth_chk_access
• User DN
• Resource Name
• Akenti Configuration File
• Command line

68
Related Work

• Ellison, et.al. SPKI - authorization certificates
• Nekander Partanen (HUT) SPKI style certificates
  for access permissions on Java code. To replace
  per/machine Java policy files.
• Blaze,Feigenbaum Policy Maker and KeyNote based
  on authorization certificates written in a
  specified executable language.
• Foster, Kesselman Globus Use of X.509 identity
  certificates to authenticate users.

From Li Dongdong End
69
?????
70
????????
71
????
72
??

• ????????????????
• ???????????????????????,??????????????

73
??

• Akenti policy engine 80 ?????????
• 8 - 9 ????
• If a capability certificate is found for the user
  and the resource is about 0.1 seconds (to find
  and verify the certificate)
• ????????????????????

74
Status

• Akenti enabled Apache Web servers deployed at
  LBNL and Sandia.
• Controlling Akenti code distribution, secure
  data/image repository, ORNL electronic notebooks
• We have given code to CONDOR, Univ. of Wisc.,
  WebFlow at Syracuse Univ., NIST, and ISI/USC
• Servers run on Solaris, but client code runs on
  Linux as well
• Java interface to Akenti policy engine exists and
  is used by the Anchor agent code.

75
Future Directions

• Implement Akenti as a standalone server
• Expand Use Conditions to include dynamic
  variables such as time-of-day, originating IP
  address, state variables.
• Change syntax of certificates, probably to XML.
  We already have a Matchmaker want-ad style in
  addition to our original key-word/value syntax.
• Add delegation - probably in the form of
  authorization certificates
• Integrate with additional applications
• Network bandwidth Quality of service,
• Secure Mobile agents,
• Group key agreement protocol.

76
Conclusions

• As enterprises deploy PKI, identifying users by
  their identity certificates will become natural
  and transparent.
• Currently there are several competing standards
• browsers, Netscape and Explorer
• Entrust - own client interface
• Akenti/SSL overhead acceptable for medium grained
  access checking. E.g , starting an operation,
  making a authenticated connection.
• Ease of use for stakeholders must be emphasized.

77
Community Authorization Service (CAS) Overview

• YOU Ganmei

78
A Quick Refresher

• Grid Security Infrastructure (GSI)
• X.509 (PKI certificate format)
• proxy certificates (single sign-on
  delegation)
• TLS/SSL (authentication msg protection)
• delegation protocol (remote delegation)
• Existing IETF standards
• Others are GGF IETF drafts

79
X.509 Proxy Certificates

• A proxy certificate is used by an entity to
  delegate all or part of its own authority.
• A proxy certificate is a special type of X.509
  certificate that is signed by a normal end entity
  cert (or by another proxy).
• A proxy certificate grants the bearer (whoever
  knows the private key) some or all of the issuing
  entitys authority.

80
Unrestricted Proxies

• An unrestricted proxy certificate delegates all
  of the issuers authority.
• Supports single sign-on delegation through
  impersonation
• Relying parties grant the same rights to an
  unrestricted proxy certificate that they would to
  the entity that issued the proxy (subject to any
  additional local policy)
• grid-proxy-init creates an unrestricted proxy
  certificate
• This is what is in current (2.0) Globus software.

81
Restricted Proxies

• A restricted proxy delegates a subset of the
  issuers authority.
• A restricted proxy cert contains a policy
  statement limiting what that cert can be used
  for.
• Relying parties authorize requests only if the
  request would have been granted for the proxys
  issuer, and the request is consistent with the
  policy embedded in the cert, and any additional
  local policy requirements are met.
• Thus, a restricted proxy grants (at most) the
  intersection of the issuers rights as granted by
  the local policy and the rights granted by the
  proxys embedded policy.

82

• problem in distributed communities of resource
  providers and resource consumers, complex and
  dynamic policies govern who can use which
  resources for which purpose.
• challenges
• 1) scalability cost of administrating a VO
  ??? VO???,???VO??????????
• 2)flexibility and expressibility
  ??????????????????????????????
• 3)policy hierarchy ????????VOs,??????????,???
  ?????????

83

• solution ????????????????????????,???????????????
  ?
• ????CAS

84
Community Authorization Service

• CAS???public key authentication ? GSI delegation
  machanisms(SSO,delegation,credential mapping).
• CAS server????????????
• ??CAs,users,servers, resources(???????????),?
  ?(????)?

85

• In the CAS model, resource providers grant access
  to blocks of resources to a community as a whole,
  and the community uses a CAS server to perform
  fine-grained access control on those resources.
• Resource providers grant course-grained access to
  communities.
• Communities run CAS servers, which keep track of
  fine-grained access control information and grant
  restricted proxies to community members.
• The result is that a CAS user gets the
  intersection of the rights granted by resource
  provider to the community and the rights granted
  by the community to that user.

86
A Typical CAS Request

• CAS request, authenticated with

CAS Server




CAS-maintained community policy database
User credential
What rights does the community grant to this
user?

• CAS reply, including
• restricted proxy cred

Community subject name
Policy restrictions

User

Resource Server

3. Resource request, authenticated with CAS proxy

Is this request authorized for the community?
Local policy information

Community subject name

Policy restrictions


4. Resource reply

Do the proxy restrictions authorize this request?

87
Features
Scalability CxP changed to CP (consumer /
producer known ,trusted by CAS server )
CAS server can be run by administrator Already
familiar with the community and Its policy. Can
add new resources and users without involving the
other.
CAS Server
Users
Resource Server
Users only have to interact With the CAS to gain
community Membership, changes rights, etc.
Resource providers can see community as a single
entity. Can set policy on group as a whole. Dont
have to be Involved in day-to-day administration
of community policy.
88

• Flexibility and expressibility allowing
  producer-community agreements and community
  policies to be expressed directly within the CAS
  server.
• Specialized policy server externalizing policy
  enforcement into a third party server,
  representing sub-communities within a VO or
  completely different VOs.

89
Steps to CAS Deployment

• A community representative acquires an identity
  certificate representing that community, and runs
  a CAS server under that identity.
• The community representative and resource
  provider negotiate terms such as acceptable usage
  policies (AUPs).
• The resource provider runs resource servers that
  understand restricted proxy credentials.

90
Steps to CAS Deployment (cont)

• Community users need client programs to interface
  with the CAS server
• Applications can be modified to interface
  directly with the CAS or can be use unmodified
• Can be wrapped with a simple script that gets CAS
  credentials and then runs program

91
CAS Policy Management the Resource Providers
View

• The resource provider grants access to a block of
  resources to the community, using their existing
  access-control mechanism for that resource(e.g.,
  grid-mapfile entries, file permissions, Akenti,
  etc.).
• The resource provider uses normal local
  mechanisms (e.g. quotas) to set policy for the
  community as a whole.
• The resource provider can grant access to
  different resources to CAS servers representing
  different communities.
• The resource provider then installs servers
  modified to enforce the policy in the CAS
  restricted proxies.

92
CAS Policy Management the Communitys View

• CAS administrative requests are used to maintain
  the CAS community policy database, which
• controls what rights the CAS server will grant to
  which users.
• controls the CAS servers own access control
  policies, and thus can be used to delegate the
  ability to grant rights, maintain groups, etc.
• maintains the list of community members

93
Policy Language

• Restricted proxies can use any policy language
  (the format consists of an identifying OID and an
  opaque policy field).
• We currently use a very simple policy language
• Resource (e.g. host and filename)
• Positive rights (e.g. read, write, create)
• Can specify subtrees (/home/user/)
• Policy language need only be understood by CAS
  and end resources
• Opaque to users and protocol
• Allows for more advanced languages
• Need deployment and feedback to understand what
  is needed in more advanced language.

94

• Implementation three extensions to GSI mechamism
• restricted proxy credential that allow for
  fine-grained control of delegated rights
• policy language that specifying the rights
  carried in the restricted proxy credentials
• libraries and APIs to facilitate the delegation
  of restricted proxies by CAS server and the
  enforcement of proxy restrictions by resource
  providers.
•  

95
Relationship to Akenti

• Akenti and CAS are complementary technologies
  Akenti can be used as the local policy
  mechanism in the CAS model
• Akenti implements local policy on resources,
  making sure all the stakeholders policies are
  complied with. Akenti stakeholders grant access
  to some set of resources to a community.
• The communitys CAS server provides finer-grained
  authorization within the community.

96
Status and Future Work

• CAS demo at HPDC-10
• Demod using simple ftp servers and clients
• CAS demo at Supercomputing01
• Integrated with ESG Visual Climat Data Analysys
  Tool
• CAS prototype release in early 02
• For latest information see http//www.globus.org/
  security/CAS/

97
GAA-API??

• ???
• 2002-12-17

98
Content

• Grid Security Requirement
• GAA-API Overview
• Conditions
• Three-Phase Policy Enforcement
• Extended Access Control List(EACL)
• Generic Authorization and Access-control
  API(GAA-API)
• The Policy Enforcement Process
• Conclusions

99
Grid Security Requirment

• User authentication. Authenticated user identity
  is used to determine who gains access to local
  resources.
• Resource usage limits (quotas). A site-specific
  resource allocation policy specifies limits on
  the computational or storage resources to be
  consumed, such as CPU load, memory usage and disk
  space. The limits are taken into account when
  deciding whether to initiate the requested
  computation. Monitoring execution of the
  computation on a particular node must be
  supported to ensure that the process keeps
  strictly to the limits imposed by the local
  policy.
• Accounting and payment. Owners of the resources
  may hold users accountable for the consumed
  resources. Accounting may include gathering
  information about executed computations and
  consumed resources. The accounting information
  can be used in payment models for remote service
  providers.
• Audit. Audit can provide a means to help
  accomplish individual accountability and provide
  data to be analyzed by intrusion or misuse
  detection systems.
• Intrusion and misuse detection. Grids are
  vulnerable to a large-scale malicious attacks
  that could cause disruption of the Grid services.
  Thus, it is essential for Grids to support
  detection and automatic response to intrusion
  attempts.
• Event notification. Tools for intrusion
  detection and fault tolerance can be driven by
  event services. Alert-level notification messages
  permit cooperative responses. For example,
  notification about a computation that exceeds the
  quotas can signal ongoing denial of service
  attack. The adequate preventive measures can be
  taken if the attack is confirmed.

100
Using the GAA API in PRM
The System Manager (SM) - allocates
resources to jobs
GAA API
EACL
5a
5
gaa_get_object_eacl
SM
6
. . .
1
4
gaa_check_authorization
6b
Transport Mechanism
6a
4a
GAA API security context
2
3
Kerberos Library
(1, 2, 3, 4, 4a) request and verification of
principals identity (5, 5a) call to
gaa_get_object_eacl, retrieval of appropriate
EACL (6, 6a, 6b) call to gaa_check_authorization
101
An Example
ACL
GAA API
5a
5
gaa_get_object_acl
. . .
Application
6
6b
1
4
gaa_check_authorization
7
Security API, e.g. GSS API
4a
6a
GAA API security context
2
3
Security Server
(1, 2, 3, 4, 4a) request and verification of
principals identity (5, 5a) call to the
gaa_get_object_acl, retrieval of appropriate
ACL (6, 6a, 6b) call to the gaa_check_authorizatio
n (7) GAA API answer
102
GAA-API Overview
103
Conditions

• access identity This condition specifies an
  authenticated access identity. If a policy does
  not require authenticated user identity,
  authentication steps can be ignored or deferred
  until the policy explicitly requests it. An
  example of a policy, which is not concerned with
  the identity is "anyone can read file A if 10 is
  paid".
• strength of authentication This condition
  specifies the authentication mechanism or set of
  suitable mechanisms for authentication. Strong
  user authentication method (e.g., Kerberos) can
  be activated in response to suspicious behavior.
• time This condition specifies time periods for
  which access is granted.
• location This condition specifies location of the
  user. Authorization is granted to the users
  residing on specific hosts, domains, or networks.
  
• payment This condition specifies a currency and
  an amount that must be paid prior to accessing an
  object.
• quota This condition specifies a currency and a
  limit. It limits the quantity of a resource that
  can be consumed or obtained.
• audit This condition enables automatic generation
  of audit data in response to access requests. An
  audit record should include sufficient
  information to establish what event occurred and
  what caused the event.
• notification This condition enables automatic
  generation of notification messages (alerts) in
  response to access requests. Specifies the
  receiver and the notification method.
• threshold This condition specifies allowable
  threshold.
• system threat level This condition specifies the
  system threat level.
• Note that in the implementation, some of these
  conditions might have side effects.

104
Read and Write Conditions

• At the conceptual level, all conditions can be
  categorized as
• Conditions that require reading some system
  variable and comparing it with the information
  specified in the policy. For example, evaluation
  of the time condition requires obtaining current
  time and checking if it fits into the time
  interval specified in the policy. We call this
  category of conditions read conditions. A read
  condition is represented as XopP, where X is the
  name of a system variable, P is a constant and op
  is the operation (e.g., , ? , lt , gt) to be
  performed on the value of the system variable X
  and the constant P. In implementation, this value
  maybe either obtained from the request or read
  using the s.Read(X) operation during the
  condition evaluation.
• Conditions that require writing some information
  (e.g., audit) or initiating some action (e.g.,
  notification). We call this category of
  conditions write conditions. A write condition is
  represented as Xnew_value, where X is the name of
  the system variable and new_value is the new
  value to be assigned.

105
Pre-, Mid-, Post- and Request-result Conditions

• An authorization policy may specify conditions
  that must be satisfied before, during or after
  the access right is exercised. Furthermore,
  evaluation of some conditions must be activated
  only if the authorization request is granted (or
  denied).
• Thus, all conditions are classified as
• pre-conditions specify what must be true in order
  to grant the request. This means that the
  requested operation is allowed to be executed on
  the target object. If any of the pre-conditions
  fails, authorization is denied.
• request-result conditions These conditions must
  be activated whether the authorization request is
  granted or whether the request is denied.
• mid-conditions specify what must be true during
  the execution of the requested operation. The
  mid-conditions can be used for the protection of
  the critical operations and resources.
• post-conditions specify what must be true on the
  completion of the operation execution.

106
The Three-Phase Policy Enforcement

• The enforcement of the advanced security policies
  is partitioned into three successive phases.
• Phase one access control. The pre- and
  request-result conditions are evaluated during
  this phase and the decision to grant or deny
  access to the requested object is made.
• Phase two execution control. The access to the
  target object is granted, the requested operation
  is started and the mid-conditions are evaluated
  during this phase. This phase allows the
  controlled execution of the requested operation.
• Phase three post-execution actions. The
  post-conditions are evaluated during this phase.
  The specified actions are performed after the
  operation is finished. We do not call this phase
  post-execution control'', since neither failure
  nor success of a post-execution action can affect
  either access decision, or operation execution.

107
Extended Access Control List (EACL)

• The EACL is a simple policy language designed to
  describe user-level authorization policy. An EACL
  is associated with an object (or a group of
  objects) to be protected and specifies positive
  and negative access rights with optional set of
  associated conditions.
• A condition block defines a conjunction of a
  totally ordered set of conditions. Conditions are
  evaluated in the order they appear within a
  condition block.
• An EACL entry consists of a positive or negative
  access right and four condition blocks a set of
  pre-conditions, a set of request-result
  conditions, a set of mid-conditions and a set of
  post-conditions. Note that a condition block can
  be empty. If all condition blocks in an EACL
  entry are empty, the right is granted
  unconditionally. An example of a practical policy
  with empty condition blocks is anyone can read
  file index.html''.
• An EACL consists of an ordered set of disjunctive
  EACL entries. An EACL representation supports
  disjunction and conjunction of conditions to
  activate different control modes.
• An EACL is equivalent to disjunctive normal form
  consisting of a disjunction of conjunctions where
  no conjunction contains a disjunction. For
  example, a policy Tom or Joe can read file A
  only if they connect from .isi.edu domain'' can
  be represented by an EACL (attached to the file
  A) with two EACL entries positive access
  right read, pre-conditions Tom, .isi.edu''
  positive access right read, pre-conditions
  Joe, .isi.edu''.

108
Generic Authorization and Access-control
API(GAA-API)

• The main GAA-API functions
• gaa_get_object_policy_info is called to to obtain
  the security policy associated with the object.
  It takes the target object and authorization
  database as input and returns an ordered list of
  EACLs. How the policies are stored and retrieved
  is opaque to the GAA-API and is not reflected in
  the EACL.
• gaa_check_authorization checks whether the
  requested right is authorized under the specified
  policy. This function takes the retrieved policy
  (an ordered list of EACLs), requested access
  right and contextual information as input.
• gaa_execution_control performs policy enforcement
  during operation execution. This function checks
  whether the mid-conditions associated with the
  granted access right are met.
• gaa_post_execution_actions performs policy
  enforcement after the operation completes. This
  function enforces the post-conditions associated
  with the granted access.

109
The Policy Enforcement Process

• The GAA-API returns three status values to
  describe policy enforcement process
• authorization status Sa. Indicates whether the
  request is authorized (T), not authorized (F) or
  uncertain (U).
• mid-condition enforcement status Sm. Indicates
  the evaluation status of the mid-conditions
  (T/F/U).
• post-condition enforcement status Sp. Indicates
  the evaluation status of the post-conditions
  (T/F/U).

110
The Policy Enforcement Process (2)

• Initially the status values are set to U.
• The access control phase starts with receiving a
  request to access an object, requested type of
  access and contextual information.
• First, the gaa_get_object_policy_info function is
  called to obtain the security policy associated
  with the object. If no relevant policy was found,
  the authorization status is set to F and the
  request is rejected. Next the gaa_check_authorizat
  ion function is called to evaluate pre- and
  request-result conditions. If there are no
  pre-conditions (this means that the requested
  right is granted unconditionally), the
  authorization status is set to T. Otherwise, the
  pre-conditions are evaluated and the result is
  stored in the authorization status Sa.
• If the request-result conditions are present in
  the policy, the conditions are evaluated and the
  intermediate result is stored in variable X. The
  conjunction of the X and Sa is stored in the
  authorization status Sa. If authorization is not
  granted (Sa ? T), the request is rejected.
• The execution control phase consists of starting
  the operation execution process and calling the
  gaa_execution_control function. If mid-conditions
  are found, the conditions are evaluated. Some
  mid-conditions are evaluated just once, other
  mid-conditions are evaluated in a loop until
  either the operation finishes or any of the
  mid-conditions fails. In the latter case, the
  operation execution is suspended and the reactive
  actions are started. The mid-conditions can be
  returned unevaluated to be enforced by
  application. The result is stored in Sm.
• During the post-execution action phase the
  gaa_post_execution_actions function is called.
  The operation execution status (indicating
  whether the operation succeeded/failed) is passed
  to the gaa_post_execution_actions. If no
  post-conditions are found, the Sp is set to T,
  otherwise the post-conditions are evaluated and
  the result is stored in Sp.

111
Conclusions

• Traditional authorization mechanisms check
  whether a user is acting within prescribed
  parameters and will not detect abuse of
  privileges. Advanced policies can conditionally
  generate audit records and in limited ways can
  react to state generated by intrusion detection
  engines based on observation of the audit
  records. Such policies can also adapt the level
  of detail of the audit records generated until an
  intrusion detection engine notices that something
  is amiss, though not necessarily what it is. Such
  policies can also adapt the applied
  authentication policies to require more
  information from a user when suspicious activity
  has been detected.
• There are some aspects of distributed policy
  evaluation and enforcement that do not fit well
  within the framework. In the current framework we
  assume that conditions are evaluated
  consecutively and that authorization requests do
  not overlap. These two assumptions enable us to
  concentrate on a single condition evaluation at a
  time and, therefore, avoid the problem of
  coordination of multiple condition evaluation
  processes.
• This results in inefficient policy evaluation
  process and leads to systems that cannot scale to
  large numbers of objects. Our current approach
  may be appropriate for some client-server
  applications, where the server is an autonomous
  agent, in complete charge of its resources. The
  server maintains the security policy and is
  responsible for the policy evaluation. Some
  distribution of the policy evaluation process can
  be achieved through the condition evaluation
  function implemented as, for example, an RPC call
  that is performed synchronously. However, this
  approach is not suitable for truly distributed
  architectures where a set of servers implement
  the policy and the policy evaluation processing
  can be distributed over several servers. Each
  server is responsible for enforcing of a part of
  the whole access control policy.

112
Thank you!