510 likes | 673 Views
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
E N D
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 • Kuali Identity Management (KIM) Security • Protecting against vulnerabilities
Kuali Overview • Kuali Foundation • Community source projects • Administrative applications • Kuali Finance • Kuali Research Administration • Kuali Student • Kuali Endowment • The foundation: Kuali Rice
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 • 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 • Large scale administrative web applications • Millions of LOCs • 1000s of business processes and transactions • Must support 1000s of simultaneous users
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 • 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 • 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) • 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 • 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 • 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 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 • 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 • 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 • 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 • 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 RECIPES_T RecipeData Dictionary Recipe(POJO) ORMMapping Lookups and Inquiries Documents Workflow(KEW)
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 • 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 • 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 <dictionaryEntry> <transactionalDocument> <documentClass> org.recipes.document.RecipesDocument </documentClass> … <documentAuthorizerClass> org.recipes.authz.RecipesDocumentAuthorizer </documentAuthorizerClass>
Wiring up DocumentSecurity Contd. … <authorizations> <authorization action="initiate"> <workgroups> <workgroup>groupA</workgroup> <workgroup>groupB</workgroup> </workgroups> </authorization> </authorizations> … </transactionalDocument> <dictionaryEntry>
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 <attribute name=”ingredients"> … <attributeAuthorization> <displayWorkgroup>Recipe Masters</displayWorkgroup> <displayMask><maskLiteral literal="*********"/></displayMask> </attributeAuthorization> … </attribute>
KNS Field Validation <attribute name=”recipeCategoryCode”> … <maxLength>5</maxLength> <validationPattern> <alphaNumeric exactLength=“5” allowWhitespace=“false” /> </validationPattern> <required>true</required> … </attribute>
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 • 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 • 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) • 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 • 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 • 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 • 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) • 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 • 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) • 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 • 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. • 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 • 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 • 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 • 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 • 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. • 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