Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "COSMOS Design 231400"
Jim.gyng.com (Talk | contribs) (→Use Case : Securing the webUI, COSMOS client, COSMOS Broker, and Data Manager / MDR via a single end-to-end solution) |
Jim.gyng.com (Talk | contribs) (→Use Case : A Single Sign ON approach for COSMOS) |
||
Line 67: | Line 67: | ||
− | |||
− | |||
==How to implement this== | ==How to implement this== |
Revision as of 11:23, 16 May 2008
Contents
Change History
Name: | Date: | Revised Sections: |
---|---|---|
Jimmy Mohsin | 05/16/2008 |
|
Bill Muldoon | 05/19/2008 |
|
Workload Estimation
Process | Sizing | Names of people doing the work |
---|---|---|
Design | Jimmy Mohsin, Bill Muldoon, Martin Simmonds, et al | |
Code | ||
Test | ||
Documentation | ||
Build and infrastructure | ||
Code review, etc.* | ||
TOTAL |
'* - includes other committer work (e.g. check-in, contribution tracking)
Purpose
The COSMOS Security solution will be implementation in multiple phases. This overall solution will address Authentication, Authorization, and Encryption at the MDR, Broker, and UI/Client level. There is also a short term (November 2008 go live) requirement to have a an MDR-level authentication in place from CA. The Security solution will also need to address a single sign-on.
Requirements
There are a number of use cases for this design. Please note that the Security implementation will be completed in two or more phases.
Use Case : Integrating a non-COSMOS MDR that requires a authentication (login-id / password)
This use case addresses the situation where a non-COSMOS MDR requires a plain-text login-id and password. This use case will be fulfilled by ER 231400 (http://bugs.eclipse.org/bugs/show_bug.cgi?id=231400)
How to implement this
Design
This section should only list high level design considerations for Security. Detail design should reside in the "child" ERs.
Current Issues
- Which use cases are relevant for Higgins?
- Given our timeframes, should we do a simple / custom authentication implementation for now, and bring in Higgins later when we have elaborate security requirements? Does anyone have any additional requirements at this juncture that require a 2008 delivery?
- Is Higgins designed for a limited-scope Security implementation that only requires authentication?
- Has anyone utilized Higgins for a similar scenario in conjunction with another open source (or corporate) project?