marc santos / ingo dahn university koblenz-landau, knowledge media institute koblenz
TRANSCRIPT
What‘s to come?
The European Integrated Project TAS3
Main Tas3 Goals/Challenges Data Structure Fedora as central component in TAS3
Architecture of Tas3
The European Integrated Project TAS3
TAS3: “Trusted Architecture for Securely Shared Services” Handle person related information
project has started January 1, 2008 We have 4 years to achieve our
goals The Catholic University in Leuven is
coordinating the project Together with Synergetics
The European Integrated Project TAS3
TAS3 Consortium 18 partners from 8 different countries SAP Research Oracle Synergetics (Belgium) University of Nottingham
Dr. Angela Smallwood – Director of the University‘s Centre for International ePortfolio Development
University of Kent David Chadwick -Professor of Information Systems Security and Leader of the
Information Systems Security Group … University Koblenz-Landau
3 years of experience with Fedora Repository, that supports different Metada standards from the Elearning area Fedora is now used as backend DB in 3 projects
Tas3 Goals/Challenges (Fedora related) “The project will allow users and service
providers in the employability and e-Health sectors to manage the lifelong generated personal information of the individuals involved.” Employability and e-Health as reference
sectors to test our prototype architecture Generic architecture (e-Learning etc.)
Support ‘Sticky policies’ Not DB wide, but for each data item Fedora helps us
Support for XACML XACML in a special datastream
Support ‘Break-the-glass’
Break the Glass Service
Break-the-Glass service or “an emergency override
procedure” E.g. healthcare professionals need
access to person related data Data Protection Guard triggers an
audit trail service Logging all actions of the doctor Afterwards one can control the
activities Strong authentication A method to grant a person access to
data, to which he/she normally has no access to.
PolicyDecision
Point
Patient Record
1. (6). Access patient record
2. Denied 8. Granted
3. Break the Glass
4. Enforce DataProtection Policy
5. Granted
AuditTrail
7. Retrieve Record
PolicyEnforcement
Point
ObligationsService
Data ProtectionPolicy Guard
Tas3 Goals/Challenges (Fedora related) Store person related information in an
internal format Independent from special formats
Support for Multiple Standards/Specifications (e.g. IMS LIP, HR-XML, SICCT)
But in a dynamical way: ‘Dynamical transformation to satisfy different requirements of the specification in use by the receiving party.’ Fedora delivers the solution
Using Disseminators and a XSL transformation web service
Data Structure – Specification neutral
IMS-LIP
HR-XML
•Use case from the employability sector
•She‘s applying for a job•All her competencies are stored in the IMS-LIP format•She grants the personnel director access to her person related data (sticky policy)•Now he is allowed to fetch data•But he doesn‘t work with IMS-LIP. He needs HR-XML
Internal Format – CCTS Core Components Developed by UN/CEFACT group A standard motivated by eCommerce
Is part of the ebXML (electronic business) The suggested data structure is ‚Simple but flexible‘
Objects consist only of name-value pairs and pointers easy to store in relational Databases
Objects mapped to Fedora objects Improvement of CCTS by using Fedora‘s Datastreams and
Disseminators Augmented by DC and Sticky Policy
Interrelations between data objects are defined by RDFS (Resource Description Framework schema) Again – Fedora helps us Integrated Triplestore based on
Kowari or MPTStore planning to migrate to MULGARA
Functions of Fedora in Tas3
Disseminators to realize different dynamically generated formats Internal format based on “Core Components”
transformed into the required format Each Fedora object has un unlimited number of
Datastreams --- perfect for ‘Sticky Policies’ to add Metadata – DC or …
Triplestore to reflect Semantics Shielding Legacy Systems behind Fedora
A lot of data in legacy systems integrate these legacy systems – Fedora as gateway
layer on top Idea from Risaris (Ireland) Challenging task
Architecture of Tas3 (initial approach)
•Simplistic diagram•Main players
•Trust- and Security Services
•This is the heart of the architecture•But has no relations to Fedora
•Service Requester realized
•1. iteration as browser•then as Smart Client
•Service Provider•With Fedora as it‘s core component
•Transformation Services•Based on XSL, since most of the docs stored are based on XML•XSLT processor
•Fedora provides it as web service
•Aggregation Service•Web of distributed Fedora instances•Person related data may be also distributed
•Search services•Fedora API-A Basic Search•Triplestore search – RI web service interface
•„Security Services“•Not doing the authentication or authorization work•Secure the line (SSL), Secure SOAP messages using WS-Security•Send some information to the Trust and Security Services : Credentials, Request for data, Policies •Receives: YES or NO
•API-M•Management tasks
•addDatastream, addDisseminator, ingest
•API-A•Fetching data, searching data
•listDatastreams, findObjects•Fedora as gateway for legacy systems
•Realized by Disseminators using web services from Risaris to query in legacy databases
•Transaction component•Not sure if we need it…•Multiuser system
•So we have to think about transactions!•We gonna have a closer look at the AKUBRA project!