11
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
2
33
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.
44
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.
55
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
66
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
77
Prototype Concept
Internet
Sender Organization
Recipient’s Organization
User Profiles
User Docs
SENDER
Reasoner
Data Policies
User Profiles
User Docs Data Policies
RECIPIENT
88
Transitioning from Prototype to Pilot
• The Prototype mechanism had limited decentralization of data – Directories on the same server were used to
model different servers
99
Prototype First Implementation
Internet
Sender Organization
SENDER
Reasoner
Data Policies
User Profiles
User Docs
Recipient Organization Data Policies
User Profiles
User Docs
RECIPIENT
1010
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
1111
Web
Sender’s Organization(MIT)
Recipient’s Organization
User SSL Certificates
User Docs
SENDER
Reasoner
Data Policies
User Docs Data Policies
Project Concept
RECIPIENT
User Profiles
User SSL Certificates
(JHU/APL)
BAE
1212
Project Implementation
Web
Sender Organization
SENDER
Reasoner
Data Policies
User Docs
Recipient Organization Data PoliciesUser Docs
RECIPIENT
User Profiles
(JHU/APL)
BAE
User SSL Certificates
(MIT)
1313
Demonstration Use Case
Mia (Massachusetts Fusion Center analyst) wants to send a Request for Information (containing protected Criminal Record Information) to Feddy Agenti (DHS).
1414
Step #1: Prototype URLMia types in the URL for the IdM version of the MIT Prototype and presses “Enter”
1515
Step #1 - Under the Hood:User SSL Certificate
The tool finds Mia’s SSL certificate ….
1616
Step #2: The UI….and uses it to auto-populate the UI
1717
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
1818
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) = USst (State) = Massachusettso (organization) = Massachusetts State Policecn (Common Name) = Mia Analysa
1919
Step #3: Sender’s AttributesJHU authenticates the “Massachusetts State Police” certificate it previously issued to MIT, and provides Mia’s attributes.
2020
Step #3: Sender’s AttributesFor reference, this is a quite different profile from the one in the MIT prototype:
2121
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).
2222
Step #4: Request for Information (RFI)
• Mia chooses the document she wishes to send.
2323
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.
2424
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.
2525
Step #5 – Under the Hood:Recipient’s Attributes
JHU’s server returns Feddy’s attributes for use.
2626
Step #6: Compliance Result• The reasoner is able to process all of the input, and return its compliance result.
2727
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
2929
Lalana Kagal: lkagal “at” csail.mit.eduK. Krasnow Waterman: kkw “at” mit.edu
Questions?