Authorization BOF Handout


The following information is meant as an overview and primer on currently available authorization technologies. There is no claim that this is an exhaustive list nor is there an meaning associated with the order in which mechanisms and frameworks are presented.

This handout is available online at http://java.cs.vt.edu/public/users/mlorch/Grid-AuthZ/BOF+Handout


The Security Assertion Markup Language (SAML)


SAML [SAML] defines a language and protocol to exchange authentication and authorization information. Its primary goal is to provide a mechanism by which permissions management data can be shared in a standardized fashion across domains and across a variety of systems and thus provide for interoperability. Among other scenarios, this enables single sign-on functionality for distributed systems. Its prime focus are web services. A standard XML message format for SAML requests, assertions and responses is provided

SAML assertions may be used within a proprietary request/response protocol. The XML Signature Specification [SIG] is suggested as an XML compliant syntax for signing SAML messages and assertions. Other mechanisms, such as secured channels (e.g. TLS) may be used instead of XML Signature to provide for message integrity, authentication of message issuer and message origin and for non-repudiation.

[SAML]
OASIS XML-Based Security Services TC (SSTC), Security Assertion Markup Language
http://www.oasis-open.org/committees/security/#documents, visited 2002-09-11

[SIG]
XML Signature Syntax and Processing, W3C Proposed Recommendation.
http://www.w3.org/TR/xmldsig-core/, visited 2002-09-11


OASIS eXtensible Access Control Markup Language (XACML)


XACML is an XML specification under development for expressing policies for information access over the internet. It "is expected to address fine grained control of authorized activities, the effect of characteristics of the access requestor, the protocol over which the request is made, authorization based on classes of activities, and content introspection... XACML is also expected to suggest a policy authorization model to guide implementers of the authorization
mechanism." [XACML]

[XACML] http://www.oasis-open.org/committees/xacml/


WS-Authorization


According to [WSARCH], a follow-on specification to WS-Security [WSSEC] named WS-Authorization "will describe how to manage authorization data and authorization policies" for Web Services. It "will describe how access policies for a Web service are specified and managed. In particular it will describe how claims may be specified within security tokens and how these claims will be interpreted at the endpoint."

[WSARCH]
Security in a Web Services World: A Proposed Architecture and Roadmap
http://msdn.microsoft.com/library/en-us/dnwssecur/html/securitywhitepaper.asp
Version 1.0
April 7, 2002

[WSSEC]
Web Services Security (WS-Security)
WS-Security is the piece that specifies how to secure an idividaul SOAP message. It defines a new schema that builds on the SOAP schemas and digital signature schema to define security tokens and claims. It is designed to support more than one credential and currently supports encoding of X.509 and Kerberos tokens. Using this schema, you can send signed and/or encrypted messages end-to-end.
http://msdn.microsoft.com/library/en-us/dnglobspec/html/ws-security.asp
Version 1.0
April 5, 2002


Attribute Certificates and Privilege Management Infrastructure (PMI)


X.509 Attribute Certificates [RFC3281] are a means to bind arbitrary attributes (e.g. role membership information, policy statements, accounting information) to identities. The binding can be accomplished by specifying either a name (e.g. X.509 DN), a X.509 public key certificate issuer and serial number, or the public key of an entitiy as the "holder". The issuer of an attribute certificate (AC) is often refered to as the authoritative entitiy. The issuer signs the AC digitally, thus ACs are self contained and do not need to be protected or stored in secured/trusted directories. ACs can be used to build a privilege management infrastructure (PMI). Issuer chains build a hierarchy similar to that in a public key infrastructure (PKI), with the root being called the source of authority (SOA).
Delegation of ACs is currently not being addresses in the RFC but are possible using extentions that specify delegation rules. ACs have been deployed succesfully in systems that implement discretionary access control (DAC) as well as role based access control (RBAC) mechanisms.

Terms X.509 Privilege Management Infrastructure:
  • Source of Authority (SOA) = The topmost root of trust, sometimes also referred to as trust anchor
  • Attribute Authority (AA) (also Privilege Allocator, Authoritative Entity) = The issuer of an attribute certificate
  • Certificate Holder / Privilege Holder = The User or Subject of an Attribute Certificate

[RFC3281] An Internet Attribute Certificate Profile for Authorization
http://www.ietf.org/rfc/rfc3281.txt


PRIMA - Privilege Management and Authorization Services


PRIMA [1] is a privilege management system that employs X.509 attribute certificates to bind rights to users (or their surrogates). Users and administrators alike can manage and delegate privileges directly through the creation and exchange of attribute certifiates. Delegated privileges can be combined and applied selectively to a specific request providing for least privilege access. This enables ad-hoc collaborative groups to exist without the need for a centralized management.
Fine grain privileges are enforced on the resources through commonly available POSIX 1E file system access control lists. This provides for fast and reliable access control that fully supports legacy applications and services.
PRIMA user tools for privilege managment and a proprietary resource gatekeeper are currently implemented in Java. A C implementation that can interoperate with the Grid Security Infrastructure and the Globus gatekeeper as well as a dynamic user account management system that mitigates the requirement for user accounts on every resource are under development and will be released shortly [2].

[1] M. Lorch, D. Kafura, "Supporting Secure Ad-hoc User Collaboration in Grid Environments", accepted for publication at the 3rd Int. Workshop on Grid Computing, Baltimore, Nov. 18th, 2002 http://zuni.cs.vt.edu/publications/grid-security-V6-submission.pdf

[2] http://zuni.cs.vt.edu/grid-security


EU DataGrid Virtual Organisation and local Access Control


This consists of five components, three in production and two as advanced prototypes available from the EDG software repository:

An LDAP-based VO service, listing Distinguished Names of members of VO's and subgroups within VO's. These are filtered using standard LDAP client tools to produce local grid-mapfiles or other local sources of authorisation information. About a dozen VO's participating in the EU DataGrid Testbed are currently in production, with several hundred users in total. http://datagrid.in2p3.fr/cgi-bin/cvsweb.cgi/Auth/VO/

Pool account extensions to Globus gatekeeper and GridFTP server (and other service that use the Globus gss_assist library) This allocates an existing pool account to each new user of the site that connects via a Globus server. Local access control is then done in terms of standard Unix user and group permissions associated with the account when it was created. This complements the LDAP-based VO service which cannot easily know local Unix account names at each testbed site. http://www.gridpp.ac.uk/gridmapdir/

Local Centre Authorisation Service extension to Globus gatekeeper etc - a modular framework allowing authorisation decisions to be made on the basis of GSI proxy names as well as job description and available timeslots. http://datagrid.in2p3.fr/cgi-bin/cvsweb.cgi/fabric_mgt/edg-lcfg/

A prototype is available for a Virtual Organisaton Membership Service, which can be contacted with a GSI proxy to request additional signed credentials giving VO and group membership, and roles within them. A client tool allows these credentials to be included as extensions to GSI proxies, in such as way that VOMS-aware services can recognise them, but unmodified Globus services continue to work. http://cvs.infn.it/cgi-bin/cvsweb.cgi/Auth/voms/

Prototypes are also available of GACL, a library for parsing local access control lists in XML in terms of GSI DN, VOMS or CAS groups/roles or LDAP VO memberships. This is used by the EDG Storage Element (mass storage server), SlashGrid filesystem framework (to provide local disk storage controlled by grid credentials) and GridSite (which provides HTTPS file serving controlled by grid credentials.) http://www.gridpp.ac.uk/gacl/ and its links to SlashGrid and GridSite


PERMIS X.509 Based Privilege Management Infrastructure


PERMIS [PERMIS] is a privilege management infrastructure (PMI) that complies with the authorization framework defined in [RFC2904]. PERMIS uses a role based access control (RBAC) scheme that allows privileges to be associated with roles rather than with specific entities. Entities can then hold several roles. X.509 attribute certificates to securely bind and communicate role membership among the components of the infrastructure. Access requests are evaluated via an authentication, authorization and accounting (AAA) server which provides two main functionalities: an access control decision function (ADF) and an access control enforcement function (AEF) as defined in ISO/IEC 10181-3. The functions interact through a PERMIS Java API. LDAP repositories are employed for credential storage. A RBAC policy language based on XML has been developed for the PERMIS PMI.

[PERMIS] "The PERMIS X.509 Role Based Privilege Management Infrastructure" in proc. of the 7th ACM SYMPOSIUM ON ACCESS CONTROL MODELS AND TECHNOLOGIES (SACMAT 2002), June 2002.


RFC 2704 The KeyNote trust management system


RFC 2704 defines trust management as a unified approach to specifying and interpreting security policies, credentials, and relationships.
It defines a simple language consisting of "Fields" and values to express both authorizaton policy and credentials. The credentials and access rights are local to an application scope. The aplication provides a complience checker that understands the rights, resource and credentials.

http://www.ietf.org/rfc/rfc2704.txt?number=2704


RFC2904 - AAA Authorization Framework


In RFC2903-2906 an ?administrative domain" defines a set of users and/or resources that have a common administrative entity which defines access permissions.

RFC2904 focuses on three elements of an authorization framework:

  1. User Home Organization (UHO), which, based on a user agreement, can check if a user?s request for a service should be permitted
  2. a service provider AAA server, which (coarsely) authorizes access based on an agreement with the UHO, without knowing about the individual users
  3. the service equipment that provides services

For evaluation and enforcement of access policies RFC2904 introduces a Policy Decision Point (PDP) and a Policy Enforcement Point (PEP). A PDP makes access control decisions based on policies defined by parties authoritative for the PDP's administrative domain. The policies can either be stored in repositories or supplied through secure messages (such as attribute certificates) PDPs can be located at the UHO and the service provider's AAA server.
A PEP is the corresponding entity, typically located at the service equipment, that can enforce an access decision made by the PDP.

Two operational models for the PEP are outlined:
  • a PEP queries the corresponding PDP to make an access decision when it receives a request.
  • a PDP provisions a set of enforcement rules to the PEP before requests arrive.

Between authorization entities (UHO, service provider AAA server, service equipment, user) authorization tickets are exchanged. Such tickets can be implemented using attribute certificates (proposed in RFC2904).

RFC2904 - AAA Authorization Framework http://www.ietf.org/rfc/rfc2904.txt?number=2904


ISO 10181-3 Security Frameworks for open systems: Access control framework


In ISO 10181-3 [ISO 10181-3] similar components of an authorization framework are defined as follows:

PEP = Access Enforcement Function (AEF)
PDP = Access Decision Function (ADF)
Policy = Access Control Information (ACI)

[ISO 10181-3] ITU-T Rec X.812 (1995) | ISO/IEC 10181-3:1996 "Security
Frameworks for open systems: Access control framework"


Authorization API - Generic Application Interface for Authorization Frameworks


The Authorization API (aznAPI) defines a standardized API for the interface between AEF and ADF as defined in RFC2904.

[AZN-API] "Authorization API - Generic Application Interface for Authorization Frameworks", Open Group Technical Standard C908, http://www.opengroup.org/publications/catalog/c908.htm


GAA API - Generic Authorization and Access Control API


The IETF proposed standard Generic Authorization and Access control API (GAA API) (http://www.isi.edu/gost/info/gaa_api.html) is a definition of a simple interface between a resource gateway and an authorization module or server and a policy language in which stakeholders express their access requirements to the authorization server. The API consists basically of three calls: one to return the policy associated with a resource, one to take that policy as input, along with the principal's identity and the access required and return a yes, no or maybe answer, and one that takes the principal and the resource name and returns all the rights of that principal. The get-policy call lets the caller specify a pointer to the policy data base as well as to provide an upcall to return any dynamic policy. The maybe return of the check-authorization call, allows the gateway to do further checking based on data that only it knows. The policy language consists of an ordered list of three value tokens: type, defining authority and value. These tokens can express permissions, principals defined by various identifiers, e.g., X.509 or Kerberos, trust relationships, e.g., who can authorize a token, and conditions on permission such as time, location, message protection, quotas and subject attributes. The language can also express capabilities and can handle credential delegation. So far there has not been a lot of implementations of this interface, but Globus GIS has released something recently.
GAA provides an uniform interface that various gateway servers can call. It implies that there can be distributed and local policy information but managing this information is up to the implementation. The type and format of the policy information is left up to the implementation as well, as long as it can be translated into the GAA policy tokens. GAA allows for considerable interaction between the resource gateway and authorization server at time of attempted resource access.

[GAA-API] http://www.isi.edu/gost/info/gaaapi/

DCE

AFS, TransArc
The DCE security server is the commerical version of an authorization server derived from AFS. (http://www.transarc.com/Library/documentation/txseries/4.2/aix/en_US/html/atshak/atshak14.htm#HDRHC00812) It uses Kerberos ids to identify users and a database of ACL's for all the resources on a system to hold authorization policy. If a user is granted access the DCE server returns a ticket that will grant access to the resource. This is a centralized scheme where one server contains all the access policy about all the resources at a site. It is implicit that all the resource gateways trust the Security server and its policy database. It is possible to set up different DCE/Kerberos realms and establish trust relations between them. In this manner a principal defined in one realm can use resources controlled by another domain. Establishing cross-realm trust turns out to be hard in practice, as is the process of administering a DCE domain in the first place. The DCE solution seems to be a bit too centralized and intrusive to be the only type of authorization acceptable by the Grid, however, it could be used by individual sites if they are willing to accept a mapping from a Grid identity to a local DCE identity.

Akenti

LBNL.
Akenti is a distributed policy-based authorization system designed for use in collaboratory or Grid environments. e.g. resources, resource stakheholders, and users distributed over administrative domains. (http://www-itg.lbl.gov/Akenti/). It uses X.509 identity certificates to identify all the principals. Policy is stored as a set of XML certificates signed by the stakeholders and trusted attribute verifiers. Akenti provides considerable support to help stakeholders create and verify policy and for users to see what their access to a resource will be. Akenti currently provides a one simple access checking API: given a principal's identity and the name of the resource, it returns all the principal's permissions. The permissions may be completely evaluated, or man contain some additional run-time constraints, such as machine load or disk usage that will need to be evaluated by the resource gateway.

Legion

Univ of Virgina, NPACI, Avaki
In Legion, everything is represented as an object and objects communicate via method calls. Therefore, access is defined as the ability to call a method on an object. Access control is not centralized in any one part of the Legion system. Each object is responsible for enforcing its own access control policy (perhaps by interacting with other objects). The general model for access control is that each method call received at an object passes through a "MayI" layer before being serviced. MayI decides whether to grant access according to whatever policy it implements. If access is denied, the object will respond with an appropriate security exception, which the caller can handle any way it sees fit.
The principals in the allow and deny lists may specify particular users, the calling object's class, or the calling object itself. Users can also easily construct groups (as just another object), and define authorization policies based on these groups.

This is a bit similiar to the CORBA and Java security mechanisms where each method can make a callout for authorization before it starts to execute.

Community Authorization Server (CAS)

Globus, ANL, ISI-USC
The CAS is supporting a model of Grid usage where the users can be grouped into virtual organizations for the purpose of authorization. The assumption is that a resource provider will allow controled access to any member of a VO and then the VO can further constrain access to indvidual members of its own VO. The user wishing to use Grid resources, first goes to his VO's CAS server and gets a delegated X.509 proxy certificate that gives him the rights that the CAS Server thinks he shold have. He then uses that credential (via GSI) to request acces tothe resources. The Resouce provider checks that it has allowed this or greater permsisions to the VO, and then grants or denies the access.
http://www.globus.org/research/papers.html#CAS-2002

Shibboleth


Shibboleth, a project of Internet2/MACE, is developing architectures, policy structures, practical technologies, and an open source implementation to support inter-institutional sharing of web resources subject to access controls. In addition, Shibboleth will develop a policy framework that will allow inter-operation within the higher education community. Access control in Shibboleth is based on attribute assertions made by the user home organization, encoded in SAML.

http://middleware.internet2.edu/shibboleth/


Condor Authorization


Condor implements configurable access control on all protocol operations [1]. Operations are categorized as read, write, administrator, config (change Condor configuration), daemon (inter-daemon protocols), owner (of
the resource), and negotiator (trusted scheduler). Kerberos, GSI, NTSSPI, and Unix ident-style authentication are supported. Peers negotiate for an acceptable authentication mechanism in common. An identity map file can be used for Kerberos and GSI mechanisms. The authorization policy for each server/daemon is fully configurable (i.e., who can perform operations in each of the categories).

At a higher level, the authenticated owner of each job is included in the job's ClassAd [2] description, and resource access policies can refer to the job owner just as any other job attributes, using the ClassAd
language. ClassAd Matchmaking [3] is used by the scheduler to locate compatible machines for the job and by the resource manager to ensure the job has permission to access the machine. ClassAds have also been used by
others for specifying security policies (for example, in [4]).

[1] http://www.cs.wisc.edu/condor/manual/v6.4/3_7Security_In.html
http://www.cs.wisc.edu/condor/presentations/PC-2002/hbwang.ppt

[2] http://www.cs.wisc.edu/condor/classad/

[3] Rajesh Raman, Miron Livny, and Marvin Solomon, "Matchmaking: Distributed Resource Management for High Throughput Computing", Proceedings of the Seventh IEEE International Symposium on High Performance Distributed Computing, July 28-31, 1998, Chicago, IL.

[4] http://www.cs.uh.edu/~babu/poster.html

Cactus

(http://www.cactusCode.org) This is a problem solving enviroment in general in the high energy/ relativistic physics community. It is currently implented over Globus, so it uses GSI for security and authorization. They are currently working on Portal to launch Cactus programs that will implement a RBAC which divides users into groups with various roles that offer sets of capabilities or
permissions.

/public/users/mlorch/Grid-AuthZ/BOF Handout Login | Web Editor | Full Editor
Last modified 10/11/02 8:04 AM by mlorch (history)
Site contents