Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "COSMOS Design 209337"

(→‎'''Open Issues/Questions ''')
(→‎'''COSMOS artifacts in scope for security''')
 
(23 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
== '''Scoping of the COSMOS Security Infrastructure''' ==
 
== '''Scoping of the COSMOS Security Infrastructure''' ==
 +
The goal of this Enhancement Request (ER) is to define / document / design the full scope of the COSMOS Security Infrastructure.  This is the master Security ER; underneath it, multiple ERs will be opened to address specific areas of Security. The COSMOS Security solutions needs to address the use cases listed on http://wiki.eclipse.org/COSMOS_Use_Cases for the actors defined in http://wiki.eclipse.org/Use_case_actors
  
 
=== '''Change History''' ===
 
=== '''Change History''' ===
Line 26: Line 27:
 
|-
 
|-
 
| align="left" | Code (not part of this ER)
 
| align="left" | Code (not part of this ER)
−
| 4
+
| 8
 
| Dev Team
 
| Dev Team
 
|-
 
|-
Line 75: Line 76:
 
This enhancement is associated with [https://bugs.eclipse.org/bugs/show_bug.cgi?id=209337 bugzilla 209337].
 
This enhancement is associated with [https://bugs.eclipse.org/bugs/show_bug.cgi?id=209337 bugzilla 209337].
 
<p>
 
<p>
−
Thsi ER will define / design / document the full scope of the COSMOS Security Infrastructure.  This is the master Security ER; underneath it, multiple ERs will be spawned to address specific areas of the Security.
+
COSMOS needs to address the following aspects of Security:
−
 
+
−
Sepcifically, we need to address
+
 
# Authentication
 
# Authentication
 
# Encryption
 
# Encryption
Line 85: Line 84:
  
 
</p>
 
</p>
 +
 +
== '''COSMOS Security Model''' ==
 +
 +
The COSMOS security model is detailed in the use cases on http://wiki.eclipse.org/COSMOS_Use_Cases
 +
 +
== '''COSMOS artifacts in scope for security''' ==
 +
 +
COSMOS should secure the following artifacts:
 +
# Management Domain
 +
# Data Broker
 +
# Visualization
 +
# Access to Data Managers and MDRs
 +
# Queries and result sets
  
 
== '''Security Providers supported by COSMOS''' ==
 
== '''Security Providers supported by COSMOS''' ==
Line 94: Line 106:
 
# Ensure full support and compliance with WS-Security
 
# Ensure full support and compliance with WS-Security
  
 +
== '''Security considerations for COSMOS components''' ==
 +
# Management Domain
 +
## Since the Management Domain is the entry point into COSMOS, it needs to address Authentication.
 +
# Data Broker
 +
## Since the Data Broker "knows" about all the MDRs and Data Manager, it should be used to enforce / implement Authorization, i.e. role-based security
 +
# Data Managers and MDRs
 +
## Should the access interfaces for the Data Managers and MDRs implement any security paradigm?
 +
# Visualization
 +
## Should the visulization interfaces implement any security paradigm?
  
 
== '''Authentication''' ==
 
== '''Authentication''' ==
  
−
COSMOS must support basic user authentication and also support an SSO paradigm.
+
COSMOS must support user authentication and also support an SSO paradigm.
  
−
== '''Message Handling Considerations''' ==
+
== '''Authorization''' ==
  
−
The COSMOS messages must consider the following guidelines to support i18n:
+
COSMOS will need to support the roles identified in http://wiki.eclipse.org/COSMOS_Use_Cases.  Additional roles may be implemented by the Security Provider used by the adopter.
  
−
# Prefix each message with unique message-ids
+
== '''Encryption''' ==
−
# Label 3rd party messages when shown from COSMOS
+
  
−
== '''i18n Checklist''' ==
+
COSMOS will not encrypt any data while it is "at rest" in and MDR.  This is something that the MDR / repository in question should own and control.  However, COSMOS will be responsible for encrypting the queries and result sets as they flow through the COSMOS components, e.g. Broker / Domain / etc.
−
 
+
−
Here is a check list to determine whether COSMOS is i18n-ready or not:
+
−
# Menus, dialogs and web layouts can tolerate text expansion
+
−
# Development language strings are reviewed for meaning and spelling to reduce user confusion and lessen translation errors
+
−
# Third-party software used in the product is examined for i18n support
+
−
# Consistent terminology is used in messages
+
−
# COSMOS runs properly in its base language in all target locales
+
−
# Strings are not assembled by concatenation of fragments
+
−
# Source code does not contain hard-coded character constants, numeric constants, screen positions, filenames or pathnames that assume a particular language
+
−
# String buffers are large enough to handle translated words and phrases
+
−
# East Asian editions support line-breaking rules
+
−
# All international editions of the program are compiled from one set of source files
+
−
# Localizable items are stored in resource files, message tables or message catalogues
+
−
# All language editions share a common file format
+
−
# Program handles non-homogeneous network environments where machines are operating with different encodings
+
−
# No assumptions are made that one character storage element represents one linguistic character
+
−
# Code does not use embedded font names or make assumptions about particular fonts being available
+
−
# Program displays and prints text using appropriate fonts
+
−
# Sorting and case conversion are culturally correct
+
−
# Application works correctly on localized editions of the target operating system(s)
+
−
# Specific for web internationalization:
+
−
## Check middle-tier components for internationalization compliance
+
−
## Ensure that information about encoding and locale of data is passed correctly between presentation and backend tiers
+
  
 
== '''Task Breakdown''' ==
 
== '''Task Breakdown''' ==
  
−
The following section includes the tasks required to complete this enhancement.
+
The following section includes the tasks required to complete this enhancement:
 +
 
 +
# Define the full scope of Security for COSMOS
 +
# Open downstream ERs to be completed in later iterations
 +
 
 +
== '''References'''==
  
−
# TBD
+
# WS-Security -- http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss
 +
# XACML -- http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml
  
 
== '''Open Issues/Questions '''==
 
== '''Open Issues/Questions '''==
Line 143: Line 146:
 
* How much effort should be expended in addressing proprietary Security Providers?
 
* How much effort should be expended in addressing proprietary Security Providers?
 
* How many downstream ERs do we need to open once this ER is complete?
 
* How many downstream ERs do we need to open once this ER is complete?
 +
* Should XACML be used for implementing Authorization?
 +
* Should COSMOS use Security Tokens?
  
 
----
 
----
 
[[Category:COSMOS_Bugzilla_Designs]]
 
[[Category:COSMOS_Bugzilla_Designs]]

Latest revision as of 14:56, 15 January 2008

Scoping of the COSMOS Security Infrastructure

The goal of this Enhancement Request (ER) is to define / document / design the full scope of the COSMOS Security Infrastructure. This is the master Security ER; underneath it, multiple ERs will be opened to address specific areas of Security. The COSMOS Security solutions needs to address the use cases listed on http://wiki.eclipse.org/COSMOS_Use_Cases for the actors defined in http://wiki.eclipse.org/Use_case_actors

Change History

Name: Date: Revised Sections:
Jimmy Mohsin 01/08/2008
  • Initial version

Workload Estimation

Rough workload estimate in person weeks
Process Sizing Names of people doing the work
Design 3 Jimmy Mohsin
Code (not part of this ER) 8 Dev Team
Test (not part of this ER) 4 QA Team
Documentation (not part of this ER) 1
Build and infrastructure (not part of this ER) 1
Code review, etc. (not part of this ER) 1
TOTAL 12

Terminologies/Acronyms

The terminologies/acronyms below are commonly used throughout this document. The list below defines each term regarding how it is used in this document:

Term Definition
User An entity representing a user in the organization. This is usually a 1:1 relation between a user and a real person
Security Provider Software that implements the various aspects of Security
Account an object representing an identity that exists on a specific realm / domain – e.g. login account on UNIX or Oracle. A single user may be associated with a multiple accounts
Role an application-centric authorization grouping of users (while group is a resource-based authorization grouping of accounts).

Purpose

This enhancement is associated with bugzilla 209337.

COSMOS needs to address the following aspects of Security:

  1. Authentication
  2. Encryption
  3. Authorization
  4. Approaches for implementing security in COSMOS, i.e. type of Security Providers supported
  5. Determine connection points where a Security Provider plugs into COSMOS

COSMOS Security Model

The COSMOS security model is detailed in the use cases on http://wiki.eclipse.org/COSMOS_Use_Cases

COSMOS artifacts in scope for security

COSMOS should secure the following artifacts:

  1. Management Domain
  2. Data Broker
  3. Visualization
  4. Access to Data Managers and MDRs
  5. Queries and result sets

Security Providers supported by COSMOS

COSMOS should allow an adopter to plug in a Security Provider of their choosing. COSMOS must support the following options:

  1. Provide support and reference implementations for specified industry standard Security Providers, e.g. LDAP.
  2. Publish guidelines for hooking in Enterprise class Security Providers
  3. Ensure full support and compliance with WS-Security

Security considerations for COSMOS components

  1. Management Domain
    1. Since the Management Domain is the entry point into COSMOS, it needs to address Authentication.
  2. Data Broker
    1. Since the Data Broker "knows" about all the MDRs and Data Manager, it should be used to enforce / implement Authorization, i.e. role-based security
  3. Data Managers and MDRs
    1. Should the access interfaces for the Data Managers and MDRs implement any security paradigm?
  4. Visualization
    1. Should the visulization interfaces implement any security paradigm?

Authentication

COSMOS must support user authentication and also support an SSO paradigm.

Authorization

COSMOS will need to support the roles identified in http://wiki.eclipse.org/COSMOS_Use_Cases. Additional roles may be implemented by the Security Provider used by the adopter.

Encryption

COSMOS will not encrypt any data while it is "at rest" in and MDR. This is something that the MDR / repository in question should own and control. However, COSMOS will be responsible for encrypting the queries and result sets as they flow through the COSMOS components, e.g. Broker / Domain / etc.

Task Breakdown

The following section includes the tasks required to complete this enhancement:

  1. Define the full scope of Security for COSMOS
  2. Open downstream ERs to be completed in later iterations

References

  1. WS-Security -- http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss
  2. XACML -- http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml

Open Issues/Questions

All reviewer feedback should go in the Talk page for 209337.

  • How much effort should be expended in addressing proprietary Security Providers?
  • How many downstream ERs do we need to open once this ER is complete?
  • Should XACML be used for implementing Authorization?
  • Should COSMOS use Security Tokens?
Retrieved from "https://wiki.eclipse.org/index.php?title=COSMOS_Design_209337&oldid=74530"

This page was last modified 14:56, 15 January 2008 by Jimmy Mohsin. Based on work by John Devine.

Back to the top