Working Notes on Protocol Centric Compositional Architecture: Section 3 – Distributed Security Capability Architecture

1. Working Notes on Protocol Centric Compositional Architecture: Section 3 – Distributed Security Capability Architecture by Robert J. DuWors 04 / 26 / 2005

2. Innovating the next Dominant Design for Large Scale Distributed Systems Section 1: Compositional Architecture Need: Architectural understanding of what we really do in practice everyday on the Web and to jump start better architectures for more effective solutions. Solution: Compositional Architecture is the first architectural framework as flexible as the Web itself and offers a powerful framework going forward. Section 2: Protocol Translating User Agents and Models Need: Provision of well structured customized functionality and unique User Experience for specialized User Community markets at competitive cost. Solution: Application Level Protocols (ASLP) link Service Oriented Models (SO-M) that extend core product functionality flexibly and inexpensively, to Protocol Translating User Agents (PTUA) that tailor User Experience on the fly. Section 3: Distributed Security Capability Architecture Need: Trustworthy security from top to bottom of all architectural levels without too much or too little securing of highly scalable, dynamic, distributed systems. Solution: Permission Rule Based Capability model for coarse through fine grained control, and for scalable, adaptable “just right” security controls from top-to-bottom and end-to-end: a big step beyond the currently dominant but troubled Access Control List (ACL) model.

3. Rule Based Dynamic Capability Model: Innovating an Advanced Security Model using Compositional Architecture • Opportunity: • Take market leadership by adding a trustworthy security model to product line architecture much • advanced over the inadequate standards of current security practices. • Challenges: • Much of what appears to be implementation errors such as “buffer overflow” mask deeper failures in the • underlying security model: how can so much evil result from hijacking a simple component? • the dominate Access Control List (ACL) approach is inadequate and nearing a state of collapse • ACLs are far too resource oriented and do not hide their resource’s existence from prying eyes • ACLS are like giving blue prints to bank robbers and then trying to setup barriers to keep them out • small elaborations like “roles” and “groups” lack flexibility to meet to the needs of real world systems • typically result in “lowest common denominator” security that is too weak, or overly restrictive, • or both! • with ACLs it nearly impossible to tailor security policies to individuals or fine grained resources • and operations e.g., limit some but not all document sections to changes by only voice inputs • Must be able to handle subjects and resources that come and go in short life times, e.g. transactional entities • not all subjects can be known in advance, so how to implement security policies for them? • dynamically created resources may need to be operated on by transient and persistent subjects • an entity may be both a subject and resource, e.g. “my action rules, and the rule of acting on me” • coarse grain, fine grain, and hierarchies of subjects and resources must be supported in security rules • collections of subjects and resources must allow for traditional “roles” and “groups” • security rules must be gathered from multiple sources • in the network • by category: subject, operation, resource, or combination of the same • Needed: A new security model to be the dominant design to make distributed systems truly trustworthy • Solution: Compositional Architecture of a Protocol Oriented Dynamic Rule Based Capability Security Model

4. Resource ACL Column View Subjects Resources Access Control Matrix Subject AC/DC: Both Subjects And Resources Capability Row View Permission Control Cell: Control Rules Intentional – membership computed, or selected by common attributes (often late binding but not always): “Role based” * Extensional – explicitly enumerated group members (often by early binding but not always): “Group based” * • Subjects • can be anything • may overlap with Resources • can be static or dynamic • can be administrated in advance or not • Resources • can be anything • may overlap with Subjects • can be static or dynamic • .can be administrated in advance or not • Operations • actions that subjects perform on resources • Access Control Rules • permit or deny operations * can be hierarchical Subjects Resources I.D.C “X” Intentionally Defined Collection “Y” Extensionally Defined Collection “Z” E.D.C. “V”

5. The Four Basic Security Entities1 • Collections • 1 All of the above (Subjects, Resources, Operations, and Permission Rules) can be organized into hierarchical • collections, e.g. by company, division, department. Thus they all can be very coarse grained through to very fine grained. • 2 Subjects and/or Resources can be combined in pre-defined collections: • “Roles” which are intentionally defined, i.e. membership is by a selective criteria. • “Groups” which are extensional defined, i.e. membership is by explicit enumeration. • Subjects and/or Resources can be in collections that use both intentional criteria and enumeration, e.g. : • “Joe” has attribute “Editor” (intentional role criteria) but other rules explicitly exclude him (extensional group) from editing. • “Sam” is listed (extensional group) in “Favorite Pets” and has attribute “Dog” (intentional role criteria). • n.b. Subjects and Resources can overlap, e.g. “Joe” can be a Subject for his own rules, but a Resource for his Manager’s rules. • 3 Operations and/or Permission Rules optionally may have attributes and can be similarly organized into intentional • and extensional collections as convenient. e.g. : • Operation “Annotate” is part of the (intentional) “Editing” family. • Permission Rule “allow(launch( joe, missile))” is parted of customized (extensional) special permissions.

6. Further Notes on the 4 Basic Security Entities • Life Time • All Subjects, Resources, Operations, Permission Rules can be: • created and destroyed statically or dynamically • short term or long term persistent • used for highly dynamic environments where things come and go frequently • The Total Permission Control Set used at Request Time • The Total Permission Control Set used to allow or deny the operation at the time of the request is: • Total Permission Rules = • all rules applicable for the subject from all sources & • all rules applicable for the resource from all sources & • all applicable rules for the operation from all sources & • all applicable compound rules for the subject and/or the resource and/or the operation. • Timing of Rules bound into the Total Permission Control Set using Compositional Architecture: • Early Binding: rules resolved in advance of usage • Late Binding: rules with pre-defined references resolved at time of usage • Meta-Binding: rules created as needed at time of usage • Early and Late Binding allow the possibility of (at least partial) optimization by pre-compiling the rules • Meta-binding requires an interpretative run time rules engine

7. Composing (Meta-binding) Access Rules Rules by Resource Compound Rules by Subject and/or by Resource and/or by Operation Rules by Subject Compose the Total Set of access control rules by merging (meta-binding) all sources of the four types of rules. Rules by Operation

8. Example of Dynamically Composing (Meta-Binding) Access Rules from Multiple Sources Compound Rules by Subject/Resource/Operation Rules by Resource Rules by Subject Joe is an Editor (can Edit). Joe has a Secret clearance. This Work Plan is Secret. This Work Plan is Version 2. Joe may see a Work Plan Version 1 or 2. Joe may not Fly a Plane. Example 1: Editing a document requires being able to see it. Joe can see a Work Plan Version 1 or 2. Editing a document requires the corresponding mandatory clearance. Joe has a Secret clearance. This document is Secret and Work Plan Version 2. ===> Joe can edit this Work Plan document! • Example 2: • By simply changing the rule so that Joe may see only a Work Plan Version 1: • Joe loses the ability to see this particular document and thus can not edit it either. • But nothing else needs to be changed, i.e. no change to Joe’s or to the Work Plan’s individual attributes or to the Edit operation rules. Rules by Operation Editing requires being able to see the document. Editing is controlled by clearance level.

9. Notes and Implications of Dynamic Capabilities as a Security Mechanism • Early binding (building all in advance) severely constrains flexibility, late binding (hooking-in some • belated pieces as needed) somewhat improves flexibility, but meta binding (creating entities as • needed) defines the maximum limits of flexibility! • meta-binding is very important because we generally know how (with suitable effort) to build • high performance systems, high capacity systems, even high reliability systems, but no • currently established technique is particularly good at building highly flexible systems • combined with all the other attributes • thus the real challenge of this decade is precisely how to build highly flexible systems in • response to fast changing business needs and reduce the cost of evolving our current highly • inflexible systems • meta-binding also provides one of the best technique to raise the level of knowledge • representation and automation – which is the Holy Grail of IT! • Many business processes require collaboration between administrative domains (security realms) • and meta binding will have to be combined with the notions importing and exporting access • decisions across security realms, while taking into account the relative level of trust between • domains (which of course are yet another set of security policy rules!) • intra-realmsecurity entities, roles, groups, and lower level resources do not necessarily need • to be known between security domains • but an SAML style protocol must define the shared notion of the inter-realm, entities, roles, • groups, and resources which may be mapped internally in a different manner by each realm • “universal/enterprise identity management” is neither necessary nor desirable

10. Notes and Implications of Dynamic Capabilities as a Security Mechanism – cont’d • There are two fundamental implementation strategies for security (whether Capability based or ACL): • Pro-active security (a.k.a. “model based security”): the security rules are known to the model (or the • “source”) and model itself honors and thereby enforces the security rules as part of itself • Filtered security: an intermediate entity acting as a proxy knows the security rules (or at least additional • ones) and passes through only that which is permitted and filters out the rest • Pro-active security: is generally the stronger security strategy because it penetrates deeply into the • application semantics and this use of security rules is less likely to leave unexpected “holes” • Filtered security: in a protocol oriented architecture, filtered security can act as a “wrapper” around • unsecured models and can be used flexibly to add security policy rules as part of external customization • Each Layer of a Distributed Architecture may be partitioned internally into sub-domains of administrative • responsibility as needed • Security realms may also differentiate between the Layers as well by using different security realms in different • Layers: • this is vitally important when the “model” is centrally or externally administrated and can not be modified directly by user communities • by using extension models and filtering style security, administrative control at the middle level may • be placed (at least partially) into the hands of the user communities: • this means that to a significant degree the user communities can control their own fate how the • application semantics appear to them, what additional security constraints must be honored, and • even how separately administrated models are “joined together” and delivered by the extension • model’s protocol to user community’s version of user agents • this can be extremely useful in terms of the “organizational dynamics” of large, highly structured • enterprises that employ rigorously centralized “releases”, “block points”, and the like • it can also drastically lower the cost of customization relative to avoiding unnecessary changes to the • basic model and the pain of customizing JSP/ASP frameworks and libraries • e.g. a complex generic software product has 80% of the application semantics, the various • extension models complete the other 20% according to their own needs, and the Protocol • Translating User Agents deal with end user presentation and interaction for the user community • multiple security filters organized in a “pipeline” are a dual of “wrapped objects” in a bracket architecture

11. Notes and Implications of Dynamic Capabilities as a Security Mechanism – cont’d • BUT THE BIG SURPRISE FOR DYNAMIC CAPABILITIES IS: • The same rule set that limits permissible operations also drives personalization! • specifically security provides the portion of the personalization • rules that constrain the range of permissible “actions” • and “views” (both of which are types of operations) • thus “Security” is part of “Personalization”