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

COSMOS Design 231400

Revision as of 13:34, 20 May 2008 by Jim.gyng.com (Talk | contribs) (Use Case : Integrating a non-COSMOS MDR that requires a authentication (login-id and password))

Change History

Name: Date: Revised Sections:
Jimmy Mohsin 05/16/2008
  • Initial version, first pass at requirements for November
Bill Muldoon 05/19/2008
  • Added some design details

Workload Estimation

Rough workload estimate in person weeks
Process Sizing Names of people doing the work
Design .25 Jimmy Mohsin, Bill Muldoon, Martin Simmonds, et al
Code .25 Bill Muldoon
Test .25 Bill Muldoon
Documentation .25
Build and infrastructure
Code review, etc.*
TOTAL 1

'* - includes other committer work (e.g. check-in, contribution tracking)

Purpose

We need a simple implementation that supports authentication ONLY (no authorization, encryption is nice to have). One of our initial adopter products has a web service that needs three parameters: login, password, and the (graph) query string. We need to add login-id/password support to COSMOS.

Requirements

Please note that this part of Security implementation will be completed by November 2008.

Use Case : Integrating a non-COSMOS MDR that requires a authentication (login-id and password)

Not complete - Need to complete first phase before Novembr 2008. Tentative target: i12

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)

Actor: non-COSMOS MDR

Description: A non-COSMOS MDR requires a plain text login-id and password before it can fulfill queries / registration / deregistration.

  1. System Administrator opens the COSMOS UI, which displays all the data managers and MDR's
  2. System Administrator selects the MDR she wishes to take offline (or online)
  3. System Administrator updates the status of the MDR

Enhancements: 231400


Design

COSMOS Application <---> COSMOS Client <---> non-COSMOS MDR

The COSMOS Application uses the COSMOS client interface to invoke the services of a non-COSMOS MDR which requires authentication:

  1. Application obtains the username and password from the user.
  2. Application initializes the COSMOS client CMDBf Query Service with the endpoint of the MDR (obtained from the Broker).
  3. Application passes the username/password to the COSMOS CMDBf Query Service and invokes the graphQuery operation with a query
  4. The COSMOS CMDBf Query Service constructs a graphQuery request with a SOAP body that contains the query. If the username/pasword was supplied, it adds a SOAP header to the request containing the username/password values. It sends the graphQuery request to the MDR endpoint.
  5. The non-COSMOS MDR authenticates the graphQuery request using the username/password in the SOAP header.

COSMOS Application

Each client application is responsible for obtaining the username and password values from the user.

COSMOS Client application

The COSMOS client application supports commands that accept the username/password values and SOAP version number. For example:

COSMOS> set username mickey
COSMOS> set password mouse
COSMOS> set soapversion 11
COSMOS> graphQuery hostname mdrname C:\COSMOS\CMDBf\query_all.xml

COSMOS UI

The COSMOS UI presents the user with a dialog prompting for the username and password. (Details to be determined)


COSMOS Client

The COSMOS client CMDBf Query Service interface allows the client to specify the username and password:

public void setUsername(String username)
public void setPassword(String password)

An additional interface for the SOAP version is available for non-COSMOS MDRs which support SOAP11:

public void setSoapVersion(int soapVersion)


non-COSMOS MDR

The non-COSMOS MDR extracts the username and password from the SOAP header and authenticates the request.


SOAP example with Security header

<?xml version='1.0' encoding='UTF-8'?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
	<soapenv:Header>
		<sec:securityHeader xmlns:sec="http://schemas.xmlsoap.org/soap/envelope/" sec:mustUnderstand="0">
			<sec:username>mickey</sec:username>
			<sec:password>mouse</sec:password>
		</sec:securityHeader>
	</soapenv:Header>
	<soapenv:Body>
		<s:query xmlns:s="http://cmdbf.org/schema/1-0-0/datamodel">
			<s:itemTemplate id="AllCIs" suppressFromResult="false" />
		</s:query>
	</soapenv:Body>
</soapenv:Envelope>


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?

Back to the top