A Framework for Obligation Fulfillment in REST Services
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

A Framework for Obligation Fulfillment in REST Services

  • 589 views
Uploaded on

WS-REST 2011. ...

WS-REST 2011.
Second International Workshop on RESTful Design.
Chairs: Cesare Pautasso, Erik Wilde, Rosa Alarcon.
<br>
Security Session. John Field, Stephen Graham and Tom Maguire

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
589
On Slideshare
589
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
3
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. A Framework for Obligation Fulfillment in REST Services WS-REST 2011 John Field Senior Technologist EMC Office of the CTO Joint work with Steven Graham and Tom Maguire© Copyright 2011 EMC Corporation. All rights reserved. 1
  • 2. Agenda   Introduction –  Motivating Use Case   Modeling Obligations –  Definitions, Architectural Roles   Extending Spring Security –  Design and Implementation   Obligation Design Patterns –  Metadata, Compatibility with REST Constraints   Obligation-enhanced Operations –  Development, Test, Deployment.   Conclusion –  Q&A, and Open Discussion© Copyright 2011 EMC Corporation. All rights reserved. 2
  • 3. What is an Obligation?   An Obligation is an expression of non-functional or cross-cutting requirements –  The scope of which transcends any specific service… –  …But for which the service bears an enforcement responsibility.   Example: The regulatory requirements imposed upon processing of Electronic Health Records (EHR).© Copyright 2011 EMC Corporation. All rights reserved. 3
  • 4. A Motivating Use Case: E-HealthRecords  Example: –  “A patient’s records may be released to a 3rd party, but only on a secure channel, and in a redacted form, and only with an appropriate notification to the parent or guardian within 24 hours”.   The implied requirements go beyond a simple “Permit” or “Deny” authorization decision, and include: –  Privacy/Redaction –  Records Retention –  Patient and/or guardian notifications –  Complex conditional authorization rules –  Etc.© Copyright 2011 EMC Corporation. All rights reserved. 4
  • 5. A Motivating Use Case: E-HealthRecords of requirements are also subject to  These types change, and may not even be known until deployment time. –  Making design, development, and product roadmap planning even more difficult.   Developers need a way to satisfy these requirements, while avoiding tangling the non-functional and cross- cutting GRC code into their core service logic. –  Question: Can we help by creating an appropriate developer framework?   Finally, note that use cases like this create challenges for many different stakeholders, not just developers: –  Product Managers –  Security Administrators –  Auditors© Copyright 2011 EMC Corporation. All rights reserved. 5
  • 6. Modeling Obligations   Obligations can be modeled as an extension to the classical conceptual model used for security enforcement. Policy Policy Administration Decision Point Point Policy Enforcement Point© Copyright 2011 EMC Corporation. All rights reserved. 6
  • 7. Conceptual Model for Obligations 4.  Policy Request Policy 5.  Policy Response Policy Administration Decision Point Point 3.  Decision Request1.  Define Policy w/Obligations 6.  Decision Semantic Response Contract …with Obligations Policy 7.  Enforce Enforcement Decision, Point and Fulfill2.  Request Resource 8.  Return Resource Obligations Representation © Copyright 2011 EMC Corporation. All rights reserved. 7
  • 8. Conceptual Model for Obligations Policy Policy Administration Decision Point Point   The PAP defines the Obligations.   The PEP fulfills the Obligations. Policy   The PDP is a trusted intermediary. Enforcement Point   Instantiates the obligation assertions,   Does not otherwise interpret or enforce the obligation.   Obligations extend the interface contract between the PDP and the PEP, and the semantic contract between the PEP and the PAP.© Copyright 2011 EMC Corporation. All rights reserved. 8
  • 9. A Standardized Model for Obligations   The OASIS XACML Technical Committee has defined a standard conceptual model for obligations. –  Boolean response + Obligation URN + attribute metadata. –  …unordered collection of strongly typed attributes, with values associated at runtime.   Permit…but do urn:emc:cto:obl:poc:1 with attributes   Deny…and do urn:emc:cto:obl:poc:2 with attributes   Our implementation was inspired by the XACML core standard, but is not a complete implementation.   Our design choices were driven by the desire to support REST developers who are already using a services framework such as Apache CXF or Spring MVC, along with Spring Security.© Copyright 2011 EMC Corporation. All rights reserved. 9
  • 10. Developer Enablement via the Spring Framework   Effective use of obligations requires support via a developer framework. –  Framework-based enforcement ensures appropriate:   Separation of concerns in the Java code   Separation of skills and responsibilities between application development and application deployment.   The Spring Framework is the de facto standard for Java developers –  Thus, we explored what could be done to provide support for obligations via Spring Security.© Copyright 2011 EMC Corporation. All rights reserved. 10
  • 11. Extending Spring Security   Spring Security’s features are extensible through the use of dependency injection. –  We designed and implemented the new obligation- aware components, and then configured these using DI.   The new components are designed to co-exist with the installed base. –  But to ensure that fulfillment occurs, deployers must be sure to configure the obligation-aware components first.© Copyright 2011 EMC Corporation. All rights reserved. 11
  • 12. Servlet  Container     Delega�ngFilterProxy   Other  Servlet  Filters         …                       …   Spring  IoC  Container  © Copyright 2011 EMC Corporation. All rights reserved. 12
  • 13. Inside the Spring Security Filter Other     Servlet     Filters   Chain Security   Authent-­‐   Session   Author-­‐   Context   ica�on   Management   iza�on   Persistence   Allowed Denied Securit Authen�ca�on   Access y ROLE_XXX   Decision Contex Manager t© Copyright 2011 EMC Corporation. All rights reserved. 13
  • 14. Supporting Obligations in Other     Servlet     Filters   Spring Security Obliga�on   Fulfillers   Security   Obliga�on   Authent-­‐   Session   Author-­‐   Obliga�on   Context   Enhanced   ica�on   Management   iza�on   Fulfiller   Persistence   Security   Filter   Context   Persistence   Allowed Allowed, but… Obligatio Denied Obligatio Securit n Pa PiP n Access Denied and… y Enhanced Authen�ca�on   PiP Enhanced Decision Contex Security ROLE_XXX   P Access Manager t Context PiP Obliga�ons   Decision PiP   PiP Fulfiller   PiP PiP Manager Registry  © Copyright 2011 EMC Corporation. All rights reserved. 14
  • 15. What about Obligations related Other     X   Servlet     Filters   to “Access Denied”? Obliga�on   Fulfillers   Security   Obliga�on   Authent-­‐   Session   Author-­‐   Deny   Obliga�on   Context   Enhanced   ica�on   Management   Obliga�on   Fulfiller   iza�on   Persistence   Security   Fulfiller   Filter   Context   Filter   Persistence   Obliga�on   Fulfillers   Obligatio Obligatio Securit n n Pa PiP Access y Enhanced Authen�ca�on   PiP Enhanced Decision Contex Security ROLE_XXX   P Access Manager t Context PiP Obliga�ons   Decision PiP   PiP Fulfiller   PiP   PiP Fulfiller   PiP PiP Manager Registry   Registry  © Copyright 2011 EMC Corporation. All rights reserved. 15
  • 16. General Obligation Design PatternQ: When should software designers use obligations?A: When there is a requirement for a supplementary policy enforcement action that is: –  Application-centric, but not application-specific. –  The supplementary enforcement is concurrent with the processing of a specific user transaction. –  Enforcement action may be independent of the outcome of the user transaction. –  Enforcement requirement specified at deployment time.   Requirement may not yet be known at application design time© Copyright 2011 EMC Corporation. All rights reserved. 16
  • 17. Metadata for Obligations Representing and Managing both the Implict and Explicit Properties   No standards exist for the metadata properties that characterize the obligation behaviors.   Our analysis led to the following table:Obl. Obl. Directly Directly Fires Before Fires After Side Synchro-Category Type Modifies Modifies Resource Resource Effects? nized* Request? Response? Access? Access? GRC Policy No No Yes No Yes. No Mgmt PAP updated Security, Audit No No No Yes Yes. No SIEM Logging Logs updated SLA Resource No Yes No Yes None No Mgmt*Synchronized before response sent to client?© Copyright 2011 EMC Corporation. All rights reserved. 17
  • 18. Obligation Management Consistent with REST   Obligations must themselves be considered REST resources. –  They are addressable, cacheable, resources.   The linked data representation of the obligation should include –  Implicit metadata properties, as described above –  Explicit relationships with other resources, i.e. a type, such as a Patient application or record.   The obligation management system must exhibit the appropriate emergent properties: –  Loose coupling through the uniform interface, scalability, visibility© Copyright 2011 EMC Corporation. All rights reserved. 18
  • 19. Compatibility With HATEOAS Constraint   Obligations can have a direct impact on the resource representation that is delivered to the client. –  The client may or may not be made aware that obligation fulfillment has occurred.   Either scenario can maintain complete adherence to the HATEOAS constraint. –  The representation must contain a consistent metadata set, via appropriate links, and media types. –  i.e. one could represent the required fulfillments through the use of specific media types   Content-Type, maybe Accept headers.© Copyright 2011 EMC Corporation. All rights reserved. 19
  • 20. Compatibility with the Layered SystemConstraint   Our current prototype is based upon an in-process model. –  Targeted to the installed base of Java + Spring Framework developers.   One can also envision other fulfillment models.   The layered system and uniform interface constraints of REST ensure that clients and servers may rely upon arbitrary intermediaries to provide fulfillment. –  This approach may have advantages when in-process fulfillment is not convenient or achievable.   An out-of-process fulfillment option again highlights the importance of defining obligations as addressable resources –  As the intermediary may be a shared component supporting more than one administrative domain, i.e. in a Cloud Service.© Copyright 2011 EMC Corporation. All rights reserved. 20
  • 21. Obligation-enhanced DevelopmentApplication DeploymentDeveloper Engineer design/code/ test/deploy Production test/release GRC Admin Security … Admin Auditor - Add GRC obligations - Tailor fulfillers - Add security obligations - Test - Tailor fulfillers - Test - Validate compliance via tool GRC Obligation - Compare to best practices Packages Security - Monitor regulatory changes Repository Obligation Packages Repository Obligation Developer Industry Standard Obligation - Build new obligation fulfillers Packages Repository - Tailor existing obligation fulfillers© Copyright 2011 EMC Corporation. All rights reserved. 21
  • 22. Operational Benefits of Obligations   For the developer –  obligations provide a consistent and standardizable mechanism to enable injection of application-centric GRC controls at design, development or deployment time.   For the security admin –  obligations provide a mechanism to enable applications to effectively leverage an existing XACML-based enterprise entitlement management infrastructure.   For the deployment engineer –  obligations can also be used to customize a generic application in support of specific corporate policies.   including adjustments required for different localities or geographies.   For the auditor –  obligations are an effective way to factor and package the code that implements any application-independent or well-known controls.© Copyright 2011 EMC Corporation. All rights reserved. 22
  • 23. Q&A© Copyright 2011 EMC Corporation. All rights reserved. 23
  • 24. THANK YOU© Copyright 2011 EMC Corporation. All rights reserved. 24