D5.1orig-2 Access Control Subsystem

From EChase
Jump to: navigation, search
Warning: this is a copy of the D5.1 document as originally submitted to the EC.

To contribute please use: Access Control Subsystem.

Back to D5.1orig System Specification


The access control subsystem will provide some interfaces to the presentation module that will show the appropriate user interface for a particular user based on the information retrieved from this module.

This subsystem is responsible of:

  • being able to trace the use of content in its "digital life"
  • making sure that only authorized end users can access the content
  • making sure that the content delivered is the exact copy of the original
  • making sure that no pirate copy of the content can be derived
  • providing the functionality to personalize the access to the eChase system for different type of content users

The Access Control Subsystem is divided in the following modules:

  • Authentication & Authorization: allow only "known" users to access the contents that they are allowed to access.
  • Profiling: manages user segmentation and personalization
  • Rights Management: it is responsible to protect the IPR of the CO
  • Content Filters: it is responsible to protect the IPR of the CO

The access control subsystem will provide some interfaces to the presentation module that will show the appropriate user interface for a particular user based on the information retrieved from this module.

The modules are the following:

  • Authentication and Authorization
  • Profiling
  • Digital Rights Management
  • Content Filters


Authentication & Authorization Module[edit]

Authentication is the process of uniquely identifying a user by verifying his or her credentials when the user attempts to make a connection to your application or service. There are many different technologies that you can use to authenticate users, including:

  • HTTP basic authentication
  • Certificate-based
  • Kerberos
  • Forms-based

In Web applications, authentication generally consists of two parts: querying for credentials (usually by some interface that requests a login name and password) and verifying those credentials against some source (such as a database).

Authorization is confirmation that an authenticated principal—a user, a computer, a network device, or an assembly—has permission to perform an operation. Protection allows only appointed users to perform certain actions, and it prevents malicious acts.

The Authentication & Authorization module is divided in the following modules:

  • Authentication Provider
  • Authorization Provider
  • Provisioning

Authentication Provider[edit]

The authentication provider is responsible for performing primary authentication of an individual which will link them to a given identity. The authentication provider produces an authenticator – a token which allows other components to recognize that primary authentication has been performed. Primary authentication techniques include mechanisms such as password verification, proximity token verification, smartcard verification, biometric scans, or even X.509 PKI certificate verification. Each identity may be associated with more than one authentication provider. The mechanisms employed by each provider may be of different strengths and some application contexts may require a minimum strength to accept the claim to a given identity.

The eChase Authentication Provider adopts password as authentication mechanism. This mechanism is the easiest to implement but is also the least secure. The eChase Authentication Provider mechanisms of authentication are made more secure using HTTPS as secure channel to provide the user credentials.

The Authentication Module interacts with the presentation layer that gathers user credential information and asks to the Authentication module to verify them and, after a successful verification, to create an authentication token.

The Authentication Module will also provide an Authentication Web Service that allows all the client applications that interact with eChase web services to authenticate themselves with eChase system.

The Authentication Module checks the credentials against the User Data Repository.

The Authentication Module provides also the API to verify the token validity and to renew the token itself.

Authorization Provider[edit]

The Authorization Provider enforces access control when an entity accesses an eChase resource.

The Authorization provider allows applications to make authorization and other policy decisions based on privilege and policy information stored in the repository.

The eChase provider supports a Role-Based Access Control (RBAC).

RBAC has seen widespread acceptance because its objectives are architectural. RBAC simplifies security administration, includes role inheritance semantics to enable rich policy definition, and permits easy review of subject-to-role as well as role-to-permission assignments. RBAC is ideal for security architecture because of its alignment with our other architectural goals of simplicity, reliability, adaptability, and serviceability.

Role-based access control attempts to simplify the number of access definitions required between a large pool of subjects and a large pool of objects. This simplification is critical for achieving security in conjunction with other architectural goals, such as scalability, ease of administration, and performance. Adding users might not require additional user groups, and adding objects might not require additional object-access groups.

RBAC introduces roles to associate a use case of the system with a label that describes all the functions that are permitted and forbidden during the execution of the use case. Users execute transactions, which are higher abstractions corresponding to business actions, on the system. Within a single transaction, a user may assume multiple roles, either concurrently or serially, to access and modify objects. Separating users into domains and determining policy at the domain level insulates us from the churn in the underlying user population. Similarly, creating object groups adds simplicity to the classification of access modes to objects. Consider a database in which the basic object accessed could be of very fine granularity—for example, a single row or field of a table. Handling access labels at this fine level of granularity can add a huge performance cost, because every query against the table is now interrupted to check row-level access permissions. To avoid this performance hit we can grant the role access to the entire table instead of individual rows.

RBAC works as follows. Users are assigned to roles; objects are assigned to groups based on the access modes required; roles are associated with permissions; and users acquire access permissions on objects or object groups through roles by virtue of their membership in a role with the associated permissions. Roles can be organized into hierarchies with implicit inheritance of permissions or explicit denial of some subset of access permissions owned by the parent role. RBAC solutions define the following:

Object-access groups[edit]

Objects can be organized into groups based on some attribute such as location (files in the same directory, rows in the same table) or by access modes (all objects readable in a context, all URLs in a document tree that are readable by a user, all valid SUID files executable by a user).

Access permissions[edit]

Access permissions define the operations needed to legitimately access elements of an object group (access modes are also sometimes called operations). Any user that requests access to the object group must do so from a role that has been assigned the correct access permissions.

Roles[edit]

Roles are use-case driven definitions extracted from the application’s operational profile describing patterns of interaction within the application. We organize users into roles based on some functional attribute, such as affiliation (all users in the Sales organization; all administrators of the application; all managers requiring read-only, ad hoc query access to the database), by access modes (all users permitted to execute commands, all Web sites trusted to serve safe applets, and all users with write access to the directory), or by hierarchical labels (manager, foreman, or shop worker). Static non-functional attributes of a user do not define roles (such as location, years of service, or annual income). The user must do something to belong to a role.

Role assignment[edit]

We assign users or user groups to roles. Users can be assigned to multiple roles and must have a default role for any specific access decision. Users can dynamically change roles during a session. Transitions between roles may be password protected, and the application might even maintain a history of past roles for a user over the life of a session.

Each operation that need to access a protected resource in eChase will interact with Authorization Provider to check if sufficient privileges are held by the user attempting to execute the operation.

The Authorization Module provides API to verify the permission rights of the user specifying the user name or his/her role, the name of the resource (URI) and the type of access needed (read, modify, download, …).

The Authorization module verifies the required permissions against the User Data Repository.

User Roles[edit]

At this stage of the project the eChase final users are not correctly identified. The following hypothetical Actors (Roles) have been identified and shown following:

Content Users

  • General Subscribers

Content Providers

  • Content Providers

Product Service Providers

  • Commercial Publishers
  • Educational Distributors

Content Aggregators

  • Cataloguers
  • Curators
  • Subject Experts
  • Editors
  • Designers
  • Authors
  • Knowledge Engineers

System Administrators

  • System Administrators
  • DB Administrators


Profiling Module[edit]

A profile is a set of characteristics that define any business-related item, such as a user or a company.

For example, a user profile may include characteristics such as first name, last name, city, gender, age, and e-mail address. A company profile may include characteristics such as company name, contact, city, and e-mail address. Using the Profile Module, you can obtain the profile information for a user who interacts with eChase system.

The profile is used to personalize interactions between eChase and individuals.

The profile is identified by a Profiled that maps uniquely a profile to a specific user.

The profile contains the following general information:

  • General user information (name, address, age, sex, ID)
  • Logical identifiers (e.g. logical name, personal number, e-mail address)
  • General subscriber information (name, bill information, users)
  • General privacy preferences

Capability description:

  • Terminal capabilities (e.g. user interface capabilities, communication capabilities, synchronization capabilities, WAP browser capabilities)
  • subscribed service capabilities

User’s preferences:

  • To allow users to describe their wishes and to indicate preferences for specific contents or information or policy, e.g. browser appearance, preferred language,…

Service customization (to customize subscribed user services or applications):

  • User interface
  • Supplementary services settings
  • Status of services (active/not active).

Profiling module allow application specific as well as generic information to be associated with an identity. These tools allow applications to tailor the user experience for a given individual leading to a streamlined interface for the user and the ability to target information dissemination for a business.

This module gives the information that allows other modules to customize their appearance and/or behavior.

The user profile could be defined as an XML document.

System Administration[edit]

All the eChase subsystem needs to be administered and configured. For each subsystem a set of API will be developed to allow administrators to interact with module. A Graphical User Interface is built for each administration module. This GUI will be developed as a plug-in (Portlet, web parts,…) so a custom administration console can be presented to administrators that have different skills an privileges.

Moreover, eChase Admin should be managed through a separate Web Site, together with its own machines and infrastructure.


Digital Rights Management[edit]

In this section the main DRM related requirements are summarized and a modularized DRM architecture is proposed.

Protection Requirements[edit]

Requirements related to Digital Rights Management are expressed in the project deliverable [X]. We report here the key points:

  • Being able to accommodate different Content Value Chains and Usage Scenarios;
  • Being applicable to a wide range of contents types, namely videos and images in various formats and resolutions;
  • Protecting contents by restricting actions on it (e.g view or print) is less important than protection from unauthorized copies;
  • Not being perceived as an intrusive solution by users: DRM system should not require users to change the way they work on digital contents;
  • Domain support: downloaded content must be usable on groups of devices (e.g. all PCs in the same school) and need to be easily movable or shared between different PCs;
  • Contents need to be usable even on devices with no connection to the internet;
  • Easy or no installation of DRM specific software on clients.

Moreover, In [X] we proposed a classification of DRM systems based on the level of security they can guarantee. Three main class were identified:

  • Weak DRM
  • Mid-Way DRM
  • Strong DRM

Analyzing the requirements appears quite clearly that there are different and contrasting interests. From one side, content providers demands security for their contents, on the other users demand flexibility and don’t accept tools that impose limitations on the way they work.

Before the proposal of a custom architecture we surveyed the ongoing standardization initiatives in the DRM area. Using standards-compliant products increases the possibility to integrate components that are replaceable and interoperable. Moreover, we took in consideration experiences made in projects or businesses similar to eCHASE. The idea was to understand how other subjects that make image or video contents available online solved the IPR protection issue. Finally, we evaluated the products currently offered both by the DRM commercial market and by open source initiatives.

From the technological point of view the main results of this phase were:

  • The majority of products better support business models addressing consumers market. On-line music and video seem to be the primary targets for these solutions. These products don’t provide the flexibility requested by eCHASE.
  • Nearly all the products are custom solutions that don’t rely on standards and that don’t offer interoperability.
  • A general consideration is that the DRM software market is not yet a mature and stable market; there are a lot of small or medium software makers and many software acquisition operations are in process; moreover, some initiatives are working on new "standards" (i.e. Digital Media Project and Sun DReAM).
  • Choosing the wrong solution could bind the consortium to a specific technology that might become obsolete in a few years.
  • The open source community is not really active in this area (probably due to patents and other legal implications). There are some products available (IPMP, Media-s) whose development was stopped some years ago. These products can only be taken as a starting point if the eCHASE consortium will decide to develop a totally new DRM from scratch.

DRM Logical Architecture[edit]

The design of the proposed DRM architecture followed an incremental and component oriented approach, this methodology led us to the definition of a modular system which can be implemented starting from a simple Weak DRM architecture and then be extended, following business needs, toward a Mid-Way and Strong DRM solution.

In conformity with the described design principle, the architecture is able to address a wide range of IPR protection requirements, which span from businesses dealing with low-valued content, to businesses managing highly valued content.

Given the requirements gathered in eCHASE, the Mid-Way solution appears to be the best compromise among security requested by content providers and flexibility needed by users. eCHASE Demonstrator will focus on the Weak solution. The Mid-Way solution should be introduced to support the real business starting after the trial phase. Strong DRM may be implemented when specific business needs will arise.

The remaining sections of this paragraph illustrate the system architecture following the described approach.

Weak DRM[edit]

Weak DRM Reference Architecture

depicts the high level design of the proposed Weak DRM architecture.

The building blocks inside the DRM System area represent the core components, boundary blocks are not strictly part of the DRM System, but their services are crucial for the implementation of the DRM system.

The main DRM architectural building blocks are:

  • DRM Content Protection Subsystem: is one of the core elements of the DRM platform; in the Weak DRM configuration the only software component contained is:
    • Object Identifier: is a service that assigns to contents a unique identifier and assures that the relationship between identification data previously assigned (original identifier) and the new object identifier is maintained. This component will generate identification numbers that adhere to Digital Object Identifier (DOI) standard.
  • License Manager Subsystem: it’s responsible for managing licenses, in the Weak configuration it’s composed of the following software component:
    • License Visualization Manager: ensures that appropriate license information are displayed and agreed by users, prior to perform the digital content download.
    • License Definition Interface: this component exposes the interfaces that allow parties (essentially the eCHASE Platform admin) to define licenses that will be associated to contents.
  • DRM Database: the DRM Database contains all the data required by other DRM software components, it’s not intended for general purpose content metadata, but for storage of information needed by DRM functionalities. Some of these data are:
    • Content Unique Identifiers
    • License information
    • Tracking information
    • Relation between contents and associable licenses
  • Reporting Engine: provides reporting functionalities that allows administrators and content owners to gather data about system usage.

Boundary blocks provide the following services:

  • Pricing Definition Interface: this interface allows to define prices associated to contents and licenses. This module must be aware of the DRM subsystem because the price could depend, not only on the content, but also on the specific kind of license. Moreover, the price could vary depending on the class of the user, e.g. a professional user could pay a price and an end-user could pay a different price.
  • Payment Gateway: this gateway exposes interfaces that allow other components to bill users.
  • Authorization/Authentication: this component ensures that all parties involved in the digital content value chain are authenticated and trusted.

Mid-Way DRM[edit]

Mid-Way DRM Reference Architecture

represents the proposed Mid-Way DRM architecture. This configuration is obtained by adding the following functional components to the Weak DRM solution:

  • DRM Watermarker: contained in the Content Protection Subsystem, it’s responsible to embed information into digital contents. This component uses invisible watermarking technologies for inserting identification and licensing information, and optionally, if requested by content providers, visible watermarking for applying logos to digital contents.
  • Tracking Crawler: is responsible to scan the Web for eCHASE watermarked contents and to store tracking data.

Strong DRM[edit]

Strong DRM Reference Architecture

Finally, illustrates the Strong DRM architecture, obtained by adding to the Mid-Way configuration the following software components:

  • DRM Packager: in the Content Protection Subsystem, is responsible for encoding contents to an encrypted format, making it unusable without the appropriate license.
  • License Delivery Manager: in the License Manager Subsystem, provides the functionalities needed for generating and delivering licenses. Licenses managed by this component will be compatible with ODRL Rights Expression Language.
  • DRM Agent: is the component, usually embedded into the rendering application (such as visualization and editing tools), that decrypts the asset and renders it according to the rules expressed in the license. The DRM Packaged content it’s usable only in applications which have the appropriate DRM Agent embedded.

The following sub paragraghs provide a further details of the main strong DRM Components and reports the related use cases.

DRM Packager[edit]

The primary goal of this Component is to transform contents in their original format in the DRM protected format (Packaged Content).

The following Activity Diagram describes the DRM packager main tasks

DRM Packager Activity Diagram
  • Generate Content Encryption Key: generates the symmetric content encryption key (CEK) that will be used to encrypt the content. The size of the key and generation algorithm may vary depending on security requirements.
  • Generate DRM Metadata: metadata includes at least:
    • Unique Content Identifier
    • License Acquisition URL
    • Encryption Algorithm identifier
    • Content Type
    • Embedded Rights
  • Include Default License: (optional step) a default license can be generated in order to be directly included in the DRM Packaged Content
  • Encrypt Content: in this phase the content is encrypted using the previously generated CEK. The Algorithm may vary depending on security requirements.
  • Sign data: sensible information are signed to ensure that no modification will be possible on the DRM packaged content
  • Package Content and DRM Metadata: Encrypted Content, Metadata and Digital Signature are packaged in one binary file.
  • Store Content Encryption Key: The Content Encryption must be stored securely in the DRM Database
  • Store Packaged Content: The content can be freely distributed

So, the DRM Packaged content has the following structure:

  • DRM metadata
  • Embedded License (not mandatory)
  • Encrypted Content: the result of the original content encryption
  • Digital Signature: to ensure the integrity of the package

License Delivery Manager[edit]

The main job of the DRM License Manager is to generate and deliver licenses to purchasers. This component will support the ODRL standard as expression language for license definition.

ODRL specification defines an extensible Rights Expression Language based on XML. As reported on the W3C web site ( http://www.w3.org/TR/odrl ). The ODRL rights information consists of the following core entities:

  • Assets: include any physical or digital content. The Assets must be uniquely identified (may include Encryption information for secure asset delivery).
  • Rights: the rights information consisting of:
  • Permissions: actual usages allowed over the assets
    • Constraints: limits to these permissions
    • Conditions: exceptions to control permissions
    • Requirements: obligations needed to exercise the permission
  • Parties: include end users and Rights Holders. Parties can be humans, organizations, and defined roles.

The ODRL foundation model is described by the following picture:

ODRL Foundation Model

Moreover, ODRL define a complete Data Dictionary that accurately defines the semantic of the terms used within the ODRL expression language.

ODRL language is extensible and many profile are already been defined for several goals, e.g. profile that implements Creative Commons licenses, profile for special sectors including educational.

Moreover, an important aspect about the security is that the License object is cryptographically bound to a specific DRM Agent or User, so only that principal can access and use it.

Depending on the financial model adopted, after the license generation and delivery, the DRM License Manager might integrate with a Payment Gateway Component to finalize the financial transaction.

DRM Agent[edit]

DRM Agent services are needed in order to be able to access and perform operation on a DRM Protected Content. For requested operation, the DRM Agent must ensure that the user has an appropriate license that grants the necessary rights.

DRM Agent must be embedded in each consuming application (e.g. Adobe Photoshop for pictures, Pinnacle Studio for videos, etc.)

The depicts the basic architecture of an abstract DRM Agent.

DRM Agent basic architecture

The DRM Agent is subdivided in 3 main subcomponents:

  • DRM Agent Application: provides core functionalities, such as:
    • Get the list of licenses associated to a given object
    • Interpret the Right Expression Language included in licenses
    • Access data contained in the DRM Agent Repository
    • Provide synchronization mechanism with server side DRM Components (e.g. timing, license usage status)
    • Manage the license acquisition protocol.
  • DRM Agent Application Plugin: is the part of the agent that must be embedded into the consuming application and that must ensure the control over it, for example, if the license doesn’t allow the print operation the plugin must ensure that all the menu items and commands that allow this operation are disabled.
  • DRM Agent Repository: maintains sensible data, such as:
    • Licenses
    • Encryption Keys
    • Status information
    • License usage status (e.g. remaing use for limited use licenses)
    • Timing information

The main defensive lines that ensure the security of the plugin are:

  • API Security: Api exposed by the core component should grant access only to trusted DRM Agent Application Plugins
  • Repository Protection: DRM agent manages sensitive information that could be abused by an attacker, the protection of this kind of data is crucial because tampering and unauthorized access would compromise the security of the entire DRM value chain.
  • Hardware Pairing: means that the DRM agent can be dependent on the hardware on which it is installed, thus protecting the agent from attacks that try to move the agent to another hardware to try to activate the content without the authorization.

Back to D5.1orig System Specification