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.
COSMOS Design 231400
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 | .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.
- COSMOS Application receives the authentication credentials from the User.
- COSMOS Application passes on these credentials to the non-COSMOS MDR alongwith with the query or registration request.
- 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:
- Application obtains the username and password from the user.
- Application initializes the COSMOS client CMDBf Query Service with the endpoint of the MDR (obtained from the Broker).
- Application passes the username/password to the COSMOS CMDBf Query Service and invokes the graphQuery operation with a query
- 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.
- 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:
- UI widget - dojo widget that submits a request to a server side component
- Query Object - A javascript object that constructs the HTTP request that contains input parameters
- UIContext - context object that contains helper apis to submit request to a server side component
- 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. 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, reqParams){ return reqParams; }, //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: http://bluesky:8080/axis2/service/StatDatamanager http://bluesky:8080/axis2/service/ExampleMdrDataManager http://bluesky:8080/axis2/service/ExampleMdrQueryService
We can define a list of security objects that will bind security parameters to a group of request
{ 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, reqParams){ return reqParams+"&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 request
{ 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, reqParams){ return reqParams+"&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; } } );
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?