1 / 29

January 2013

Interoperating: MIT’s Fusion Center Prototype & JHU/APL’s Back End Attribute Exchange ( Identity Management Testbed). January 2013. Agenda. What is the MIT prototype? Accountable Systems concept Prototype mechanism Scenario #1 Integrating with JHU/APL IdM Testbed Goals Achievements

ivie
Download Presentation

January 2013

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Interoperating: MIT’s Fusion Center Prototype &JHU/APL’s Back End Attribute Exchange(Identity Management Testbed) January 2013

  2. Agenda • What is the MIT prototype? • Accountable Systems concept • Prototype mechanism • Scenario #1 • Integrating with JHU/APL IdM Testbed • Goals • Achievements • Observations

  3. MIT Massachusetts Institute of Technology Computer Science & Artificial Intelligence Lab Decentralized Information Group The Decentralized Information Group explores the consequences of information on the Web: where it comes from, what happens to it, and what are the rules for using it. We build tools to help people control the policies governing information, and we build automated reasoning systems to help determine whether information use complies with policy.

  4. Accountable Systems • Ability for systems to: • Determine whether each use of data is/was permitted • by the relevant rules • for the particular data, party, and circumstance • Make that decision available to access control, audit, and other technology • for real-time enforcement, retrospective reporting, redress, and risk modeling.

  5. Prototype • Prior project built a working prototype of an accountable system technology • Funded by DHS • Use cases were “fusion centers” • Attempting to retrieve or send information protected by privacy statutes

  6. Prototype: Principles • Real rules (e.g., statutes & regulations) require more information to reach a decision than traditional access control mechanisms provide • An accountable system must be able to access all decision-relevant information • Since decision-relevance varies by rule and situation, it would be unreasonable to work towards placing all such data in a centralized repository • Therefore, an accountable system must be able to reach data in its pre-existing decentralized locations • Real rules require more complex reasoning than traditional access control mechanisms provide • Rules are expressed in terms of conditions, exceptions, and context • Rules are not limited to access, but express many restrictions and permissions in the context of use • Therefore, an accountable system must be able to express, manipulate, and reason across a broad range of concepts

  7. Prototype Concept Sender Organization Internet Reasoner SENDER User Profiles User Docs Data Policies Recipient’s Organization RECIPIENT User Profiles User Docs Data Policies

  8. Transitioning from Prototype to Pilot • The Prototype mechanism had limited decentralization of data • Directories on the same server were used to model different servers

  9. Prototype First Implementation Internet Reasoner SENDER Sender Organization User Profiles User Docs Data Policies Recipient Organization User Profiles RECIPIENT User Docs Data Policies

  10. Transitioning from Prototype to Pilot More closely modeling the “real world”: • Implementing a level of decentralization • Interoperating with and external security mechanism to more closely model the “real world” • Reasoner and Sender organization data on the MIT server • Back end Attribute Exchange (BAE) authenticating and serving user profiles on the JHU/APL server

  11. Project Concept User Profiles BAE Sender’s Organization (MIT) (JHU/APL) Reasoner SENDER Web User SSL Certificates User Docs Data Policies Recipient’s Organization RECIPIENT User SSL Certificates User Docs Data Policies

  12. Project Implementation User Profiles BAE (JHU/APL) Web Reasoner SENDER (MIT) Sender Organization User SSL Certificates User Docs Data Policies Recipient Organization RECIPIENT User Docs Data Policies

  13. Demonstration Use Case Mia (Massachusetts Fusion Center analyst) wants to send a Request for Information (containing protected Criminal Record Information) to FeddyAgenti (DHS).

  14. Step #1: Prototype URL Mia types in the URL for the IdM version of the MIT Prototype and presses “Enter”

  15. Step #1 - Under the Hood:User SSL Certificate The tool finds Mia’s SSL certificate ….

  16. Step #2: The UI ….and uses it to auto-populate the UI

  17. Step #2 – Under the Hood:URI is a cgi Script to Fetch Attributes • The URI for Mia is a cgi script which will cause her attributes to be fetched from JHU: • The link “location” is http://dice.csail.mit.edu/idm/idm_query.cgi?c=US&st=Massachusetts&o=Massachusetts%20State%20Police&cn=Mia%20Analysa#me • In the prior demo, the link was a literal: • http://dig.csail.mit.edu/2010/DHS-fusion/MA/profiles/MiaAnalysa#me

  18. Step #2 – Under the Hood:Attributes Served • The URI for Mia is a cgi script which will cause her attributes to be fetched from JHU: • The link “location” is http://dice.csail.mit.edu/idm/idm_query.cgi?c=US&st=Massachusetts&o=Massachusetts%20State%20Police&cn=Mia%20Analysa#me c (Country) = US st (State) = Massachusetts o (organization) = Massachusetts State Police cn (Common Name) = Mia Analysa

  19. Step #3: Sender’s Attributes JHU authenticates the “Massachusetts State Police” certificate it previously issued to MIT, and provides Mia’s attributes.

  20. Step #3: Sender’s Attributes For reference, this is a quite different profile from the one in the MIT prototype:

  21. Step #3 - Under the Hood:SSL & XML SOAP -> RDF The cgi script calls a python script that serves the SSL key, issues an encrypted SOAP query and retrieves the “Distinguished Name” (DN) from the JHU/APL store, and converts from XML SOAP (the JHU format) to RDF (the MIT format).

  22. Step #4: Request for Information (RFI) Mia chooses the document she wishes to send.

  23. Step #4 – Under the Hood:Data - Request for Information (RFI) As in the original prototype, Mia identifies a pdf document that she wishes to send (the document was embedded with tags in xmp), and the UI populates the URL for the document.

  24. Step #5: Recipient’s Attributes Mia identifies the person to whom she wishes to send the RFI, and the UI populates URI for the cgi script again, this time seeking Feddy’s DN.

  25. Step #5 – Under the Hood:Recipient’s Attributes JHU’s server returns Feddy’s attributes for use.

  26. Step #6: Compliance Result The reasoner is able to process all of the input, and return its compliance result.

  27. Achievements • MIT Prototype able to Interoperate with JHU Back End Attribute Exchange • Able to serve appropriate certificates, create appropriate signatures • Able to fetch the Distinguished Name from JHU • Able to convert RDF -> SOAP and SOAP -> RDF • MIT able to use the JHU served sender and receiver attributes in the reasoning to achieve decisions

  28. Observations • JHU does not appear to control access to individual profiles • Access to the Policy Information Point (PIP) is restricted on what appears to be an organizational/server-basis through the use of client certificates granted to the organization • Once access to the PIP is achieved, there appear to be no restrictions on access to the information contained within (e.g., all profiles are accessible) • MIT prototype looking for enhanced functionality from the BAE • Pattern matching for the authenticator • Ability to serve URIs for attribute names or values • Elimination of requirement to populate the attributes in canonical order

  29. Questions? Lalana Kagal: lkagal “at” csail.mit.eduK. Krasnow Waterman: kkw “at” mit.edu

More Related