Federated Access to Multimedia Content Ajay Daryanani Middleware Engineer RedIRIS Zurich, 30th January 2009 1st Media Management and Distribution Workshop 1
Outline 1. Federated access to content • Requirements • Approaches 2. Additions to the metadata 3. Additions to ARCA 4. SIR: IdentityService@RedIRIS 5. Conclusions and questions 2
Requirements • As of today, the content available at our institutions is open and publicly available • Content providers need control over some items – Licensed content (=> Access Control) – Courses in different institutions (=> Federate) • Usage of web-based AAI technologies – Users are familiar with it – Seamless integration with current systems 3
First approach: Video Server plugin (1) • Protect the content itself (.wmv, .avi, …) • A user will see a http URL to start the authentication process (generated by a CMS) • Once authenticated, the CMS will show the real URL with the user’s data (secured) in the parameters • The user will call that URL, and the plugin will authorize or deny the access 4
First approach: Video Server plugin 5
First approach: Video Server plugin (2) • Advantages – URLs are public – Can serve through mms, rstp, http… • Disadvantages – Develop a tailored authentication/authorization plugin for each server – Not flexible – Difficult maintenance, high cost – Extension to the federation protocol (relayed trust) (or is it an advantage? ) 6
Second approach: SP-Proxy • Add a SP in front of the video server • Functionality – Act as a normal SP (authN, authR) using HTTP – Mask the links on the video server through HTTP • Advantages – Valid for any video server – Can serve through mms, rstp, http… • Disadvantages – Develop a whole new (complex) component – Should implement one-time URLs – Extension to the federation protocol 7
Second approach: SP-Proxy 8
Third approach: Common AAI (1) • WebTVs are emerging as a front-end to multimedia content • Typical AAI components can be applied • Advantages – Allows authN, authR, SSO, federated access… transparently – Low-cost deployment – Software maintenance not required – Flexible 9
Third approach: Common AAI (2) • Disadvantages – Controls access to the page, not the content – Once access is granted, the final URL (at the video server) is known and unprotected => IPTV portals should use one-time URLs 10
Third approach: Common AAI 11
Comparison 12
Outline 1. Federated access to content • Requirements • Approaches 2. Additions to the metadata 3. Additions to ARCA 4. SIR: IdentityService@RedIRIS 5. Conclusions and questions 13
Extension of the metadata • Definition of an object should also include the access permissions – For authorization at the SP – To publish extended metadata to ARCA • The new metadata – Is an addition to the current object metadata – Should be consumable by a XACML engine – Requires an agreement on the attribute schema (values, semantics) 14
Extension of the metadata example <item> <title>Some title</title> <link>http://iptv.univ-a.edu/SomeURL</title> … < policy scheme=“http://…/schema” public =“yes|no”> <Rule RuleId=“1” Effect=“Allow|Deny”> // Beginning of XACML policy <Target> <Subject> <AnySubject/> </Subject> <Resource> http://iptv.univ-a.edu/SomeURL </Resource> </Target> <Condition FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-one-and-only”> <SubjectAttributeDesignator DataType="http://www.w3.org/2001/XMLSchema#string" AttributeId=” schacHomeOrganisation "/> </Apply> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string"> uc3m.es </ AttributeValue> </Condition> </Rule> … 15
Outline 1. Federated access to content • Requirements • Approaches 2. Additions to the metadata 3. Additions to ARCA 4. SIR: IdentityService@RedIRIS 5. Conclusions and questions 16
Adding security in ARCA • Two-way SSL authentication for publishing – At the client, who wants to publish the metadata to a valid ARCA server – At the server, because ARCA should not accept content from everyone • Authenticated access to ARCA – To enable video rating and comments – To offer a customized view to the user • A user will be shown all public content + protected content which the user is authorized to see 17
Adding security in ARCA 18
Outline 1. Federated access to content • Requirements • Approaches 2. Additions to the metadata 3. Additions to ARCA 4. SIR: IdentityService@RedIRIS 5. Conclusions and questions 19
SIR: Servicio de Identidad de RedIRIS • Provides a single entry point to digital identity services for the academic community • Multiprotocol – Simplified management – Guarantee evolution • Flexible – Compatible with any level of IdM deployment • http://www.rediris.es/sir 20
The Basic SIR Model 21
Connecting to SIR 22
Outline 1. Federated access to content • Requirements • Approaches 2. Additions to the metadata 3. Additions to ARCA 4. SIR: IdentityService@RedIRIS 5. Conclusions and questions 23
Pilot phase (Using approach 3) • ARCA – Connection to SP (PAPI phpPoA) – Extended metadata parsing – SSL connections for metadata publishing • Universities: – Connect WebTV portal to SP (PAPI phpPoA) – Usage of one-time URLs – SSL connections for metadata publishing • Connection to SIR 24
Questions? Edificio Bronce Tel.: 91 212 76 20 / 25 Plaza Manuel Gómez Moreno s/n Fax: 91 212 76 35 25 28020 Madrid. España www.red.es
Recommend
More recommend
