Distributed Capability Computing System (DCCS)

Donnelley, James E.

doi:10.17487/rfc0712

Cited by 11 publications

(4 citation statements)

References 6 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Revocable membranes (Donnelley 1976;Miller 2006;Rajunas 1989) allow one software component to share values that contain behavior or state with another component, but to later revoke access to those values when needed. Such membranes are useful for providing untrusted parties timelimited access to sensitive data, and they have been verified to enforce the appropriate security properties (Murray 2010).…”

Section: Revocable Membranesmentioning

confidence: 99%

Chaperones and impersonators

et al. 2012

View full text Add to dashboard Cite

Chaperones and impersonators provide run-time support for interposing on primitive operations such as function calls, array access and update, and structure field access and update. Unlike most interposition support, chaperones and impersonators are restricted so that they constrain the behavior of the interposing code to reasonable interposition, which in practice preserves the abstraction mechanisms and reasoning that programmers and compiler analyses rely on.Chaperones and impersonators are particularly useful for implementing contracts, and our implementation in Racket allows us to improve both the expressiveness and the performance of Racket's contract system. Specifically, contracts on mutable data can be enforced without changing the API to that data; contracts on large data structures can be checked lazily on only the accessed parts of the structure; contracts on objects and classes can be implemented with lower overhead; and contract wrappers can preserve object equality where appropriate. With this extension, gradual typing systems, such as Typed Racket, that rely on contracts for interoperation with untyped code can now pass mutable values safely between typed and untyped modules.

show abstract

Section: Revocable Membranesmentioning

confidence: 99%

Chaperones and impersonators

et al. 2012

View full text Add to dashboard Cite

show abstract

“…Initially, capabilities were used to limit access to hardware resources, such as memory pages [6]. Later, they were used to protect other resources, such as files, and used across the network [8]. More recently, people have noted that object references can be used as capabilities controlling access at the object level [27].…”

Section: Related Workmentioning

confidence: 99%

Solving the Transitive Access Problem for the Services Oriented Architecture

Karp

2010

2010 International Conference on Availability, Reliability and Security

View full text Add to dashboard Cite

A key goal of the Services Oriented Architecture is the composition of independently written and managed services. However, managing access to these services has proven to be a problem. A particularly difficult case involves a service that invokes another service to satisfy an initial request. In a number of cases, implementations are able to achieve either the desired functionality or the required security, but not both at the same time. We say that this service composition suffers from the transitive access problem. We show that the problem arises from a poor choice of access control mechanism, one that uses subject authentication to make access decisions, and that the problem does not occur if we use delegatable authorizations.

show abstract

“…KeyKOS [13] later implemented capabilities for general resources types on commodity hardware. Capabilities were later extended over the network [7]. ABAC is more general than capabilities.…”

Section: Prior Workmentioning

confidence: 99%

Access control for the services oriented architecture

Karp

2007

Proceedings of the 2007 ACM Workshop on Secure Web Services

View full text Add to dashboard Cite

Federated Identity Management (FIdM) is being applied to Services Oriented Architecture (SOA) deployments that cross enterprise boundaries. Though federation is essential in order to address the distributed nature of SOA, these FIdM solutions have been found to be inflexible, unscalable, and difficult to use, manage, and upgrade. We contend that a major reason for these difficulties is that FIdM addresses the wrong aspect of the problem. Specifically, FIdM does not address the federation of access policies. What is needed is a system for Federated Access Management (FAccM). This paper demonstrates the benefits of FAccM over FIdM for SOA deployments and shows how FAccM can be implemented using the existing web services standards.

show abstract

Distributed Capability Computing System (DCCS)

Cited by 11 publications

References 6 publications

Chaperones and impersonators

Chaperones and impersonators

Solving the Transitive Access Problem for the Services Oriented Architecture

Access control for the services oriented architecture

Contact Info

Product

Resources

About