Skip to main content

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.

Jump to: navigation, search

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 along with 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 (or Registration) Service with the endpoint of the MDR (obtained from the Broker).
  3. Application passes the username/password to the COSMOS CMDBf Query (or Registration) Service and invokes the graphQuery (or register/deregister) operation
  4. The COSMOS CMDBf Query (or Registration) Service constructs a 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 request to the MDR endpoint.
  5. The non-COSMOS MDR authenticates the 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

Requirements

  1. Prompt the user for username and password before submitting a request to the server component
  2. Different username and passwords can be used to authenticate differnt request
  3. Subsequent requests should not prompt the user for the same username or password.

Current Architecture

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.

COSMOSSec1.jpg

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. Note that the password should be encrypted before binding 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, callbackMethod){		
                      callbackMethod("");
		},
                //return true if the security object should bind credentials to the request otherwise false is returned.
                canBind:function(data){
                      return false;
                }
	}
);

Consider a case where we want to prompt the user when a request is made to the following eprs:


We can define a list of security objects that will bind security parameters to a group of requests 

{
   securityObjects: [{ clazz: org.eclipse.cosmos.provisional.dr.ps.components.utility.ExampleSecurityObject},
                    { clazz: org.eclipse.cosmos.provisional.dr.ps.components.utility.StatSecurityObject}]
}

org.eclipse.cosmos.provisional.dr.ps.components.utility.ExampleSecurityObject defines a security object that will prompt the user if the epr contains the "/service/ExampleMdr" string: 

dojo.declare(
   "org.eclipse.cosmos.provisional.dr.ps.components.utility.ExampleSecurityObject",
	// superclass	
	[org.eclipse.cosmos.provisional.dr.ps.components.utility.SecurityObject],
	{
                //we can bind user name and password to the request parameters
		bindInput: function(data, callbackMethod){		
                      callbackMethod("&username="+this.username+"&password="+this.password);
		},
                //return true if the security object should bind credentials to the request otherwise false is returned.
                canBind:function(data){
                      if (data.epr){
                          //define regular expression rule to match EPR
                          return (data.epr.match(\b(\w)*/service/ExampleMdr(\w)*\b));
                      }
                      return false;
                }
	}
);

We can define a list of security objects that will bind security parameters to a group of requests 

{
   securityObjects: [{ clazz: org.eclipse.cosmos.provisional.dr.ps.components.utility.ExampleSecurityObject},
                    { clazz: org.eclipse.cosmos.provisional.dr.ps.components.utility.StatSecurityObject}]
}

org.eclipse.cosmos.provisional.dr.ps.components.utility.StatSecurityObject defines a security object that will prompt the user if the epr contains the "/service/StatDatamanager" string and the data.nodeClass is equal to "stat": 

dojo.declare(
   "org.eclipse.cosmos.provisional.dr.ps.components.utility.ExampleSecurityObject",
	// superclass	
	[org.eclipse.cosmos.provisional.dr.ps.components.utility.SecurityObject],
	{
                //we can bind user name and password to the request parameters
		bindInput: function(data, callbackMethod){		
                      callbackMethod("&username="+this.username+"&password="+this.password);
		},
                //return true if the security object should bind credentials to the request otherwise false is returned.
                canBind:function(data){
                      if (data.epr){
                          //define regular expression rule to match EPR
                          return ((data.epr.match(\b(\w)*/service/StatDatamanager\b)) && (data.nodeClass=="stat"));
                      }
                      return false;
                }
	}
);

Lets go through the steps to understand how the each component interacts with one another. Consider the case when the end user wants to submit a CMDBf query to the Example MDR.

COSMOSSec2.jpg

  1. The user constructs the query using the query builder and clicks submit
  2. A query object is constructed that binds the epr of the query service and the xml query document to the request
  3. Note that a security object is registered with the COSMOS UI. The security object runs its "canBind" function to determine if the user should be prompted.
  4. A dialog box is prompted to the user to enter the user name and password. The dialog box also adds an option to save the username and password so that the dialog box is not prompted after each request. Note that the Security object will save the username and password in memory. The password is encrypted using some form of encryption (e.g. MD5, etc.). The user name and password is also bounded to the query object request.
  5. The UIContext process the query and submits the HTTP request
  6. The HTTP request contains the query parameters and security credentials
  7. The HTTP request is received. The password is decrypted and used to authenticate the request. A return response is generated and passed back to the client. The widget renders the response.

A set of security objects can be registered with the COSMOS UI. A security object can be associated with a set of query request. Note that different security objects can utilize different security protocols. Also notice that the security object can cache the username and password. This will allow the user to specify the username and password once. Subsequent requests can reuse the cached username and password.

COSMOSSec3.jpg

Providing a generic Security Object

There have been discussions to define a security service on an MDR. This will allow the UI to determine if an MDR requires security authentication when sending a request to the MDR.

Similarly to the query service, an MDR can register a EPR that contains a security service. The following defines a namespace that indicates that the MDR supports a basic security model that requires a username and password. http://www.eclipse.org/cosmos/basicsecurity

In cases where more complex security authentication is required, a new namespace would be defined.

We can define a security object that checks if the MDR supports the security service as follows: 

dojo.declare(
   "org.eclipse.cosmos.provisional.dr.ps.components.utility.GenericSecurityObject",
	// superclass	
	[org.eclipse.cosmos.provisional.dr.ps.components.utility.SecurityObject],
	{
                //we can bind user name and password to the request parameters
		bindInput: function(data, callbackMethod){		
                     //prompt for user name and password
                     var dialog = new org.eclipse.cosmos.provisional.dr.ps.components.widget.SecurityDialog({reqParams: reqParams,callbackMethod:callbackMethod});
                     dialog.show();
		},
                //return true if the security object should bind credentials to the request otherwise false is returned.
                canBind:function(data){
                      //get the security epr
		      var securityEPR = this.UIContext.getService(data, "http://www.eclipse.org/cosmos/basicsecurity");
                      //does this mdr support security?
                      if (securityEPR){
                          return true;
                      }
                      return false;
                }
	}
);

Allow the end user to bind a security object to a Data Manager

Another approach is to allow the end user to associate a security object with a particular Data Manager.

A new menu option can be added to data manager node. The menu option will allow the user to associate credentials to the data manager node. If any request is sent to the particular data manager the associated credentials will be pass into the HTTP request.

COSMOS Client

The COSMOS client CMDBf Query Service interface (and Registration Service) 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?
  • The ui needs to encrypt the password using a encryption algorithm. Dojo contains MD5 encryption however there are ip issues using this algorithm that will not pass legal.
Retrieved from "https://wiki.eclipse.org/index.php?title=COSMOS_Design_231400&oldid=99597"

This page was last modified 10:05, 23 May 2008 by Eclipsepedia anonymous user Unnamed Poltroon.

Back to the top