COSMOS Design 231400

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, 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 an 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 authentication (login-id and password)

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

Actor: COSMOS application

Description: The COSMOS application needs to provide a login-id and password to a non-COSMOS MDR before it can fulfill queries / registration / deregistration. The login-id and password does not need to be encypted.

1. COSMOS Application receives the authentication credentials from the User.
2. COSMOS Application passes on these credentials to the non-COSMOS MDR alongwith with the query or registration request.
3. COSMOS Appliction notifies the user in case of invalid credentials. Otherwise, the request is fulfilled.

Enhancements: 231400 (i12)

Use Case : Securing the COSMOS webUI via simple authentication (login-id and password)

Actor: COSMOS end user

Description: The COSMOS end user utilizes the COSMOS webUI to interface with the various services provided by an MDR or non-MDR. Each request to a MDR or non-MDR may require authentication. It should be possible to group requests to a particular authentication session. For example, requests to view service meta data and submit CMDB queries to a specific MDR can use the same authentication credentials. The user should not be prompted each time a request is sent to the MDR.

Enhancements: 231400 (i12)

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

Lets first consider the existing UI architecture components:

1. UI widget - dojo widget that submits a request to a server side component
2. Query Object - A javascript object that constructs the HTTP request that contains input parameters
3. UIContext - context object that contains helper apis to submit request to a server side component
4. Outputter - service side java component that receives the request and generates a response.

Notice the a query object is constructed and passed to the UIContext class. The UIContext will process the query object and send a request to the server component. The server component will return a response. The response will be sent to the query object and eventually returned to the dojo widget.

The query objects decouples the binding logic from the ui widget. We can make use of this architecture to prompt the user for a password and username before submitting a request to the server.

We can define the following security object that will bind the security credential to the request.

dojo.declare(
   "org.eclipse.cosmos.provisional.dr.ps.components.utility.SecurityObject",
	// superclass	
	null,
	{
                username:"",
                password:"",
                //Basic Constructor
		constructor: function(params){
			dojo.mixin(this,params);
		},
                //we can bind user name and password to the request parameters
		bindInput: function(data, reqParams){		
                      return reqParams;
		}
		}
); 

dojo.declare(

  "org.eclipse.cosmos.provisional.dr.ps.components.utility.BasicQuery",

// superclass null, {

               //URL to serverside component

queryHandler: null,

               //Post data input parameters

postData: "",

               //Basic Constructor

constructor: function(params){ dojo.mixin(this,params); },

               //can bind additional input parameter based on the data object that the query object is associated with

bindInput: function(data, callbackMethod){ callbackMethod(this.postData); },

               //api that is called when a response is recieved

render: function(response){ return response; },

               //api that is called when the query object has been processed completely

onComplete: function(response){ } } );

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?