DOCSLIB.ORG

Introducing a Security Access Control Engine Inside Openldap

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Introducing a Security Access Control Engine Inside Openldap Introducing a Security Access Control Engine Inside OpenLDAP The OpenLDAP RBAC Accelerator November 13, 2015 LDAPCon, Edinburgh Session Objective • Convince you that using an LDAP Server as a security Policy Decision Point (PDP) is a good idea. LDAPCon, Edinburgh 2015 2 Introductions Shawn McKinney • Systems Architect http://events.linuxfoundation.org/events/apachecon-core-europe • PMC Apache Directory Project • Engineering Team LDAPCon, Edinburgh 2015 3 Agenda • Idea & Rationale • Specs & Requirements • Implementation • Standardization • Demo Benchmarks IMAGE FROM: HTTP://EVENTS.LINUXFOUNDATION.ORG/EVENTS/APACHECON-NORTH-AMERICA LDAPCon, Edinburgh 2015 4 Hit a Wall with Policy Enforcement Need a Policy Decision Point implementation for every platform. We wanted one of these that runs natively… and had to build a PDP as well. OpenLDAP LM LDAPCon, Edinburgh 2015 5 Started With An Idea • Proposed by Ted Cheng in 2012 • Move the PDP into the LDAP server • Utilize the natural strengths of LDAP protocol Image from: http://www.clker.com/clipart-6937.html • Simpler client-side bindings OpenLDAP LM 6 Rationale Because I haven’t convinced you yet. LDAPCon, Edinburgh 2015 7 But First A quick lesson on how we integrate security systems into applications… LDAPCon, Edinburgh 2015 8 Access Control System Composition 1. Policy Enforcement Point (PEP) 2. Policy Decision Point (PDP) 3. Database (DB) LDAPCon, Edinburgh 2015 9 Policy Enforcement Point • Invoked by the apps for security checks. • TheThe SecuritySecurity System’sSystem’s Gatekeeper.Gatekeeper. • Requires platform specific bindings. • Best to reduce impact to the host machine. LDAPCon, Edinburgh 2015 10 Database • Invoked by PDPs to store security stuff. • TheThe SecuritySecurity System’sSystem’s LongLong--termterm Memory.Memory. • Must be reliable, consistent and fast. LDAPCon, Edinburgh 2015 11 Policy Decision Point • Invoked by PEP and dependent on the DB. • TheThe SecuritySecurity System’sSystem’s Brain.Brain. • Authenticates with passwords and keys. • Authorizes using attributes and permissions. • Audit trail. LDAPCon, Edinburgh 2015 12 Three Composition Types • Type 1 – PDP runs in-process to PEP, with out- of-process DB • Type 2 – PDP runs out-of-process to PEP, with out-of-process DB • Type 3 – PDP runs out-of-process to PEP, with in-process DB LDAPCon, Edinburgh 2015 13 Type 1 Process Communication • PEP and PDP on one tier • DB on another LDAPCon, Edinburgh 2015 14 More on Type 1 Composition • The PEP and PDP run in-process and the DB is out-of- process. • Policy decisions occur synchronously inside the client process. • Combines the PEP and PDP into a single component. • Most open-source security frameworks are this type. – Tomcat JDBC Realm – Apache Fortress – Spring Security – Apache Shiro LDAPCon, Edinburgh 2015 15 Pros/Cons of Type 1 Advantages Disadvantages • Simple – only security • More code exposed to the framework and DB required client (making deployment • Widely available harder) • Works well for single • More load on the client deployments of stand-alone • More memory consumed apps on the client • Many options for database • More network io traffic on usage. the client • Fewer platforms supported LDAPCon, Edinburgh 2015 16 Type 2 Process Communication • All on separate tiers LDAPCon, Edinburgh 2015 17 More on Type 2 Composition • The PEP, PDP and DB all run out-of-process from one another. • More complex than a Type 1 PDP. • Obtained as separate COTS – CA Siteminder, Tivoli Access Manager, Oracle Access Manager • Or OSS products: – OpenAM, Shibboleth, and CAS LDAPCon, Edinburgh 2015 18 Pros/Cons of Type 2 Advantages Disadvantages • Less network traffic on client • More security processes to maintain due to PEP, PDP and DB • Less cpu consumed on client all running separately (increasing • Less memory consumed on management burden) client • Poor response time due to extra network hops • Less code exposed to client • Poor throughput due to PDP (making deployment simpler) reliance on heavyweight • More platforms supported communication protocols xml/json over http. LDAPCon, Edinburgh 2015 19 Type 3 Process Communication • PEP on one tier • PDP and DB on another LDAPCon, Edinburgh 2015 20 More on Type 3 Composition • The PDP and DB run in-process and the PEP is out-of-process. • Not widely available today. LDAPCon, Edinburgh 2015 21 Pros/Cons of Type 3 Advantages Disadvantages • All of Type 2’s • Fewer options for database • Embedded database speed usage gain • Poor throughput due to • Embedded database reliance on heavyweight reliability gain communication protocols xml/json over http. LDAPCon, Edinburgh 2015 22 Benefits of the LDAPv3 Protocol • Compact and efficient wire protocol (fast) • Supports robust replication and high availability requirements (safe) • Rich data model (good) • Relatively easy to code (cheap) LDAPCon, Edinburgh 2015 23 Pros/Cons of Type 3 using LDAP Advantages Disadvantages • All of Type 3’s • Less options for database • Less i/o traffic due to LDAP’s usage BER protocol. • Poor throughput due to reliance on heavyweight communication protocols (xml/json/http) LDAPCon, Edinburgh 2015 24 Specs & Requirements Because you’re still not convinced. Image from: http://www.cockpitseeker.com/aircraft/ LDAPCon, Edinburgh 2015 25 High-Level System Requirements • Security - Access control checking that is platform independent. • Authentication – Had to work with various SSO protocols, i.e. SAML, OpenID Connect • Authorization – Must be standards-based. • Administration – Not needed (covered by Apache Fortress) • Audit - Record of system ops inside persistent data store. • Service-based SLA - Maintain service level agreements for security, performance, and reliability. LDAPCon, Edinburgh 2015 26 Access Control Requirements • Policy Database that can be centralized and federated • Fine-grained permissions • Common functional and object models LDAPCon, Edinburgh 2015 27 Other Key Requirements • Centralized Audit Trail and Reporting API • Password Policy Control • Lockout Procedures based on Time & Date • Session persistence and replication LDAPCon, Edinburgh 2015 28 Audit • System • Principal Identity Compliance • Date Assurance • Resource • Resource Identity • Operation Objectivity • Result LDAPCon, Edinburgh 2015 29 Password Policies 1. A configurable limit on failed authentication attempts. 2. A counter to track the number of failed authentication attempts. 3. A time frame in which the limit of consecutive failed authentication attempts. 4. The action to be taken when the limit is reached. 5. An amount of time the account is locked (if it is to be locked) 6. Password expiration. 7. Expiration warning 8. Grace authentications 9. Password history 10. Password minimum age 11. Password minimum length 12. Password Change after Reset 13. Safe Modification of Password https://tools.ietf.org/html/draft-behera-ldap-password-policy-10 LDAPCon, Edinburgh 2015 30 Temporal Constraints Applies to User and Role • Time of Day activations • Day of Week • Begin and End Date • Lockout Periods 31 Persistent or Transient Session? Each has its own benefits… Transient Persistent 1. Less processing on server 1. Less data to transfer over 2. Less data stored wire 3. More flexibility in terms of 2. Less processing on client attributes managed 3. Supports session timeout and concurrency controls LDAPCon, Edinburgh 2015 32 Non-Functional Requirements • Fault Tolerant Business • Highly Available Requirements • Multitenant • Full Audit Trail User Requirements • Highly Performant System Requirements LDAPCon, Edinburgh 2015 33 Non-Functional Requirements • Optimized for Performance • Low latency – < 1ms • High throughput – > 100,000 TPS http://americandigest.org/sidelines/2010/04/flying_the_blac.html LDAPCon, Edinburgh 2015 34 Specifications LDAPCon, Edinburgh 2015 35 Why Use Functional Specifications? • Saves the trouble (and risk) of deciding ‘what’ to do. • Instead we get to focus on ‘how’ to do it. • Difference between being handed a blank sheet of paper or a coloring book. LDAPCon, Edinburgh 2015 36 Which Functional Specifications • Protocols Must Be Standards-Based: – Role-Based Access Control (RBAC) - ANSI INCITS 359 – Attribute-Based Access Control (ABAC) – Use INCITS 494 Instead? – IETF Password Policies (Draft) – Must cooperate with others like OAuth2, SAML 2.0, OpenID Connect, UMA, etc. LDAPCon, Edinburgh 2015 37 Role-Based Access Control (RBAC) LDAPCon, Edinburgh 2015 38 Role-Based Access Control (RBAC) • RBAC0RBAC0 --– Users,Users, Roles, Roles, Perms, Perms, Sessions Sessions Support this one • RBAC1 – Hierarchical Roles • RBAC2 – Static Separation of Duties (SSD) • RBAC3 – Dynamic Separation of Duties (DSD) ANSI INCITS 359 http://csrc.nist.gov/groups/SNS/rbac/ LDAPCon, Edinburgh 2015 39 ANSI RBAC Functional Model Three standard interfaces: 1. Administrative – CRUD 2. Review – policy interrogation Implement 3. SystemSystem –– policypolicy enforcementenforcement this one LDAPCon, Edinburgh 2015 40 System RBAC Interface public interface AccelMgr { Link to AccelMgr javadoc Session createSession( User user, boolean isTrusted ); List<Permission> sessionPermissions( Session session ); List<UserRole> sessionRoles( Session session ); void addActiveRole( Session session, UserRole role ); Fortress AccelMgr void dropActiveRole( Session session, UserRole role ); User getUser( Session session ); APIs map to the boolean checkAccess( Session session, Permission perm); INCITS 359 specs } http://git-wip-us.apache.org/repos/asf/directory-fortress-core.git Link to INCITS 359 spec
Load more

Recommended publications
  • Apache Directory Studio™
    Main | ApacheDS | Studio | LDAP API | Mavibot | eSCIMo | Fortress | Kerby Apache Directory Studio Apache Directory Studio™ Home News The Eclipse-based LDAP browser and directory client Screenshots Apache Directory Studio is a complete directory tooling platform Downloads intended to be used with any LDAP server however it is particularly Version 2.0.0-M10 designed for use with ApacheDS. It is an Eclipse RCP application, Older Versions composed of several Eclipse (OSGi) plugins, that can be easily upgraded with additional ones. These plugins can even run within Documentation Eclipse itself. User's Guide Developer's Guide Download Apache FAQs Directory Studio 2.0.0-M10 Resources ChangeLog Testimonials LDAP Browser LDIF Editor Support Mailing Lists & IRC The LDAP Browser has been designed to work with almost any The LDIF Editor is a tool for editing LDIF files. It provides syntax Sources LDAP server available. It not only permits to read and display the highlighting and content assistance. Issue Tracking tree of your LDAP Server but also allows you to modify it by creating, editing or removing entries. Commercial Support Community How to Contribute Schema Editor Embedded ApacheDS Team The Schema Editor has been designed to edit the schema files Apache Directory Studio bundles the latest version of the Original Project Proposal in the OpenLDAP format. It allows you to edit easily attribute LDAPV3 certified ApacheDS. Creating and launching a new Special Thanks types and object classes for Apache Directory Server and LDAP server now takes less than 10 seconds! OpenLDAP. About Apache Apache License ApacheDS Configuration ACI Editor Sponsorship Thanks The ApacheDS Configuration Editor can be used to edit the The ACI Editor allows you to define, for an entry or a set of Security server configuration ('server.xml' and 'config.ldif' files) of an entries, graphically or manually (in souce code mode), an ACI Apache Directory Server installation.
    [Show full text]
  • The Anatomy of a Secure Web Application Using Java EE, Spring Security and Apache Fortress
    The Anatomy of a Secure Web App Using JavaEE, Spring Security and Apache Fortress May 18, 2017 ApacheCon NA, Miami Objective • Think about how a web app would behave, if we spared no expense for security. ApacheCon NA, Miami 2017 2 Introductions @play Shawn McKinney @work • Software Architect • PMC Apache Directory Project • Engineering Team ApacheCon NA, Miami 2017 3 Agenda Look at two examples… 1. Apache Fortress Demo + Java EE + Spring Security – https://github.com/shawnmckinney/apache-fortress-demo 2. Fortress SAML Demo + Spring Security SP – https://github.com/shawnmckinney/fortress-saml-demo ApacheCon NA, Miami 2017 4 Themes Covered 1. Simplicity 2. Common Sense 3. Household Analogies to explain ‘Why’ ApacheCon NA, Miami 2017 5 With a few caveats… • Not cloud native • Not microservices • Not big data Not a problem, same rules apply ApacheCon NA, Miami 2017 6 And a couple of recommendations • Listen, don’t take notes. These slides are published and have all the details you need. • Save questions for the end (we’ve got a lot of ground to cover). ApacheCon NA, Miami 2017 7 Example #1 Apache Fortress Demo https://github.com/shawnmckinney/apache-fortress-demo ApacheCon NA, Miami 2017 8 The Five Security Layers of Java Web Apps 1.Java Secure Socket Extension (JSSE) 2.Java EE Security 3.Spring Security 4.Web App Framework 5.Database Functions ApacheCon NA, Miami 2017 9 Rationale for Each 1.JSSE ---------------------------- private conversations 2.Java EE Security ---------- deadbolt on front door 3.Spring Security ------------ locks on room doors 4.Web App Framework - locks on equipment in rooms 5.Database Functions ---- content filtering ApacheCon NA, Miami 2017 10 Two Areas of Access Control 1.Java EE and Spring Role Declarative checks 2.RBAC Permission Programmatic checks ApacheCon NA, Miami 2017 11 Start with Tomcat Servlet Container ApacheCon NA, Miami 2017 12 1 & 2.
    [Show full text]
  • Security Pattern Validation and Recognition
    Security-Pattern Recognition and Validation Dissertation Submitted by Michaela Bunke on 12th December 2018 to the Universit¨atBremen Faculty of Mathematics and Computer Science in partial fulfillment of the requirements for the degree of Doktor der Ingenieurwissenschaften { Dr.-Ing. { Reviewed by Prof. Dr. Hans-J¨orgKreowski Universit¨atBremen, Germany and Dr. Karsten Sohr Universit¨atBremen, Germany In Memorial of Ilse Schlamilch Karl Schlamilch Manfred Friedrichs 21 November 1924 03 March 1927 29 August 1935 09 June 2017 19 June 2018 3 July 2017 ABSTRACT The increasing and diverse number of technologies that are connected to the Internet, such as distributed enterprise systems or small electronic devices like smartphones, brings the topic IT security to the foreground. We interact daily with these technologies and spend much trust on a well-established software development process. However, security vulnerabilities appear in software on all kinds of PC(- like) platforms, and more and more vulnerabilities are published, which compromise systems and their users. Thus, software has also to be modified due to changing requirements, bugs, and security flaws and software engineers must more and more face security issues during the software design; especially maintenance programmers must deal with such use cases after a software has been released. In the domain of software development, design patterns have been proposed as the best-known solutions for recurring problems in software design. Analogously, security patterns are best practices aiming at ensuring security. This thesis develops a deeper understanding of the nature of security patterns. It focuses on their validation and detection regarding the support of reviews and maintenance activities.
    [Show full text]
  • Code Smell Prediction Employing Machine Learning Meets Emerging Java Language Constructs"
    Appendix to the paper "Code smell prediction employing machine learning meets emerging Java language constructs" Hanna Grodzicka, Michał Kawa, Zofia Łakomiak, Arkadiusz Ziobrowski, Lech Madeyski (B) The Appendix includes two tables containing the dataset used in the paper "Code smell prediction employing machine learning meets emerging Java lan- guage constructs". The first table contains information about 792 projects selected for R package reproducer [Madeyski and Kitchenham(2019)]. Projects were the base dataset for cre- ating the dataset used in the study (Table I). The second table contains information about 281 projects filtered by Java version from build tool Maven (Table II) which were directly used in the paper. TABLE I: Base projects used to create the new dataset # Orgasation Project name GitHub link Commit hash Build tool Java version 1 adobe aem-core-wcm- www.github.com/adobe/ 1d1f1d70844c9e07cd694f028e87f85d926aba94 other or lack of unknown components aem-core-wcm-components 2 adobe S3Mock www.github.com/adobe/ 5aa299c2b6d0f0fd00f8d03fda560502270afb82 MAVEN 8 S3Mock 3 alexa alexa-skills- www.github.com/alexa/ bf1e9ccc50d1f3f8408f887f70197ee288fd4bd9 MAVEN 8 kit-sdk-for- alexa-skills-kit-sdk- java for-java 4 alibaba ARouter www.github.com/alibaba/ 93b328569bbdbf75e4aa87f0ecf48c69600591b2 GRADLE unknown ARouter 5 alibaba atlas www.github.com/alibaba/ e8c7b3f1ff14b2a1df64321c6992b796cae7d732 GRADLE unknown atlas 6 alibaba canal www.github.com/alibaba/ 08167c95c767fd3c9879584c0230820a8476a7a7 MAVEN 7 canal 7 alibaba cobar www.github.com/alibaba/
    [Show full text]
  • Open Source Web Content Management in Java
    Open Source Web Content Management in Java Release 1.0 February 2008 Open Source Web Content Management Options in Java Seth Gottlieb Version 1.0, Workgroup License Copyright © 2007 Content Here, Inc. License Agreement and Disclaimer Workgroup License This report is licensed under a "Workgroup License" that allows your company to make this report available to up to ten (10) staff members. It may not be shared with customers or copied, reproduced, altered, or re-transmitted in any form or by any means without prior written consent. Any rankings or scoring information may not be used in promotional materials. Disclaimer This report is intended to be an overview of the technologies described and not a recommendation or endorsement of a specific platform or technology strategy. The most appropriate platform for your use depends on the unique requirements, legacy architecture, and technical capabilities of your organization. Content Here, Inc., cannot ensure the accuracy of this information since projects, vendors, and market conditions change rapidly. Content Here, Inc., disclaims all warranties as to the accuracy or completeness of the information in this report and shall have no liability for errors, omissions, or inadequacies in the information presented. All Rights Reserved. Not for Redistribution. Copyright 2007 Content Here, Inc. Version 1.0, Workgroup License Page 2 All Rights Reserved. Not for Redistribution. Copyright 2007 Content Here, Inc. Version 1.0, Workgroup License Page 3 All Rights Reserved. Not for Redistribution. Acknowledgements Thanks to the following people for reviewing sections of this report for accuracy • Elie Auvray (Jahia) • Kevin Cochrane (Alfresco) • Arjé Cahn • Alexander Kandzior (OpenCms) • Boris Kraft (Magnolia) • Steven Noels (Daisy) Jennifer Gottlieb provided copyedit services and general encouragement to help me complete this report.
    [Show full text]
  • RBAC-Enable Your Java Web Applications with Apache Directory
    RBAC-Enable Your Java Web Applications with How I Built an IAM System using Java and Apache Directory Fortress Shawn McKinney October 29, 2015 JavaOne San Francisco Session Objectives Learn about: Identity and Access Management Specifications (What) System Design Considerations (How) Apache Directory Fortress (Why) JavaOne, San Francisco 2015 2 Introductions Shawn McKinney • Systems Architect http://events.linuxfoundation.org/events/apachecon-core-europe • PMC Apache Directory Project • Engineering Team JavaOne, San Francisco 2015 3 Session Agenda • Examine Specs & Requirements for IAM • Examine Designs for an IAM System • Intro to Apache Fortress – Project Details – Components – Future Image from: HTTP://EVENTS.LINUXFOUNDATION.ORG/EVENTS/APACHECON-NORTH-AMERICA JavaOne, San Francisco 2015 4 Cut to the Chase The recipe for any successful technology project: Mix well: • Well defined set of functional specifications • Understanding of the non-functional requirements • Common elements from the platform • Accepted development practices JavaOne, San Francisco 2015 5 Specs & Requirements What do we Build? Image from: http://www.cockpitseeker.com/aircraft/ JavaOne, San Francisco 2015 6 High-Level System Requirements • Security - Access control checking inside common containers like JavaEE and Spring. • Authentication - May use both simple and complex protocols. • Authorization - Use standards-based access control methodologies. • Administration - Policy usage is managed by delegation policies. • Audit - Record of operations inside persistent data store. • Service-based SLA - Maintain service level agreements for security, performance, and reliability. JavaOne, San Francisco 2015 7 Why Use Functional Specifications? • Saves the trouble (and risk) of deciding ‘what’ to do. • Instead we get to focus on ‘how’ to do it. • Difference between being handed a blank sheet of paper or a coloring book.
    [Show full text]
  • RBAC Enable Your Java Web Apps Using Apache Directory and Fortress
    RBAC Enable Your Java Web Apps Using Apache Directory and Fortress Shawn McKinney – SYMAS Corporation April 15, 2015 Introduction • Systems Architect @ • Committer @ OpenLDAP & Apache Directory Projects Agenda I. Project Overview II. Components III. Standards IV. Future V. Demo VI.Benchmarks VII.Wrap-up I. Project Overview Project Description ● High Performance Identity and Access Management • Permission-based Access Control Model (RBAC) • Four Components: • Core • Realm • Web • Rest Project Features • Highly Performant • ANSI INCITS 359 • Multitenant data and object model • Audit Trail (OpenLDAP only) • LDAPv3 Portable Project History ● Core & Realm released in '11 to OpenLDAP Project • Rest component in '12 to OpenLDAP • Web component in '13 to OpenLDAP • Moved all to Apache Directory project in '14 Project History 22 Releases http://mvnrepository.com/artifact/us.joshuatreesoftware http://mvnrepository.com/artifact/org.openldap Project History Downloads II. Components Inventory of Components ● Accelerator – LDAPv3 Extended accelerator 9 k ● Core – APIs core 74 k ● Realm – Policy Enforcement realm 2 k ● Web – HTML Server web rest 18 k 5 k ● Rest – XML Server 108 k SLOC Fortress Core • Identity and Access Management SDK • Communicates LDAPv3 protocol but has switch for REST • Extensive Tests (one-to-one) https://git-wip-us.apache.org/repos/asf/directory-fortress-core.git Fortress Core Depends On • Mostly other Apache components like • Commons • CXF • Directory • With some help from • Javax • Jgrapht • ehcache Core System Architecture J
    [Show full text]
  • Configuring Apache Fortress-Openldap for High Availability by Shawn Mckinney (Contributions by Emmanuel Lecharny) | Dec 1, 2018 | Fortress, Openldap
    Configuring Apache Fortress-OpenLDAP for High Availability by Shawn McKinney (contributions by Emmanuel Lecharny) | Dec 1, 2018 | Fortress, OpenLDAP This document describes how Apache Fortress and OpenLDAP can be placed into a highly-available configuration. Apache Fortress provides Identity and Access Management APIs over HTTP using either JSON or REST formats. OpenLDAP is where the data is stored and maintained. There are two identically configured machines, each with an instance of Fortress (Java) and OpenLDAP (native) processes running on it. A Virtual IP address will be used to route traffic to the designated primary node. In the event of a failure on the primary, the routing will be to the other. What’s a Virtual IP Address From Wikipedia, the free encyclopedia A virtual IP address (VIP or VIPA) is an IP address that doesn’t correspond to an actual physical network interface. Uses for VIPs include network address translation (especially, one-to-many NAT), fault-tolerance, and mobility. Not Load-balanced All traffic to either Fortress or OpenLDAP gets routed to a single machine. The virtual IP determines which of the two identically configured machines is active and which is standby. In the event of failure on the primary node, the Virtual IP is then pointed to the secondary. Advantages Simple to understand, automate/setup, maintain and use. Efficiency: No additional network hops (through a load-balancer) are required for round trips. Reliability: No risk of a ‘split-brain’ occurrence, when one node falls out of synch of the other, i.e. differing views on the data / inconsistent results.
    [Show full text]
  • The Anatomy of a Secure Java Web App Using Apache Fortress
    The Anatomy of a Secure Java Web App Using Apache Fortress March 10, 2019 SCaLE 17X, Pasadena Objective Think about how we should be securing web apps. (If we pulled out all stops) SCaLE 17X, Pasadena 2019 2 Intro • Software Architect https://github.com/shawnmckinney • Apache Directory PMC Chair • Engineering Team Agenda 1. Discuss recent security breaches and vulnerability scanning. 2. Talk about Principle of Least Privilege 3. Look at Remote Code Execution Vulnerability 4. Talk about Defense in Depth 5. Look at Apache Fortress Demo and RBAC 6. “ Fortress ABAC Demo 7. Wrap-up SCaLE 17X, Pasadena 2019 4 Recommendation Listen and absorb conceptually. Slides are published and have the details. https://iamfortress.files.wordpress.com/2018/09/ anatomy-secure-web-app-scale17x-2019- v1.pdf SCaLE 17X, Pasadena 2019 5 There are 2 types of companies: those that have been hacked and those who don’t know they have been hacked. -- John T. Chambers former CEO Cisco Systems 6 It's not a network as much as an ocean. Not a tier, machine or container but islands separated by miles of hostile waters. All must be attended to and defended, each with unique challenges. 7 Problem Statement Make our systems more resilient to cyber attack via the application of a few common security principles. SCaLE 17X, Pasadena 2019 8 Disclosed Breaches in 2018 – Aadhaar, 1.1B – Exactis, 340M – Under Armour, 150M – MyHeritage, 92M – Facebook, 87M SCaLE 17X, Pasadena 2019 9 For Example • Equifax disclosed a breach in Sep ‘17 – 148 million consumers in the U.S., U.K.
    [Show full text]
  • RBAC Authorization with Apache Directory Server and Fortress
    RBAC Authorization With Apache Directory Server And Fortress Shawn McKinney Emmanuel Lécharny Introducing Fortress ● Accepted as a Directory sub-project in october 2014. ● IP clearance on its way ● Code injection in Git repository last week ● ~90 000 SLOCs Introducing Fortress RBAC Access Control & Management Apps ● Core - Software Development Kit ● Realm - Policy Enforcement Plug-in for Java EE Apps & Servers ● Web - Administrative GUI for Management of Policies ● REST - XML/HTTP Policy Server Fortress Features ● ANSI Role-Based Access Control ● ARBAC02 Model Delegated Administration ● IETF Password Policies ● LDAPv3 Interoperability ● Multi-tenant Data and Object Model ● Audit Trail (OpenLDAP only) ● Works with any LDAP V3 compliant server Introducing ApacheDS LDAP & Kerberos Server, and more... ● ApacheDS - LDAP Server ● Studio - Ldap Browser ● LDAP API - A new Java LDAP API ● Mavibot - MVCC btree ● eSCIMo - SCIM 2.O implementation Introducing ApacheDS ● Get accepted in Apache Incubator in 2003 ● Became a TLP in 2005 ● 37 releases since then ● Around 700 000 Slocs ApacheDS Features ● Ldap server in Java ● Kerberos server built-in ● Embeddable ● Password Policy support ● Multi-master replication (RFC 4533) ● X500 authorization ● Multi-platform (Windows, Linux, Mac OSX) Role-Based Access Model Early History ● introduced in 1992 (David Ferraiolo and Richard Kuhn) ● meant to address critical shortcomings of DAC ● integrity was lacking as the requirement for data and process to be modified only in authorized ways by authorized users. Role-Based
    [Show full text]
  • Open Source Og Søketeknologi for Virksomheter Masteroppgave Eivind Hasle Amundsen
    UNIVERSITETET I OSLO Institutt for informatikk Open Source og søketeknologi for virksomheter Masteroppgave Eivind Hasle Amundsen April 2007 2 Innhold 1 Introduksjon 11 1.1Problemstillingogmotivasjon................... 13 1.2Observasjonerogfunn....................... 15 1.3Oppgavensstruktur......................... 16 1.4Problemområdeogomfang.................... 18 1.5Avgrensninger............................ 19 2 Søk i virksomheter 21 2.1Hvaersøk?.............................. 21 2.2Hvaerenvirksomhet?....................... 23 2.3EnterpriseSearch(ES)........................ 24 2.3.1ESiforholdtilwebsøk................... 26 2.3.2ESiforholdtildatabaser.................. 28 2.4Dagensstatus............................. 31 2.5Dataoginformasjon........................ 34 2.5.1Datalagring–enflaskehals................ 36 2.5.2Strukturerteogustrukturertedata........... 37 2.5.3 Dokumenter og innhold . 39 2.5.4Ordningavinformasjon.................. 41 2.5.5Ekstraheringogutvinning................. 43 3 Utfordringer i virksomhetssøk 45 3.1Tilpassingogintegrering...................... 45 3.1.1Eksisterendesystemer................... 46 3.1.2Modularisering........................ 47 3.1.3 Verktøy for styring og brukervennlighet . 49 3.1.4Dokumentformater..................... 50 3.2Presentasjonoggrensesnitt.................... 51 3.2.1Tradisjonellegrensesnitt.................. 51 3.2.2Navigérbaregrensesnitt.................. 53 3.2.3Integrertegrensesnitt.................... 53 3.3Sikkerhet................................ 54 3.3.1Integreringogkompatibilitet..............
    [Show full text]
  • The Use of Java in Large Scientific Applications in HPC Environments
    The use of Java in large scientific applications in HPC environments Aidan Fries ADVERTIMENT. La consulta d’aquesta tesi queda condicionada a l’acceptació de les següents condicions d'ús: La difusió d’aquesta tesi per mitjà del servei TDX (www.tdx.cat) ha estat autoritzada pels titulars dels drets de propietat intel·lectual únicament per a usos privats emmarcats en activitats d’investigació i docència. No s’autoritza la seva reproducció amb finalitats de lucre ni la seva difusió i posada a disposició des d’un lloc aliè al servei TDX. No s’autoritza la presentació del seu contingut en una finestra o marc aliè a TDX (framing). Aquesta reserva de drets afecta tant al resum de presentació de la tesi com als seus continguts. En la utilització o cita de parts de la tesi és obligat indicar el nom de la persona autora. ADVERTENCIA. La consulta de esta tesis queda condicionada a la aceptación de las siguientes condiciones de uso: La difusión de esta tesis por medio del servicio TDR (www.tdx.cat) ha sido autorizada por los titulares de los derechos de propiedad intelectual únicamente para usos privados enmarcados en actividades de investigación y docencia. No se autoriza su reproducción con finalidades de lucro ni su difusión y puesta a disposición desde un sitio ajeno al servicio TDR. No se autoriza la presentación de su contenido en una ventana o marco ajeno a TDR (framing). Esta reserva de derechos afecta tanto al resumen de presentación de la tesis como a sus contenidos. En la utilización o cita de partes de la tesis es obligado indicar el nombre de la persona autora.
    [Show full text]