kuali iam and security n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Kuali IAM and Security PowerPoint Presentation
Download Presentation
Kuali IAM and Security

Loading in 2 Seconds...

play fullscreen
1 / 51

Kuali IAM and Security - PowerPoint PPT Presentation


  • 122 Views
  • Uploaded on

Kuali IAM and Security. Aaron Godert Sr. Software Architect/Engineer Kuali Rice Development Manager Cornell University. Outline. Kuali Overview Kuali Rice Overview Kuali Nervous System (KNS) Security Kuali Enterprise Workflow (KEW) Security Kuali Service Bus (KSB) Security

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Kuali IAM and Security' - sook


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
kuali iam and security

Kuali IAM and Security

Aaron Godert

Sr. Software Architect/Engineer

Kuali Rice Development Manager

Cornell University

outline
Outline
  • Kuali Overview
  • Kuali Rice Overview
  • Kuali Nervous System (KNS) Security
  • Kuali Enterprise Workflow (KEW) Security
  • Kuali Service Bus (KSB) Security
  • Kuali Identity Management (KIM) Security
  • Protecting against vulnerabilities
kuali overview
Kuali Overview
  • Kuali Foundation
  • Community source projects
  • Administrative applications
    • Kuali Finance
    • Kuali Research Administration
    • Kuali Student
    • Kuali Endowment
  • The foundation: Kuali Rice
foundation partners
Foundation Partners
  • Boston University
  • Bradley University
  • Colorado State University
  • Cornell University
  • Florida State University
  • Indiana University
  • Marist College
  • Massachusetts Institute of Technology
  • Michigan State University
  • San Joaquin Delta Community College
  • University of Arizona
  • University of British Columbia
  • University of California-President's Office
  • University of California-Berkeley
  • University of California-Davis
  • University of California-Irvine
  • University of California-Santa Barbara
  • University of Hawaii
  • University of Maryland
  • University of Southern California
the level of contribution
The Level of Contribution
  • Contributing “tendered” developers or money for hiring “tendered” developers
    • 3+ FTEs at 100%
    • Contributing developers are working under the supervision of the Project Manager
    • Virtual reporting
  • Subject Matter Experts provide requirements and functional guidance (20% - 80%)
    • Councils and committees
    • QA functional testing
the scale of kuali
The Scale of Kuali
  • Large scale administrative web applications
  • Millions of LOCs
  • 1000s of business processes and transactions
  • Must support 1000s of simultaneous users
distributed development teams
Distributed Development Teams
  • The systems are broken down into modules
  • Each module has a team
  • Each team is made up of resources from different institutions
    • Balanced view on functionality
    • Changes in institutional commitments won’t jeopardize a whole module
  • Communication is virtual with periodic face-to-faces
  • Weekly code reviews to ensure quality
  • Full QA
the challenge
The Challenge
  • Ensuring consistent development practices around security within a Kuali application and across the suite
  • Consolidating and isolating pieces of the application that deal with IAM and security
  • Make security part of the core
    • 90%/10%
    • We want 90% of the developers focusing on functionality
    • We want to eliminate the potential for introducing security vulnerabilities
project governance our ally for iam and security
Project Governance: Our Ally for IAM and Security
  • Foundation Board of Directors
  • Each project has its own board of directors
  • Each project has its own functional council (lead SMEs)
  • Each project has its development team and reporting structure
  • Kuali Technical Council - one technical governing body
    • Sets technical standards and ensures consistent practices
    • Sets security standards across projects
kuali technical council ktc
Kuali Technical Council (KTC)
  • Each institution has one voting member
  • Spans all Kuali projects
  • All development teams must follow the technical standards put forth by the KTC
  • Architecture and Development Standards Document
    • Standards for transport security
    • Standards for authn
    • Standards for authz
    • Standards for encryption protocols
    • Revisit every six months
  • Consulted with security experts at each institution
  • Accepting contributions from community - Kuali Contributions Guidelines document
    • Security requirements
kuali technology stack
Kuali Technology Stack
  • Uses all open source software and libraries that are ECL compliant
    • Java EE - Servlets, JSPs, JSTL, POJOs
    • Spring Framework
    • HTML, XML
    • CAS, Acegi
    • JUnit
    • WS-Sec
  • Kuali Rice helps us to employ these technologies consistently across all of the Kuali applications
kuali rice
Kuali Rice
  • What is Kuali Rice?
  • Kuali: a humble kitchen wok; Malaysian origins
  • Rice: it is what it is
    • Sits on the bottom of a dish
    • Not a very tasty meal by itself
    • Better with some substance on top
      • KFS - Beef
      • KRA - Chicken
      • KS - Seafood
  • Rice is the foundation to a hearty software product
the goals of rice
The Goals of Rice
  • The board vision for Kuali is a plug and play module by module approach to software
  • Kuali started as financials, but has evolved into a suite of administrative software (KFS, KRA, KS)
  • A lot of functionality in Kuali systems
    • Keeping the Kuali code base as small as possible without impacting quality is key
  • Highly productive development environment
    • For Kuali projects
    • For non-Kuali projects
rice goals continued
Rice Goals Continued
  • A common and consistent architecture
    • Allow developers to understand other rice enabled projects
    • Infrastructure would not need to be reinvented on each project - focus on functionality!
    • Rice team can focus on IT standards, like SOA, that will benefit the entire Kuali software suite
    • Adoption of other Kuali modules feasible
  • Generic enough for non-Kuali applications
  • Consistent security practices
rice modules
Rice Modules
  • KEW Kuali Enterprise Workflow
  • KNS Kuali Nervous System
  • KSB Kuali Service Bus
  • KEN Kuali Enterprise Notification
  • KIM Kuali Identity Management
  • KOM Kuali Organization Management
rice and security
Rice and Security
  • Security aspects are isolated to reusable pieces within Rice
  • An application development framework called the Kuali Nervous System (KNS) - AuthZ, ACL, automatic integration with the modules below
  • Workflow (KEW) provides audit features as well as approval policies
  • The Kuali Service Bus (KSB) provides standard ways for configuring secure inter-application communication
  • KIM will provide a set of fully functional user interfaces for managing Identity and Access Management
    • Consistent service API for IdM throughout applications
kuali nervous system kns overview
Kuali Nervous System (KNS) Overview
  • Provides reusable code, shared services, integration layer, and a development strategy
  • Provides a common look and feel through screen drawing framework
  • A document (business process) centric model with workflow as a core concept
understanding the kns paradigm
Understanding the KNS Paradigm

RECIPES_T

RecipeData Dictionary

Recipe(POJO)

ORMMapping

Lookups and Inquiries

Documents

Workflow(KEW)

kns security
KNS Security
  • Driven off of the Data Dictionary feature
  • Provides plug-points for authorization checking
    • Implementers can write their own authorization code in Java
    • Configure to use that code in XML within the Data Dictionary
  • Provides XML based ACL configuration for initiation of documents
  • Provides XML based field-level security configuration
kns security module level
KNS Security - Module Level
  • Kuali breaks down functionality into modules
    • Modules organize documents (business processes)
    • Examples: KFS GL, KS Billing, etc
  • Each module has a “Module Authorizer” interface to abide by
    • Contains certain core permissions checking methods
      • canInitiate, canLookup, canInquire
    • Each module implements an instance of this Java interface
    • Policies there get applied to all functionality in the module
    • Security formula looks at one’s roles in the context of the system (KIM)
kns security document level
KNS Security - Document Level
  • Documents roughly correlate to business processes
  • Document security has a formula:
    • Your role in the context of the document (initiator, approver, etc)
    • Your roles in the context of the system (KIM)
    • The state of the document
  • Each document has a “Document Authorizer” for applying this formula
    • Many documents follow a similar authorization pattern and can leverage inheritance of a parent “Document Authorizer” which implements the interface
    • Typically, documents override specific permission checking methods and inherit the rest
  • ACL or “Initiation” checks are configured based on group membership (KIM) and declared in Data Dictionary files
wiring up document security
Wiring up Document Security

<dictionaryEntry>

<transactionalDocument>

<documentClass>

org.recipes.document.RecipesDocument

</documentClass>

<documentAuthorizerClass>

org.recipes.authz.RecipesDocumentAuthorizer

</documentAuthorizerClass>

wiring up document security contd
Wiring up DocumentSecurity Contd.

<authorizations>

<authorization action="initiate">

<workgroups>

<workgroup>groupA</workgroup>

<workgroup>groupB</workgroup>

</workgroups>

</authorization>

</authorizations>

</transactionalDocument>

<dictionaryEntry>

kns security field level
KNS Security - Field Level
  • Read-only fields
  • Hidden fields
  • Masked fields - for displaying sensitive data (or not)
  • Encrypted fields - for storing sensitive data
  • Multiple levels of validation
    • Protection against XSS
  • Primarily driven from the Data Dictionary files for a given business object
kns field level authorization
KNS Field Level Authorization

<attribute name=”ingredients">

<attributeAuthorization>

<displayWorkgroup>Recipe Masters</displayWorkgroup>

<displayMask><maskLiteral literal="*********"/></displayMask>

</attributeAuthorization>

</attribute>

kns field validation
KNS Field Validation

<attribute name=”recipeCategoryCode”>

<maxLength>5</maxLength>

<validationPattern>

<alphaNumeric exactLength=“5” allowWhitespace=“false” />

</validationPattern>

<required>true</required>

</attribute>

kns persistence of data
KNS Persistence of Data
  • We use an object-relational-mapper (ORM)
    • Apache OJB; moving to JPA/Hibernate
    • Adds a layer of abstraction which handles proper data escaping automatically
    • Guards against SQL injection (OWASP recommends an ORM)
    • Allows the framework to handle the encryption protocol for storing data (not the developer)
kns encryption service
KNS Encryption Service
  • We have one service in our stack

<bean id="encryptionService"

class="org.kuali.core.service.impl.DemoGradeEncryptionSvcImpl" />

  • Uses DES out of the box
  • We document this and state a warning to stdout saying this is “insufficient” for production and that implementers should use AES
kns orm and encryption
KNS ORM and Encryption
  • Uses a built in conversion class which calls the encryption service to
    • Encrypt on storing data
    • Decrypt on retrieving data

<class-descriptor class="org.kuali.recipe.document.Recipe”

table=”RECIPES_T">

...

<field-descriptor name=”ingredients"

column=”INGREDIENTS" jdbc-type="VARCHAR"

conversion="org.kuali.core.util.OjbKualiEncryptDecryptFieldConversion" />

...

<class-descriptor>

kuali enterprise workflow kew
Kuali Enterprise Workflow (KEW)
  • Facilitates routing and approval of business processes throughout an organization
  • Provides re-usable routing rules across business processes
    • Binds business data to approvers (Persons and Groups)
  • Provides hooks for client applications to handle workflow lifecycle events of business processes
  • End users interact with central workflow GUIs for all client applications
workflow approvals as security
Workflow Approvals as Security
  • Sometimes functionality requires delegation of management
  • Workflow fits perfectly with this - it allows loosened restrictions on initiation (no ACL)
  • But requires approval for change to take effect
  • Almost all data changes in Kuali applications require approval
audit capability
Audit Capability
  • KEW provides a “route log” feature
  • Every business process transaction has this route log which is an audit trail
  • This feature is built into KEW and automatically happens
security of integration with kew
Security of Integration with KEW
  • Client applications can integrate with KEW in a couple ways:
    • Java API - in the same JVM
    • Through web services - remotely
      • SSL
      • Digital signatures
    • Over the KSB using it’s security mechanisms
kuali service bus ksb
Kuali Service Bus (KSB)
  • Enables applications and Spring beans (i.e. services) registered on the bus to interact with other applications and services
  • Provide (a)synchronous communication
  • Provide flexible security
  • Provide Quality of Service (QoS)
  • Keep it simple (light weight)
ksb security
KSB Security
  • Bus level: option to digitally sign, encrypt
  • Service level security through Acegi
    • Service level, method level
    • User proxying through standard security models (i.e. CAS, Kerberos)
    • Security context passed along (user, authn token, roles)
    • Services can call authn/authz authority to validate context
  • Web services
    • Apache CXF is foundation; supporting WS-Sec
kuali identity management kim
Kuali Identity Management (KIM)
  • Currently being built
  • Goals:
    • Satisfy requirements of all Kuali applications surrounding IdM
    • Consistent service APIs for all applications to use in their “Authorizers”
    • Simple and unified OOTB system
    • Consolidated management of IdM data backed by workflow, built using the KNS
    • Pluggable service layer - support plugging in other products (Shibboleth, CAS, Grouper, LDAP, etc)
kim model
KIM Model
  • Namespace - scoping for applications
    • Examples: KFS, KRA, Common, etc
  • Entity - person, service, system, etc
    • Entity Types allow for arbitrarily defining these
    • Entity Attributes - meta-data about a person
      • Service backing this will allow LDAP integration
      • Scoped to Namespace; can define defaults for a Namespace
  • Principal - An entity needs at least one to authenticate
    • Multiple principals per Entity instance
  • Group - simply groups entities or other groups
    • Can have arbitrary meta-data attributes
kim model contd
KIM Model Contd.
  • Permissions
    • Actions in an application; scoped to namespace
    • Can be arbitrarily defined at runtime - canSave, canView, etc
  • Roles
    • Aggregate permissions; can be across a Namespace
      • Role “Student Concierge” has permissions in KRA, KS, etc
      • Can be qualified:
        • “Student Concierge” for group “All Freshmen”
        • “Student Concierge” for student “Alice I. Wonderland”
    • Roles are given to Principals and Groups (applies authz)
  • Full DB diagram available at:https://test.kuali.org/confluence/x/38
  • Atlassian Crowd used as a functional model
kim services
KIM Services
  • AuthorizationService
    • isAuthorized(principal, permissions, <qualifiers>)
  • PrincipalService
  • EntityService
  • GroupService
  • RolesService
  • NamespaceService
  • All wired up in Spring
    • Will be exposed on the KSB (remote invocation)
    • Allow external applications and processes to provision
kim authentication
KIM Authentication
  • We don’t provide data storage for passwords in KIM
  • Implementers will be required to leverage their own authentication infrastructure
  • Acegi at the core as the framework
  • Recommend CAS
    • Will transitively support:
      • Shibboleth
      • LDAP
  • Our deliverable will be a supporting framework, documentation, configuration guides
kim roadmap
KIM Roadmap
  • 0.9.3 - KIM core functionality (May 2008)
    • OOTB system
    • Maintenance backed by workflow
    • Services and default implementations
    • Web Service-able
  • 0.9.4 - Retrofitting all Kuali apps to use KIM (August 2008)
  • Post 0.9.4 - Exercising “pluggability” - Shib, LDAP, Grouper integration (November 2008)
safeguarding against vulnerabilities
Safeguarding Against Vulnerabilities
  • XSS
    • Multiple layers of automated validation (web tier, business tier, etc)
    • Validation on every field is a runtime requirement - it must be in place
    • Stance on Javascript
  • SQL Injection
    • ORM does escaping
    • No direct interface to JDBC from the request object
  • SOA
    • Java interfaces become hardened contracts
    • Spring Framework for IoC
safeguarding against vulnerabilities contd
Safeguarding Against Vulnerabilities Contd.
  • Consolidated and pluggable encryption service
    • Easy to swap in a new protocol
  • Leverage well-known products with communities (Acegi, JA-SIG CAS, etc)
  • Leverage as many Java specifications as possible
  • Periodic code scans (Palamida)
  • Lots of code reviews - the more eyes, the better
  • A watchful eye on OWASP
questions
Questions?
  • The Kuali Foundation - http://www.kuali.org
  • Kuali Rice - http://rice.kuali.org
  • KIM - http://kim.kuali.org