# Presentation: 553937

## NDG Security: Distributed Governance, Distributed Access Control, Distributed Data. 

**NDG Security: Distributed Governance, Distributed Access Control, Distributed Data.**** **

**+**

**+**

**+**

**+**

**+[**

**]=**

- Bryan Lawrence
- (on behalf of a big team)

**Notes:**
Introduce myself and Wendy and ask them to contact her.

## http://ndg.nerc.ac.uk

- British Atmospheric Data Centre

- British Oceanographic Data Centre

- Complexity + Volume + Remote Access = Grid Challenge

## NDG Assumptions

- No one would change their data storage systems!
- Need to support a wide range of “metadata-maturity”!
- No NDG-wide user management system possible.
- It is illegal to share user information without each and every user agreeing ...
- implies no way of having one virtual organisation with common user management!
- With a large enough group it is impossible to agree on common roles that could be associated with access control.
- ... but we want single-sign on ... and trust relationships between data providers ...

## Authentication and Authorisation

- Clean separation between concepts:
- Authentication
- Identity - Who you are
- Users are identified between data providers and services by means of Proxy Certificates
- Proxy Certificates issued by *MyProxy* services
- Users are identified between sessions at the same browser by means of a cookie which points to the location of a proxy certificate.
- Authorisation
- For a user: what you can do e.g. what data they can access
- For a data provider: how you determine what a user can and can’t do
- NDG Attribute Certificates determine access
- Attribute Certificates issued by *AttributeAuthorities.*

## Controlling Access to Data

- NDG Attribute Certificate
- Issued to a user by an ATTRIBUTE-AUTHORITY
- Contain roles – these determine what the user is authorised to do
- An attribute authority determines on behalf of a data provider what roles a user has, from the list of roles known to that data provider
-  e.g. badc has the coapec role which allows access to the coapec data set. If a badc user has a badc issued Attribute Certificate containing coapec then badc will grant access.
- XML based
- Issued by the Attribute Authorities on receipt of a valid user *Proxy Certificate*
- Digitally signed by the Attribute Authority issuer
- Contain the user’s identity expressed as a Distinguished Name as derived from the user’s Proxy Certificate
- Has a timebound validity

## Key Concepts thus far

- All data providers deploy, or have access to, a *myproxy* database capable of delivering proxy certificates on request.
- All data providers deploy or have access to a *Session Manager* instance.
- No requirement for the myproxy to visible outside a firewall, access can be mediated by a Session Manager.
- All data providers secure resources by coupling resources to roles.
- There is no assumption that data providers share the same role names or role definitions.
- All data providers deploy, or have access to, *Attribute Authorities* that grant NDG Attribute Certificates to users based on their “rights”.

## TRUST

**TRUST**

**Trust between data providers is established by making BILATERAL agreements on role mapping!**

## Browser User Authentication

- Authenticate when trying to access a secured resource (which has role, AAwsdl).
- Pole AAwsdl for trusted host list (including self)
- Choose a login
- Application should redirect to a loginURL
- Login ...
- Login Service establishes an NDG Session Manager, and populates it with proxy certificate/
- LoginURL sets a cookie and redirects back to originator with cookie details in URL (if not local)
- (All redirections done with https)
- Originator sets cookie with session manager details
- Originator establishes local session manager session that knows about remote session manager via cookie contents.

## User Authorisation

**User Authorisation**

**UserSession**
**CredWallet**

**SessionManager WS**

**ProxyCert, reqAttCert**

**AttCert**

**sessionID and smWSDL**
**reqRole AAwsdl**

***Returned Proxy Cert. is kept in CredWallet of user’s UserSession instance***

**FIREWALL**

**(Installable Library)**

**Calls**

**Exploits reqAuthorisaton method**

**Local smClient talks to local SessionManager which may or may not talk to remote SessionManagers. Credential Wallet is populated with attribute certificates as needed. **

## How to Deploy a system

- What’s needed to represent ID?
- [User DataBase of some sort]
- [PKI/Proxy Certificates]
- [MyProxy Server]
- [Session Manager]
- What’s needed to grant access rights to a user?
- [Attribute Authority]
- [Session Manager]
- Some “database” binding resources to roles and AA

***[Indicate that a minimally configured data provider can use remote resources to provide these services]***

## Python Browser Application

**class YourClass:**
**    ****''' Dummy class encapsulating key ndg security concepts from a browser application developers perspective '''**
**    ****def __init__(self,stuff):**
**        ****...**
**        ****self.cookie=... #set cookie **
**        ****self.config=... #read from config file, includes local smWSDL ....**
**        ****self.makeGateway()**
**        ****...**
**    ****def makeGateway(self,cookie=None):**
**	****''' Make connection to NDG security and load what is necessary for **
**        ****an NDG cookie to be written '''**
**        ****#   - the requestURL so that a redirect can come back, and to pass**
**        ****#           any URL components which have come back from one ...**
**        ****#   - your local smWSDL address, and your cookie ...**
**	**
**        ****self.ndgGate=securityGateway(self.requestURL,self.cookie,self.config)**
**    ****def goforit(self):**
**       ****''' your actions ... trying to access a URI for which you may have constraints'''**
**        ****...**
**        ****if  constraints.exist:  **
**            ****result=self.ndgGate.check((role,AAwsdl))**
**            ****if result=='AccessGranted': **
**                 ****access=1**
**            ****else:**
**                 ****access=0**

## NDG Security Current Status

- NDG Started Phase 2 in 2006 with Alpha Stage milestone this week:
- Target secure data resource with NDG security
- Done (both for A and B metadata)
- Engineered NDG security into BBFTP ...
- Working prototype implemented in Python:
- Deployed at partner sites: British Oceanographic Data Centre, National Oceanography Centre Southampton, Plymouth Marine Lab and Centre for Ecology and Hydrology
- Supports single sign on
- Uses XML Signature and XML encryption but not WS-Security compliant (yet)
- Uses WSDL
- Open Source

## Security Next Steps

- WS interfaces need to be adapted to be compliant to WS-Security
- Produce Java implementation for DEWS
- Adapt ZSI Python WS libraries
- Possibly use LBL libraries – pyGridWare
- Latest status info: NDG Project Management *Trac* site (_[http://](http://proj.badc.rl.ac.uk/ndg/)__[proj](http://proj.badc.rl.ac.uk/ndg/)__[.](http://proj.badc.rl.ac.uk/ndg/)__[badc](http://proj.badc.rl.ac.uk/ndg/)__[.](http://proj.badc.rl.ac.uk/ndg/)__[rl](http://proj.badc.rl.ac.uk/ndg/)__[.ac.](http://proj.badc.rl.ac.uk/ndg/)__[uk](http://proj.badc.rl.ac.uk/ndg/)__[/](http://proj.badc.rl.ac.uk/ndg/)__[ndg](http://proj.badc.rl.ac.uk/ndg/)__[/](http://proj.badc.rl.ac.uk/ndg/)_)

## DEWS

**Department of Trade and Industry funding ...**
** ****health stream (new WFS)**
** ****Marine stream (new WCS based on GADS)**
** ****NDG Security**
** ****Prototype for commercial activity**

**Delivering Environmental Web Services**

## Current Status

## Architecture: NDG Metadata Taxonomy

**... ****not one schema, not one solution!**

**MOLES THREDDS**
**(... NMM, SENSORML etc)**

**CLADDIER**

## Architecture:

**Architecture:**
** ****Deployment**

## Architecture:

**Architecture:**
** ****Deployment**

## Architecture:

**Architecture:**
** ****Deployment**

## Architecture:

**Architecture:**
** ****Deployment**

## MOLES: implementation

- Core linking concept is the **deployment**

- Deployment

- Activity

- on behalf of an **Activity**

- of a **Data Production Tool**

- at an **Observation Station**

- that produces a **Data Entity**

- DataProductionTool

- ObservationStation

- Data Entity

- Each of the main metadata objects has security data attached to it. This means that this can be applied to queries on the metadata

- Links the metadata records into a structure that can be turned into a navigable structure

**Notes:**
Use of Xquery
Each record has its own security metadata attached, thus giving a degree of granularity to the security.

## NDG “Pseudo-Demo”

**EXPLOITING DISCOVERY WEB SERVICE**
**(running interface on my laptop last night)**

## More Browse

## MOLES Navigation

**Actually, this is where we plan to use NMM**

## MOLES to Secure Dx

## NDG Authentication

## Data Extractor

## Geosplat

## NDG Timeline

- NDG2 runs until September 2007:
- NDG-Alpha (June 2006)
- Not all components in place (particularly delivery broker)
- Not many (maybe only DX) products will be deployable by non-NDG participants
- (too much hard work installing things that haven’t been optimised for installation)
- Discovery portal will be (is now) usable, linking to NCAR data etc, but isn’t very user friendly (options not obvious etc).
- NDG-Beta (Feb 2007)
- Most components should work, but deployment of software may still be difficult by non-participants
- NDG-Prod (Jun 2007)
- Should be deployable and far more user friendly (spending from Feb-June working on deployment and friendliness, no new functionality)
- Last few months working on sustainability etc

**http://proj.badc.rl.ac.uk/trac/roadmap**