The document discusses access control and authorization in distributed systems. It introduces role-based access control (RBAC) as a promising approach. RBAC separates the administration of principals and roles from the specification of authorization policy in terms of roles. This allows authorization policy to be expressed independently of changes to principal membership. RBAC also facilitates inter-domain authorization by allowing roles to span domains. The document presents an example RBAC implementation using the OASIS framework that specifies role activation and authorization policies using rules. It also discusses engineering role certificates and maintaining credential state to support RBAC in a distributed environment.
This document discusses various access control models and concepts. It begins by defining access control as the prevention of unauthorized use of resources, controlling who can access a resource, under what conditions, and what they are allowed to do. It then covers different access control models and concepts in detail including access control matrices, access control lists, capabilities, role-based access control (RBAC), mandatory access control (MAC), and separation of duty constraints. RBAC is described as defining roles and associated permissions rather than assigning permissions directly to users. Hierarchical and static/dynamic separation of duty extensions to the core RBAC model are also summarized.
1. The document discusses access control models and concepts, including the reference monitor model, subjects and objects, access rights, and access control structures like access control matrices, capabilities, and access control lists.
2. Role-based access control (RBAC) is introduced as a model that uses roles as an intermediate access control layer between subjects and objects. Roles are defined by assigning permissions to perform certain procedures on particular types of objects.
3. Other access control concepts covered include security labels and partial orderings to compare sensitivity levels associated with subjects and objects. Lattices provide a mathematical structure to determine the least privileged label for a subject to access multiple objects.
IRJET- A Review On - Controlchain: Access Control using BlockchainIRJET Journal
This document summarizes several access control models that could be used for the Internet of Things (IoT), including Mandatory Access Control (MAC), Discretionary Access Control (DAC), Role-Based Access Control (RBAC), Attribute-Based Access Control (ABAC), Organization-Based Access Control (OrBAC), and OAuth. It discusses the key components, advantages, and limitations of each model. Specifically, it notes that MAC and DAC focus on confidentiality but lack flexibility, RBAC is well-suited for independent domains but not cross-domains, ABAC provides more flexible access based on user, resource, and environment attributes defined in XACML policies, and OrBAC extends this to incorporate organizational
With sharing or without sharing... is that the question? Join us to better understand how to leverage the best Salesforce security features in code. Learn all the best practices for hardening your application and keeping your data secure. We'll cover sharing, FLS, CRUD, and all the most common mistakes and misconceptions about how these features work in Apex and Visualforce.
Aos v unit protection and access controlvanamali_vanu
This document discusses the goals, principles, and implementation of protection in computer systems. The key points are:
1) Protection aims to prevent malicious use, ensure resources are only used according to policies, and minimize damage from errant programs.
2) The principle of least privilege dictates that users and programs are given only the minimal privileges needed to perform their tasks.
3) Protection domains define the resources a process can access, with access rights specifying allowed operations on each object. Domains can be static or allow switching between processes.
Goals of Protection
Principles of Protection
Domain of Protection
Access Matrix
Implementation of Access Matrix
Access Control
Revocation of Access Rights
Capability-Based Systems
Language-Based Protection
The document discusses security mechanisms in Linux operating systems. It covers access control modules, including audit, access control, and role-based access control modules. It also discusses security models like DAC, MAC, RBAC and how they integrate with the operating system's security tag library and audit log. The principles of least privilege, separation of duties and simplicity are important to the design.
This document discusses various access control models and concepts. It begins by defining access control as the prevention of unauthorized use of resources, controlling who can access a resource, under what conditions, and what they are allowed to do. It then covers different access control models and concepts in detail including access control matrices, access control lists, capabilities, role-based access control (RBAC), mandatory access control (MAC), and separation of duty constraints. RBAC is described as defining roles and associated permissions rather than assigning permissions directly to users. Hierarchical and static/dynamic separation of duty extensions to the core RBAC model are also summarized.
1. The document discusses access control models and concepts, including the reference monitor model, subjects and objects, access rights, and access control structures like access control matrices, capabilities, and access control lists.
2. Role-based access control (RBAC) is introduced as a model that uses roles as an intermediate access control layer between subjects and objects. Roles are defined by assigning permissions to perform certain procedures on particular types of objects.
3. Other access control concepts covered include security labels and partial orderings to compare sensitivity levels associated with subjects and objects. Lattices provide a mathematical structure to determine the least privileged label for a subject to access multiple objects.
IRJET- A Review On - Controlchain: Access Control using BlockchainIRJET Journal
This document summarizes several access control models that could be used for the Internet of Things (IoT), including Mandatory Access Control (MAC), Discretionary Access Control (DAC), Role-Based Access Control (RBAC), Attribute-Based Access Control (ABAC), Organization-Based Access Control (OrBAC), and OAuth. It discusses the key components, advantages, and limitations of each model. Specifically, it notes that MAC and DAC focus on confidentiality but lack flexibility, RBAC is well-suited for independent domains but not cross-domains, ABAC provides more flexible access based on user, resource, and environment attributes defined in XACML policies, and OrBAC extends this to incorporate organizational
With sharing or without sharing... is that the question? Join us to better understand how to leverage the best Salesforce security features in code. Learn all the best practices for hardening your application and keeping your data secure. We'll cover sharing, FLS, CRUD, and all the most common mistakes and misconceptions about how these features work in Apex and Visualforce.
Aos v unit protection and access controlvanamali_vanu
This document discusses the goals, principles, and implementation of protection in computer systems. The key points are:
1) Protection aims to prevent malicious use, ensure resources are only used according to policies, and minimize damage from errant programs.
2) The principle of least privilege dictates that users and programs are given only the minimal privileges needed to perform their tasks.
3) Protection domains define the resources a process can access, with access rights specifying allowed operations on each object. Domains can be static or allow switching between processes.
Goals of Protection
Principles of Protection
Domain of Protection
Access Matrix
Implementation of Access Matrix
Access Control
Revocation of Access Rights
Capability-Based Systems
Language-Based Protection
The document discusses security mechanisms in Linux operating systems. It covers access control modules, including audit, access control, and role-based access control modules. It also discusses security models like DAC, MAC, RBAC and how they integrate with the operating system's security tag library and audit log. The principles of least privilege, separation of duties and simplicity are important to the design.
Authorization is the process of giving someone permission to do or have something.
Table of Content
Introduction Authorization
Common Attacker Testing Authentication
Strategies For Strong Authentication
Access Control
UNIT 3- DATABASE INTEGRITY AND SECURITY CONCEPTS (1).pdfKavitaShinde26
This document provides an overview of database integrity and security concepts. It discusses domain constraints and referential integrity, which enforce data validity. It then covers database security topics like authentication, access control using methods like discretionary access control and mandatory access control. Role-based access control is described for assigning user permissions. The use of views for security enforcement and an overview of encryption techniques like symmetric and public key encryption are also summarized. The document is presented as part of a course on database concepts by an assistant professor.
Experience Mazda Zoom Zoom Lifestyle and Culture by Visiting and joining the Official Mazda Community at http://www.MazdaCommunity.org for additional insight into the Zoom Zoom Lifestyle and special offers for Mazda Community Members. If you live in Arizona, check out CardinaleWay Mazda's eCommerce website at http://www.Cardinale-Way-Mazda.com
This document discusses protection in operating systems. It covers the goals of protection which include ensuring objects are only accessed by allowed processes. Principles of protection include least privilege and need-to-know. Protection domains and access matrices are used to specify allowed access. Implementation options for access matrices include access lists, capability lists, and lock-key systems. Role-based access control and revocation of access rights are also covered. Capability-based systems like Hydra and Cambridge CAP are described. Finally, language-based protection specifies policies through programming languages.
1.1 Cyber Security Layers of Defense and Technology Solutions.pdf.pdfThangVuQuang4
This document discusses layers of defense and technology solutions in cybersecurity. It covers topics like access control, application security, data security, host security, network security, and cloud security. For access control, it describes identification, authentication, authorization, and accountability. It provides examples of access control in computer systems and bank vault access. For application security, it discusses the need to protect applications and data. It describes web application firewalls, email security gateways, and database security platforms that can detect and prevent attacks targeting applications.
This presentation covers the topic of access control in software. Access control is an essential part of every software application that manages data of any value. However, access control is also complex and hard to get right, both from a development and management point of view.
In this presentation, we first explore the concept and goals of access control in general. We then discuss the different models that exist in practice and in literature to reason about access control. We then investigate different approaches of how to enforce access control in an application. Overall, this sessions aims to provide deeper insights into access control in order to better reason about it and implement it correctly and efficiently.
Access Control Facilities in Oracle Database 11g r2Amin Saqi
The document discusses access control facilities in Oracle Database 11gR2. It describes how user groups can be implemented through profiles or roles. Hierarchical role-based access control and role-based access control with separation of duty using Oracle Database Vault are also covered. The document outlines how time-based and location-based access constraints can be achieved and discusses cascading revocation and conflict resolution. Mandatory access control using Oracle Label Security and tools for administering access policies are also introduced.
Railsplitter is a framework which significantly reduces development cost to expose a hierarchical data model as a production quality Create, Read, Update, and Delete (CRUD) web service. Railsplitter adopts JSON API [10] as the standard for the service definition given its focus on consumption by front-end developers. Inherent in the design of JSON API are capabilities that reduce the number of round trips from client to server to fetch or update data. Updates on disparate models can happen in a single request allowing the server to build atomicity guarantees. Rather than starting from scratch with a domain-specific language (DSL) to describe a data model, Railsplitter adopts Java Persistence API (JPA) [6] - a modeling definition that is rich and has a long tenure of proven provider implementations. Unlike other approaches, Railsplitter addresses the fundamental needs of flexible, model driven authorization, interoperability with client side applications, and test automation.
1. The document outlines security risks related to inadequate SAP security administration procedures and controls. It lists internal controls and corresponding audit procedures to evaluate access restrictions, segregation of duties, password controls, and access to sensitive data and programs.
2. Specific risks addressed include failure to restrict access to security administration functions, lack of segregation of security roles, and unauthorized access due to weak password controls or unrestricted custom programs.
3. The audit procedures involve inquiries with security administration, reviewing access logs and profiles, and examining password parameters to evaluate compliance with guidelines.
The document discusses the challenge of implementing scalable authorization and describes how to use Keycloak's authorization service to achieve it. Keycloak allows defining fine-grained authorization policies and centralizing authorization data, improving scalability. Combined with OPA and CockroachDB, Keycloak can also enhance performance and availability while maintaining a centralized approach. The document provides an overview of Keycloak's authorization capabilities and how they enable scalable and standards-based authorization.
Access control regulates operations on protected data and resources. It aims to control what subjects can do to prevent damage. Access control is provided by operating systems and database management systems. It uses reference monitors to grant or deny access requests from subjects for objects based on access control policies and permissions. Access control mechanisms implement the access control function using permissions or subject/object attributes to make access decisions.
This document provides definitions and terminology related to computer security architecture and models. It defines key terms like access control, authentication, authorization, confidentiality, integrity, and availability. It also summarizes several influential security models like Bell-LaPadula, Biba, Clark-Wilson, and discusses certification and accreditation procedures. The document also briefly outlines the IPSEC standard and some general network and host security concepts.
10 Steps to Better Windows Privileged Access ManagementBeyondTrust
In this presentation from his webinar, Derek A. Smith, Founder, National Cybersecurity Education Center, delves into the strategies and techniques attackers use to gain privileged access to systems, and how you can stop them.This presentation covers:
- Privileged Windows accounts
- The importance of managing privileged access in Windows
- How attackers compromise Windows Privileged Accounts
- Challenges PAM can help solve in your Windows environment
- 10 Steps to better Windows privileged access management
You can also watch the full webinar on-demand here: https://www.beyondtrust.com/resources/webinar/10-steps-better-windows-privileged-access-management/
International Journal of Engineering Inventions (IJEI) provides a multidisciplinary passage for researchers, managers, professionals, practitioners and students around the globe to publish high quality, peer-reviewed articles on all theoretical and empirical aspects of Engineering and Science.
The peer-reviewed International Journal of Engineering Inventions (IJEI) is started with a mission to encourage contribution to research in Science and Technology. Encourage and motivate researchers in challenging areas of Sciences and Technology.
Access control is a collection of methods that enforce confidentiality and integrity by controlling access to resources. It allows only authorized users to access permitted objects like files, devices, or network connections. There are different models of access control, including discretionary access control (DAC) where owners set access rules, mandatory access control (MAC) where rules are based on security labels, and role-based access control (RBAC) where rules are based on user roles. Effective access control requires policies, least privilege, auditing, and technical controls like access control lists that implement the rules.
This document provides an overview of SAP security. It discusses key concepts like user master records, roles, profiles, and authorization objects which form the building blocks of SAP security. It also explains common terminologies and tools used in SAP security like user buffer, authorization errors, and security matrix. The document demonstrates how authorization checks work when executing a transaction in SAP and lists some standard SAP password controls. It introduces the Central User Administration feature and provides examples of common security tools in SAP.
Data modeling is the process of exploring data structures and relationships. It involves identifying entity types, attributes, relationships and applying normalization. Conceptual, logical and physical data models are used at different stages of the design process. Database security involves techniques like access control, encryption and firewalls to protect data confidentiality, integrity and availability. Issues like SQL injection occur when user input is not sanitized before passing to the database.
This document discusses information systems analysis and prototyping. It begins with an agenda that covers defining prototyping, the need for it, types of prototypes, prototyping as a methodology, user interface prototyping, and advantages and disadvantages. It then defines prototyping and discusses the need for it to explore problems and solutions with stakeholders. Various types of prototypes are covered, including throwaway, evolutionary, low-fidelity, and high-fidelity. Prototyping is presented as a methodology involving preliminary designs and refinements. The document concludes with risks of prototyping and key learnings around using prototypes to understand requirements and evolve systems.
The document discusses the OWASP Software Assurance Maturity Model (SAMM) which provides a framework for organizations to improve their application security practices. SAMM defines security practices across various stages of the development lifecycle. It establishes maturity levels for each practice to guide organizations from an initial to comprehensive approach. SAMM includes assessment worksheets, roadmap templates, and other resources to help organizations measure their maturity and develop a phased plan to strengthen security.
Authorization is the process of giving someone permission to do or have something.
Table of Content
Introduction Authorization
Common Attacker Testing Authentication
Strategies For Strong Authentication
Access Control
UNIT 3- DATABASE INTEGRITY AND SECURITY CONCEPTS (1).pdfKavitaShinde26
This document provides an overview of database integrity and security concepts. It discusses domain constraints and referential integrity, which enforce data validity. It then covers database security topics like authentication, access control using methods like discretionary access control and mandatory access control. Role-based access control is described for assigning user permissions. The use of views for security enforcement and an overview of encryption techniques like symmetric and public key encryption are also summarized. The document is presented as part of a course on database concepts by an assistant professor.
Experience Mazda Zoom Zoom Lifestyle and Culture by Visiting and joining the Official Mazda Community at http://www.MazdaCommunity.org for additional insight into the Zoom Zoom Lifestyle and special offers for Mazda Community Members. If you live in Arizona, check out CardinaleWay Mazda's eCommerce website at http://www.Cardinale-Way-Mazda.com
This document discusses protection in operating systems. It covers the goals of protection which include ensuring objects are only accessed by allowed processes. Principles of protection include least privilege and need-to-know. Protection domains and access matrices are used to specify allowed access. Implementation options for access matrices include access lists, capability lists, and lock-key systems. Role-based access control and revocation of access rights are also covered. Capability-based systems like Hydra and Cambridge CAP are described. Finally, language-based protection specifies policies through programming languages.
1.1 Cyber Security Layers of Defense and Technology Solutions.pdf.pdfThangVuQuang4
This document discusses layers of defense and technology solutions in cybersecurity. It covers topics like access control, application security, data security, host security, network security, and cloud security. For access control, it describes identification, authentication, authorization, and accountability. It provides examples of access control in computer systems and bank vault access. For application security, it discusses the need to protect applications and data. It describes web application firewalls, email security gateways, and database security platforms that can detect and prevent attacks targeting applications.
This presentation covers the topic of access control in software. Access control is an essential part of every software application that manages data of any value. However, access control is also complex and hard to get right, both from a development and management point of view.
In this presentation, we first explore the concept and goals of access control in general. We then discuss the different models that exist in practice and in literature to reason about access control. We then investigate different approaches of how to enforce access control in an application. Overall, this sessions aims to provide deeper insights into access control in order to better reason about it and implement it correctly and efficiently.
Access Control Facilities in Oracle Database 11g r2Amin Saqi
The document discusses access control facilities in Oracle Database 11gR2. It describes how user groups can be implemented through profiles or roles. Hierarchical role-based access control and role-based access control with separation of duty using Oracle Database Vault are also covered. The document outlines how time-based and location-based access constraints can be achieved and discusses cascading revocation and conflict resolution. Mandatory access control using Oracle Label Security and tools for administering access policies are also introduced.
Railsplitter is a framework which significantly reduces development cost to expose a hierarchical data model as a production quality Create, Read, Update, and Delete (CRUD) web service. Railsplitter adopts JSON API [10] as the standard for the service definition given its focus on consumption by front-end developers. Inherent in the design of JSON API are capabilities that reduce the number of round trips from client to server to fetch or update data. Updates on disparate models can happen in a single request allowing the server to build atomicity guarantees. Rather than starting from scratch with a domain-specific language (DSL) to describe a data model, Railsplitter adopts Java Persistence API (JPA) [6] - a modeling definition that is rich and has a long tenure of proven provider implementations. Unlike other approaches, Railsplitter addresses the fundamental needs of flexible, model driven authorization, interoperability with client side applications, and test automation.
1. The document outlines security risks related to inadequate SAP security administration procedures and controls. It lists internal controls and corresponding audit procedures to evaluate access restrictions, segregation of duties, password controls, and access to sensitive data and programs.
2. Specific risks addressed include failure to restrict access to security administration functions, lack of segregation of security roles, and unauthorized access due to weak password controls or unrestricted custom programs.
3. The audit procedures involve inquiries with security administration, reviewing access logs and profiles, and examining password parameters to evaluate compliance with guidelines.
The document discusses the challenge of implementing scalable authorization and describes how to use Keycloak's authorization service to achieve it. Keycloak allows defining fine-grained authorization policies and centralizing authorization data, improving scalability. Combined with OPA and CockroachDB, Keycloak can also enhance performance and availability while maintaining a centralized approach. The document provides an overview of Keycloak's authorization capabilities and how they enable scalable and standards-based authorization.
Access control regulates operations on protected data and resources. It aims to control what subjects can do to prevent damage. Access control is provided by operating systems and database management systems. It uses reference monitors to grant or deny access requests from subjects for objects based on access control policies and permissions. Access control mechanisms implement the access control function using permissions or subject/object attributes to make access decisions.
This document provides definitions and terminology related to computer security architecture and models. It defines key terms like access control, authentication, authorization, confidentiality, integrity, and availability. It also summarizes several influential security models like Bell-LaPadula, Biba, Clark-Wilson, and discusses certification and accreditation procedures. The document also briefly outlines the IPSEC standard and some general network and host security concepts.
10 Steps to Better Windows Privileged Access ManagementBeyondTrust
In this presentation from his webinar, Derek A. Smith, Founder, National Cybersecurity Education Center, delves into the strategies and techniques attackers use to gain privileged access to systems, and how you can stop them.This presentation covers:
- Privileged Windows accounts
- The importance of managing privileged access in Windows
- How attackers compromise Windows Privileged Accounts
- Challenges PAM can help solve in your Windows environment
- 10 Steps to better Windows privileged access management
You can also watch the full webinar on-demand here: https://www.beyondtrust.com/resources/webinar/10-steps-better-windows-privileged-access-management/
International Journal of Engineering Inventions (IJEI) provides a multidisciplinary passage for researchers, managers, professionals, practitioners and students around the globe to publish high quality, peer-reviewed articles on all theoretical and empirical aspects of Engineering and Science.
The peer-reviewed International Journal of Engineering Inventions (IJEI) is started with a mission to encourage contribution to research in Science and Technology. Encourage and motivate researchers in challenging areas of Sciences and Technology.
Access control is a collection of methods that enforce confidentiality and integrity by controlling access to resources. It allows only authorized users to access permitted objects like files, devices, or network connections. There are different models of access control, including discretionary access control (DAC) where owners set access rules, mandatory access control (MAC) where rules are based on security labels, and role-based access control (RBAC) where rules are based on user roles. Effective access control requires policies, least privilege, auditing, and technical controls like access control lists that implement the rules.
This document provides an overview of SAP security. It discusses key concepts like user master records, roles, profiles, and authorization objects which form the building blocks of SAP security. It also explains common terminologies and tools used in SAP security like user buffer, authorization errors, and security matrix. The document demonstrates how authorization checks work when executing a transaction in SAP and lists some standard SAP password controls. It introduces the Central User Administration feature and provides examples of common security tools in SAP.
Data modeling is the process of exploring data structures and relationships. It involves identifying entity types, attributes, relationships and applying normalization. Conceptual, logical and physical data models are used at different stages of the design process. Database security involves techniques like access control, encryption and firewalls to protect data confidentiality, integrity and availability. Issues like SQL injection occur when user input is not sanitized before passing to the database.
This document discusses information systems analysis and prototyping. It begins with an agenda that covers defining prototyping, the need for it, types of prototypes, prototyping as a methodology, user interface prototyping, and advantages and disadvantages. It then defines prototyping and discusses the need for it to explore problems and solutions with stakeholders. Various types of prototypes are covered, including throwaway, evolutionary, low-fidelity, and high-fidelity. Prototyping is presented as a methodology involving preliminary designs and refinements. The document concludes with risks of prototyping and key learnings around using prototypes to understand requirements and evolve systems.
The document discusses the OWASP Software Assurance Maturity Model (SAMM) which provides a framework for organizations to improve their application security practices. SAMM defines security practices across various stages of the development lifecycle. It establishes maturity levels for each practice to guide organizations from an initial to comprehensive approach. SAMM includes assessment worksheets, roadmap templates, and other resources to help organizations measure their maturity and develop a phased plan to strengthen security.
The document discusses validating all inputs to prevent cross-site scripting (XSS) attacks. It introduces the OWASP HTML Sanitizer Project, which is a Java library that sanitizes HTML to allow untrusted user input to be safely embedded in web pages. The sanitizer removes malicious code while keeping desired markup, through a policy-based approach. Sample usages demonstrated validate specific elements like images and links. The project aims to protect against XSS while allowing third-party content through a tested, securely-designed library.
The document provides information on coding techniques and best practices for variable declarations and naming. It discusses data types, initializing variables, variable scope, naming conventions, and the Hungarian notation naming convention. The key points are:
- Variables should be declared close to where they are used and initialized immediately to avoid errors from unintended values.
- Variable names should be descriptive yet concise to indicate what they represent and avoid confusion. Naming conventions can help with readability and consistency.
- The Hungarian notation convention prefixes variable names with abbreviations to indicate their type, scope, and other properties to make their purpose clear at a glance.
Defensive programming techniques aim to avoid problems in code development and during runtime. Issues that can occur include dodgy user input data, poorly structured code that is hard to maintain, and runtime errors. Defensive design focuses on preventing unintended exploitation of systems, keeping code well-organized, and minimizing bugs. Input validation and sanitization are important techniques to check user data meets criteria and remove unwanted characters. Database inputs especially need to be sanitized to prevent SQL injection attacks.
This document discusses defensive programming techniques of assertions and parameter checking. Assertions allow programmers to explicitly check assumptions in code through boolean conditions. If an assertion fails, it throws an error. Parameter checking validates function parameters are valid, either through assertions or throwing exceptions if invalid. Both help avoid bugs by detecting errors early.
This document provides an overview of the requirements analysis process. It explains that requirements come from both business and technical perspectives and describe what the system must do and how it will be implemented. Various techniques for gathering requirements are discussed, including interviews, documentation analysis, questionnaires, observation, and prototyping. The importance of user involvement and properly documenting requirements is also covered.
This document provides an overview of the requirements analysis process. It explains that requirements come from both business and technical perspectives and describe what the system must do and how it will be implemented. Various techniques for gathering requirements are discussed, including interviews, documentation analysis, questionnaires, observation, and prototyping. The importance of user involvement and properly documenting requirements is also covered.
The document provides an overview of a lecture on system analysis and design (SAD). It introduces SAD processes and approaches, including structured analysis, design, and programming as well as object-oriented analysis and design. Key concepts covered include objects, classes, encapsulation, inheritance, and polymorphism in the object-oriented approach.
This document covers topics in requirements engineering including functional and non-functional requirements, the software requirements document, requirements specification, and requirements processes. It defines requirements engineering as establishing customer services and system constraints. Requirements can range from abstract to detailed specifications and serve both bidding and contractual purposes. User requirements use natural language while system requirements provide structured descriptions. Functional requirements define system services and behaviors while non-functional requirements constrain timing, standards, and processes.
The document provides information on modeling business processes using activity diagrams. It discusses the key elements and notation of activity diagrams including activities, transitions, start/final states, decisions, swimlanes, and parallel activities. Guidelines are provided for creating activity diagrams such as setting the context, identifying activities and organizing them in order, adding decisions, object flows, prospects for parallelism, and swimlanes. An example activity diagram for a dentist office system is described and guidelines are given for developing the diagram and associated use case descriptions.
This document provides an overview of use case modeling. It defines what use cases are, how they are created, and the elements that comprise them. Use cases describe the functional requirements of a system from the perspective of an actor. They are developed through user interviews and documentation analysis to understand how users interact with the system. Use cases are then written as text descriptions and organized visually in a use case diagram to show relationships between use cases and actors.
Presentation Use Case Diagram and Use Case Specification.pptxazida3
The use case diagram models the interactions between a Customer and an ATM machine. The Customer can perform the use cases of Logging In, Making a Withdrawal, Checking Balance, and Depositing Funds. The ATM machine facilitates these use cases.
The document provides an overview of a module on system analysis and design (SAD). It discusses the structured approach to SAD using techniques like data flow diagrams, entity relationship diagrams, and structure charts. It also covers the object-oriented approach, defining key concepts like objects, classes, encapsulation, inheritance, and polymorphism. The structured approach models the problem as a set of functions, while the object-oriented approach models the real world and subdivides problems based on objects.
How to Add Chatter in the odoo 17 ERP ModuleCeline George
In Odoo, the chatter is like a chat tool that helps you work together on records. You can leave notes and track things, making it easier to talk with your team and partners. Inside chatter, all communication history, activity, and changes will be displayed.
Walmart Business+ and Spark Good for Nonprofits.pdfTechSoup
"Learn about all the ways Walmart supports nonprofit organizations.
You will hear from Liz Willett, the Head of Nonprofits, and hear about what Walmart is doing to help nonprofits, including Walmart Business and Spark Good. Walmart Business+ is a new offer for nonprofits that offers discounts and also streamlines nonprofits order and expense tracking, saving time and money.
The webinar may also give some examples on how nonprofits can best leverage Walmart Business+.
The event will cover the following::
Walmart Business + (https://business.walmart.com/plus) is a new shopping experience for nonprofits, schools, and local business customers that connects an exclusive online shopping experience to stores. Benefits include free delivery and shipping, a 'Spend Analytics” feature, special discounts, deals and tax-exempt shopping.
Special TechSoup offer for a free 180 days membership, and up to $150 in discounts on eligible orders.
Spark Good (walmart.com/sparkgood) is a charitable platform that enables nonprofits to receive donations directly from customers and associates.
Answers about how you can do more with Walmart!"
How to Build a Module in Odoo 17 Using the Scaffold MethodCeline George
Odoo provides an option for creating a module by using a single line command. By using this command the user can make a whole structure of a module. It is very easy for a beginner to make a module. There is no need to make each file manually. This slide will show how to create a module using the scaffold method.
Executive Directors Chat Leveraging AI for Diversity, Equity, and InclusionTechSoup
Let’s explore the intersection of technology and equity in the final session of our DEI series. Discover how AI tools, like ChatGPT, can be used to support and enhance your nonprofit's DEI initiatives. Participants will gain insights into practical AI applications and get tips for leveraging technology to advance their DEI goals.
বাংলাদেশের অর্থনৈতিক সমীক্ষা ২০২৪ [Bangladesh Economic Review 2024 Bangla.pdf] কম্পিউটার , ট্যাব ও স্মার্ট ফোন ভার্সন সহ সম্পূর্ণ বাংলা ই-বুক বা pdf বই " সুচিপত্র ...বুকমার্ক মেনু 🔖 ও হাইপার লিংক মেনু 📝👆 যুক্ত ..
আমাদের সবার জন্য খুব খুব গুরুত্বপূর্ণ একটি বই ..বিসিএস, ব্যাংক, ইউনিভার্সিটি ভর্তি ও যে কোন প্রতিযোগিতা মূলক পরীক্ষার জন্য এর খুব ইম্পরট্যান্ট একটি বিষয় ...তাছাড়া বাংলাদেশের সাম্প্রতিক যে কোন ডাটা বা তথ্য এই বইতে পাবেন ...
তাই একজন নাগরিক হিসাবে এই তথ্য গুলো আপনার জানা প্রয়োজন ...।
বিসিএস ও ব্যাংক এর লিখিত পরীক্ষা ...+এছাড়া মাধ্যমিক ও উচ্চমাধ্যমিকের স্টুডেন্টদের জন্য অনেক কাজে আসবে ...
A workshop hosted by the South African Journal of Science aimed at postgraduate students and early career researchers with little or no experience in writing and publishing journal articles.
Strategies for Effective Upskilling is a presentation by Chinwendu Peace in a Your Skill Boost Masterclass organisation by the Excellence Foundation for South Sudan on 08th and 09th June 2024 from 1 PM to 3 PM on each day.
How to Fix the Import Error in the Odoo 17Celine George
An import error occurs when a program fails to import a module or library, disrupting its execution. In languages like Python, this issue arises when the specified module cannot be found or accessed, hindering the program's functionality. Resolving import errors is crucial for maintaining smooth software operation and uninterrupted development processes.
How to Manage Your Lost Opportunities in Odoo 17 CRMCeline George
Odoo 17 CRM allows us to track why we lose sales opportunities with "Lost Reasons." This helps analyze our sales process and identify areas for improvement. Here's how to configure lost reasons in Odoo 17 CRM
This slide is special for master students (MIBS & MIFB) in UUM. Also useful for readers who are interested in the topic of contemporary Islamic banking.
Main Java[All of the Base Concepts}.docxadhitya5119
This is part 1 of my Java Learning Journey. This Contains Custom methods, classes, constructors, packages, multithreading , try- catch block, finally block and more.
1. 1
Access control (authorisation) in distributed systems
recall lecture 9 - Introduction to DS: slides 21 to 27
for access control within the overall system architecture:
• as an individual e.g. from home
• within a single administration domain e.g. CL
• using external services from a domain as an individual or group member
• federated domains: inter-domain authorisation
We are concerned with authorisation for service use and/or object access
How is access control policy expressed and enforced?
Access Control
2. 2
Authorisation and authentication
Authorisation is built above authentication (proof of identity – proof that you
are who you say you are – will someone/something vouch for you?).
Within an administration domain, principals are named and registered as
individuals and members of groups.
Principals authenticate in their home domain by means of e.g. passwords.
The aim is to avoid having to have a username/password for every service.
(.... How does one remember them all? ......
....Use the same one for all? No, break one break all .....)
A Single Sign On service is needed.
Authentication is covered in Security courses.
For background reading, slides 29-36 outline some single sign on systems for
cross-domain service use: Raven, Shibboleth, OpenID
Access Control
3. 3
Access control – from first principles
Model: access matrix A ( i, j ) rows represent principals, columns objects
entry ( i, j ) contains the rights principal i has to object j
Implementation: since the matrix is sparse (most entries are null)
1. Using access control lists (ACLs): keep non-null entries of column j with object j
ACL entry = principal name + access rights
optimisation: group name = list of principals
2. Using capabilities: keep non-null entries of row i with principal i
a capability (capability list entry) = object name + access rights
Assume managers for the various types of object
On an access request, the manager must check that the requesting principal
has the appropriate right to access the object
1. check that the ACL list contains an entry for that principal with the right
2. check that the capability passed by the principal with the request contains the right
Access Control
4. 4
ACLs – cf. - capabilities
ACLs
Expressiveness: subtle expression of policy – entries may be for individual principals
and groups with individual exceptions.
Revocation: easy to revoke – but ACL changes may not have immediate effect
(because the ACL may not be checked on every access once an object is open)
BUT: slow to check - scalability problem
- if expressiveness exploited e.g. negatives and exceptions allowed
- if there are many principals and large groups
- generalisation? multi-domain operation? names outside domain of registration?
AND: awkward to delegate rights e.g. For a file to a printer for a single print job
In a distributed system many services are not part of privileged OSs.
Capabilities
Quick to check – like a ticket – so scale well
Anonymous – knowledge of names not needed – may generalise to multiple domains.
- anonymity may be wanted by some applications for privacy reasons
Problems/issues ... because they are associated with the process rather than the object ...
Access Control
5. 5
Capability-based access control - issues
as defined so far, a capability is an object name and some rights
1. protection
must prevent unauthorised creation, tampering, theft
2. control of propagation
can principals pass on copies?
must they ask the object manager? How can this be enforced?
3. delegation
is an example of propagation
often with restricted rights for a limited time or action
4. revocation
- if the access control policy changes, and certain principals should lose their rights,
their capabilities should ideally be revoked. Can this be done without revoking all
capabilities for the service/object?
- if a capability is known to have been stolen or tampered with it should be revoked
instantly. Will this invalidate all capabilities for this service/object?
Anonymity has created revocation problems.
Access Control
6. 6
Capabilities in centralised and distributed systems
centralised
Several capability architectures were designed and built e.g. Plessey PP250, CAP
Capabilities can be protected by the hardware and/or the OS
A capability is named via an index into a segment or an OS table.
- held in protected OS space per process
- held in typed capability segments in user space with operations such as
insert, delete, use-as-argument
distributed
Can’t be protected by hardware/OS
Have to be transferred across networks and pass through user space
so must be encryption-protected
Security terminology and implementation:
capability = signed certificate
e.g. X.509 authentication and attribute certificates
Access Control
7. 7
Capabilities in distributed systems - design
Must be protected by encryption
The object manager (certificate issuer) keeps a SECRET (random number, private
key) and uses a well-known function f, a one-way function.
A capability is constructed using
check digits = f ( SECRET, protected fields )
When a capability is presented with an operation invocation, the manager checks that:
f ( SECRET, protected fields ) = check digits
If not, the invocation is rejected.
More generally, the invoked service may not be the capability issuer. The service can
check back with the issuer (cf. Certification Authority )
protected fields check digits (signature)
Access Control
8. 8
Encryption-protected capabilities – issues?
1. protection
protect against tampering – adding rights,
NOT against theft – eavesdropping on the network and replay attacks
2. control of propagation
still no control over propagation
3. delegation
object manager must be asked to create a capability with reduced rights to pass to
another principal for delegated authority.
Works indefinitely – duration is not controlled – nor further transfer
4. revocation
(recall: needed when access control policy changes as well as for stolen capabilities)
- expiry time as a protected field (like X.509) – crude mechanism
- hot list of invalid invoking principals per service/object (spoofing? check overhead?)
- change the SECRET – not selective – all old capabilities will not work and
authorised principals will have to request new capabilities.
Access Control
9. 9
Principal-specific capabilities
include the name of the principal in the capability for generation and checking as an
argument to f, perhaps as a protected field in the capability.
1. protection
from tampering – YES, from theft – YES: authenticate presenting principal
2. control of propagation
YES – a capability for the receiving principal can only be created by the object manager
3. delegation
YES – a capability for the receiving principal must be created by the object manager
4. revocation
can be more selective – still involves overhead of checking hot list
e.g. revocation list of principals excluded by policy change
stolen capabilities should be detected on authenticating the presenting principal
unless the presenter is successfully masquerading as the owner.
All the above raise the question of the structure and scope of principal names and how and
where principals are authenticated.
Access Control
10. 10
ACLs in distributed systems
We first followed the capability thread after slide 11.
We have discussed principal-specific capabilities
Now, return to consider ACLs.
ACLs comprise lists of principals (or groups)
ACL entry = principal (or group) name, rights (from slide 3)
Where principals and groups are defined and registered within some administration domain.
Without group names ACLs may become unmanageable, long lists of principals.
Within the administration domain where a group and its constituent principals are
registered, a group name can be expanded into a list of principals, for checking.
How can group names be used outside the domain where the group is registered?
We generalise groups to roles and consider role-based access control (RBAC)
Access Control
11. 11
Role-based access control (RBAC)
Services may classify their clients into named roles e.g.
login service: logged-in-user (after authentication)
patient monitoring service: surgeon, doctor, nurse, patient
online exam service: candidate, examiner, chief examiner
digital library service: reader, librarian, administrator
Access rights (privileges) are assigned to roles for use of services
(method invocation) or more fine-grained access to individual objects or
broad categories of object managed by a service
Scope of role names may be the local domain of the service, or some role
names may be organisation-wide, across federated domains
e.g. sales-manager used in all branches of a world-wide company
police-sergeant used in all of the 52 UK county police forces
NHS-doctor used throughout the UK NHS
Access Control
12. 12
RBAC - 2
Administration: note the separation:
principals –> roles, roles –> privileges
Service developers need only specify authorisation in terms of roles,
independently of the administration of principals
e.g. annual student cohort, staff leaving and joining
Principals are authenticated, as always, and must also prove their right to
acquire/activate a role. They thus prove they are authorised to use a service
Compare with ACLs – like ACLs containing only group names.
Compare with capabilities – can a capability that proves role membership
be engineered?
RBAC seems promising for fast authorisation checking.
Access Control
13. 13
RBAC – 3: Parametrised roles
Roles may be parametrised for fine-grained access control to capture:
- relationships between principals:
Policy: “only the doctor treating a patient may access the medical record”
e.g. treating-doctor ( hospital-ID, doctor-ID, patient-ID )
- patients and others may express exclusions as authorisation policy
e.g. doctor (doctor-ID)
Policy: “where doctor is not Shipman”, “where doctor is not <x> (a relative)”
Compare with ACLs containing only groups, with exclusions of individual members
– semantics of precedence of evaluation in ACLs has always been a difficult area.
Access Control
14. 14
RBAC – 4: Role hierarchies
Some RBAC systems define role hierarchies with privilege inheritance up the hierarchy.
The hierarchy may mirror organisational structure, which reflects power and responsibility
rather than functional competence.
Privilege inheritance is even less defensible for functional roles.
Also: privilege inheritance violates the principle of minimum necessary privilege
and makes reasoning about privileges difficult
– see many ACM SACMAT papers)
Role hierarchies are defined in the later NIST RBAC standards.
Our work has avoided privilege inheritance (see OASIS case study).
Access Control
15. 15
RBAC – 5: Inter-domain authorisation
RBAC eases authorisation outside principals’ home domains, because:
• Roles change less frequently than principals leave and join them
• Administration of users and role membership is separate from service
development and use.
• Negotiation on use of services external to domains can be in terms of
roles, e.g. payment for a role to use a service
• Federated domains may contain agreed role names in each domain.
Makes policy easier to negotiate and express.
e.g. sales-department-staff, sales-manager, salesman
Access Control
16. 16
RBAC – 6: Authorisation context
Authorisation policy could include other constraints on use of a role
e.g. time of day, as well as relationships and exclusions.
see OASIS case study – environmental constraints
The privileges associated with a role might not be static.
e.g. student ( course-ID, student-ID) may read solutions to exercises
only after marked work has been returned.
e.g. Conference management system – a small-scale example follows
of use of an external service from a number of domains.
Access Control
17. 17
Example: conference management (e.g. Easychair, CMT, EDAS, ... )
selection from workflow and policy
Program chair registers names, email addresses, initial password, and roles of the
programme committee: roles PC-chair(s), PC-member
all are sent an email asking them to register their account, change their password
Authors submit papers, acquiring role contact-author, returned a UID for the paper
contact-author may submit new versions up to the deadline
PC-members are assigned papers to review. They may delegate some reviews:
role reviewer per paper, separate from PC-member
Conflicts of interest must be expressed by submitting-authors and PC members, and
enforced by the system
PC members must never be able to know the reviewers and see the reviews of their own
papers
PC members can see only their own reviews until after the review deadline.
After this, in a discussion phase, PC members may be able to see the ranked order and
other reviews (except for their own papers). Systems vary in this respect.
Note: small scale example e.g. 50 PC members, 200 papers
Note: rights will change after deadlines (an example of context)
Access Control
18. 18
Design of capabilities/certificates can incorporate RBAC
Traditional capabilities in centralised systems:
Capabilities/certificates in distributed systems
check digits = f ( SECRET, protected fields )
protected fields check digits
(object-ID, rights) (signature)
role parameters
object-ID rights proves the presenter has the rights to the object
RBAC
proves the presenter holds the role + parameters
must be checked against access control policy
RBAC in distributed systems
check digits = f ( SECRET, protected fields )
protected fields check digits
(role, parameters) (signature)
Access Control
19. 19
RBAC - discussion
RBAC provides:
1. Expressiveness
- subtle expression of access control policy.
- if roles are parametrised, exclusions and relationships can be captured.
- environmental/context checks (time/place) can also be included.
2. Efficiency
- checking faster than ACLs
- use of certificate technology comparable with capabilities
- or use a secure channel and role authentication in source domain
3 Cross-domain interworking
- easy to negotiate
- authorisation policy expressible and enforceable
- heterogeneity of certificates – can check back with issuing domain
Access Control
20. 20
OASIS RBAC
Open Architecture for Securely Interworking Services
Case study from Opera Group research
• OASIS services name their clients in terms of roles
• OASIS services specify policy in terms of roles
- for role entry (activation)
- for service invocation (authorisation, access control)
both in Horn clause form
see: www.cl.cam.ac.uk/Research/SRG/opera
for people, projects, publications for download
Access Control
21. 21
OASIS model of role activation
a role activation rule is of the form:
condition1, condition2, ….. |- target role
where the conditions can be
- prerequisite role
- appointment credential
- environmental constraint
all are parametrised
Access Control
22. 22
OASIS (continued) membership rules
as we have seen, a role activation rule:
cond1*, cond2, cond3*, ….. |- target role
role membership rule:
the role activation conditions that must remain true, e.g.*
for the principal to remain active in the role
monitored using event-based middleware
another contributor to an active security environment
Access Control
23. 23
OASIS model of authorisation
An authorisation rule is of the form:
condition1, condition2, ….. |- access
where the conditions can be
- an active role
- an environmental constraint
all are parametrised
Access Control
24. 24
access control
policy
A Service Secured by OASIS Access Control
principal role
entry policy
OASIS
-secured
service
credential records
(active roles’ status)
RMC = role membership certificate
= role entry
= use of service
credentials
RMC
RMC
Check persistent credentials and
environmental constraints
Check environmental constraints
monitoring
heartbeats or change events
Access Control
25. 25
OASIS role activation illustrated
service A
CR
RMC
service B
CR
CR
event channels
for revocation
prerequisite roles:
P has RMC issued by A
P has RMC issued by B
appointment certificate:
P has specified appointment
environmental constraints
role parameters checked in DB
time is as specified
---------------------------------
P is issued new RMC by B
RMC for principal P
for service A
RMC
appointment certificate
(persistent)
administrative
database for
domain of
service B
time service
for domain
of service B
RMC
new RMC for
principal P
for service B
role entry policy specification of service B, in Horn clause form
conditions for principal P to activate some role
Access Control
26. 26
Active Security Environment
Monitoring membership rules of active roles
service A
CR
RMC
service B
CR
RMC
service C
CR
RMC
ECR ECR
heartbeats or
status-change
events
RMC = role membership certificate
CR = credential record
ECR = external credential record
a prerequisite role
for service C’s role
a prerequisite role
for service C’s role
Access Control
27. 27
authorisation
Engineering per-domain certificate issuing and authentication
principal
role activation
OASIS
-secured
service
service X
credential records
(status of RMCs)
role activation policy
activate role
invoke service
authorisation
policy
certificate validation
service X
other services
CIA It is not realistic for every service to
manage secrets and issue certificates
The CIA service, for services in its domain:
- keeps the activation polices
- activates roles
- issues and validates certificates
- maintains credential record structures
for active roles
-handles revocation via event channels
The CIA service, for services in other domains:
-validates certificates it has issued
- handles revocation of its certificates
Access Control
28. 28
OASIS philosophy and characteristics
• Distributed architecture, not a single organisation. Incremental deployment
of independently developed services in independent administration
domains.
• RBAC for scalability, parametrised roles for expressiveness of policy
(e.g. exclusion of values, relationships between parameters).
• Policy expression is per service, per domain
• Roles are activated within sessions. Persistent credentials may be required
for role activation.
• Independent designs of RMCs may coexist – service at which RMC is
presented checks back with issuer for RMC validation
• Service (domain) level agreements on use of others’ RMCs
• Anonymity if and when required
• Immediate revocation on an individual basis
• No role hierarchies with inheritance of privileges
Access Control
29. 29
Background on cross-domain authentication
(From slide 2) – here is an outline of some single sign on systems
Raven for use of websites across all the domains of Cambridge University
- common naming of principals (CRSIDs, nested domains)
- authentication is sufficient for authorisation
Shibboleth organisation-centric.
organisation negotiates use by its members of external services
OpenID user-centric
used by many large websites (BBC, Google, MySpace, PayPal, ....)
Access Control
30. 30
Raven
• Aim: avoid proliferation of passwords for UCam web services
– Raven is a Ucam-webauth Single Sign On system instance
– Developed within Cambridge (by Jon Warbrick)
• Three parties in the Ucam_webauth protocol:
– User’s web-browser
– Target web-server
– Raven web-server
• Authentication token passed as an HTTP cookie
– Thus should be passed using HTTPS… but often isn’t
Access Control
31. 31
Example Raven dialogue
• User requests protected page
• Target web-server checks for Ucam-WLS-Session cookie
• If found, and decodes correctly, page is returned. Done.
• Otherwise, redirect client browser to Raven server
– Encodes information about the requested page in the URL
• Raven inputs and checks credentials
– (Also permits users to “cancel”)
• Raven redirects client browser to the protected page. Done.
– (An HTTP 401 error will be generated if users cancelled)
Access Control
32. 32
Raven coordinates participants using time
• Target web-server verifies Ucam-WLS-Session cookie
– Public-key of Raven server pre-loaded on target web-server
• Target web-server and Raven do not interact directly
– Client browser receives, stores and resends cookies
• What about malicious client behaviour or interception?
– e.g. replay attacks?
• Raven requires time-synchronisation
– A site-specific clock-skew margin can be configured
Access Control
33. 33
Shibboleth provides federated authentication
• System for federated authentication and authorisation
– Internet2 middleware group standard
– Implements SAML: Security Assertion Markup Language
– Facilitates single-sign-on across administrative domains
• Raven actually speaks both Ucam-webauth and Shibboleth
– Shibboleth has the advantage of wider software support
• Identity providers (IdPs) supply user information
• Service providers (SPs) consume this information and get access to
secure content
Access Control
34. 34
Shibboleth exchange
• Similar to Raven, but with some extra indirection
– User requests protected resource from SP
– SP crafts authentication request
– User redirected to IdP or ‘Where Are You From’ service
• E.g. UK Federation WAYF service
– User authenticates (external to Shibboleth)
– Shibboleth generates SAML authentication assertion handle
– User redirected to SP
– SP may issue AttributeQuery to IdP’s attribute service
– SP can make access control decision
Access Control
35. 35
OpenID
• Another cross-domain single-sign-on system
• Shibboleth is organisation-centric
– Organisations must agree to accept other organisations’ statements
regarding foreign users
– Lots of support within the UK Joint Information Systems
Committee (JISC) for accessing electronic resources
• OpenID is user-centric
– Primarily about identity
– OpenIDs are permanent URI or XRI structures
Access Control
36. 36
OpenID (cont)
• User provides their ID to relying party web site
– OpenID 1.0 retrieves URL, learns identity provider
– OpenID 2.0 retrieves XRDS, learns identity provider
• XRDS/Yadis indirection affords greater flexibility
• Many big commercial players offer OpenID assertions
• Lots of open source software support for OpenID also
• In terms of responsibility, consider use for:
– Access to a web resource
– Access to a wireless network
Access Control