Federated Access to Multimedia Content Ajay Daryanani Middleware - - PowerPoint PPT Presentation

1

Ajay Daryanani Middleware Engineer

RedIRIS Zurich, 30th January 2009 1st Media Management and Distribution Workshop

Federated Access to Multimedia Content

2

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

3

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

4

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

5

First approach: Video Server plugin

6

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?  )

7

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

8

Second approach: SP-Proxy

9

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

10

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

11

Third approach: Common AAI

12

Comparison

13

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

14

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)

15

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> …

16

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

17

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

18

Adding security in ARCA

19

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

20

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

21

The Basic SIR Model

22

Connecting to SIR

23

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

24

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

25

Edificio Bronce Plaza Manuel Gómez Moreno s/n 28020 Madrid. España Tel.: 91 212 76 20 / 25 Fax: 91 212 76 35 www.red.es

Questions?