Changes between Initial Version and Version 1 of TI12_Security/NDG/UseCases/DataProviderDeployment

23/01/07 13:19:29 (15 years ago)



  • TI12_Security/NDG/UseCases/DataProviderDeployment

    v1 v1  
     1'''Location: [wiki:SecurityTeam]/[wiki:SecurityTeam/UseCases UseCases]/DataProviderDeployment''' 
     3= Data Provider Deployment of NDG Security = 
     5== Description == 
     6The steps required for a new data provider to deploy NDG Security 
     8== Actors == 
     9 * Data Provider 
     10 * Data Provider systems administrator responsible for deployment 
     11 * Data Provider stakeholders 
     12 * NDG Security support representative - help data provider with deployment 
     13 * [Other NDG Data Provider systems administrators to negotiate role mapping agreements] 
     14 * Data Provider Web Server 
     15 * Attribute Authority WS 
     16 * Session Manager WS 
     17 * Gatekeeper WSs 
     18 * Logging WS 
     19 * !MyProxy 
     20 * Credential Repository Database 
     22== Assumptions == 
     24== Triggers == 
     25A new data provider wants to enable NDG security for access control to their data. 
     27== Outcome == 
     28Data provider secures datasets with NDG security 
     30== Normal Course == 
     31 1. Review System Architecture (NDG security person to liase with data provider systems administrator and other stakeholders) 
     32 1. Analyse data provider's requirements - which NDG Security components are needed to satisfy the proposed use? (agree between data provider systems administrator with NDG security support person).  Issues to consider: 
     33   1. Does the data provider need to control access to resources? - YES ->  
     34     * deploy an Attribute Authority WS 
     35     * deploy Gatekeeper WSs to control access to each resource 
     36     * what other NDG components are to be deployed and how will they interface with NDG Security e.g. Data Extractor, Data Delivery tool, NDG Browse. 
     37   1. Data Provider supports a list of users? - YES ->  
     38     * deploy !MyProxy - if so use NDG CA or alternative? 
     39     * determine interface for user registration - web based or otherwise?  When users are registered how long will their certificates be set to last? 
     40     * Deploy NDG enabled user login - supports authentication redirect request from data provider resource in another host domain 
     41   1. Is a roles mechanism in place to control access to resources? - YES ->  
     42     * arrange to write a custom interface to the Attribute Authority to map username to role entitlement 
     43     * custom interface for roles interface required? 
     44   1. Is data to be shared with other NDG providers? - YES ->  
     45     * deploy Attribute Authority WS  
     46     * agree role mapping by liasing with other data providers about the roles they publish and what they mean 
     47     * Publish a roles list for ''this'' data provider so that other NDG data providers can set up mappings to allow ''this'' data provider's users to access their resources 
     48   1. Do they wish to support session management or browser based access to resources? - YES ->  
     49     * deploy a Session Manager WS 
     50     * user interface to user Credential Wallet - enable user to determine which Attribute Certificate to use to access which data. 
     51   1. Is a Session Manager needed? - YES -> deploy a Credential Repository database 
     52   1. Deploy Credential Repository? - YES -> deploy SQLObject supported database e.g. MySQL or PostgreSQL ''OR'' write custom data provider interface to database e.g. Oracle. 
     53   1. Is system logging required? - YES -> deploy Logging WS. 
     54 1. Determine Hardware requirements and system configuration 
     55   1. Check for hardware available for NDG components.   
     56     * NDG Security currently requires Redhat Enterprise AS3 / AS4 
     57     * Note requirements for !MyProxy 
     58     * Judge requirements based on expected traffic to data provider site and data provider security policy and any NDG wide security policies. 
     59   1. Identify target machine(s) - considering the security implications: !MyProxy holds user public/private keys, Credential Repository database stores user session cached Attribute Certificates 
     60   1. Identify web server to deploy security WSDLs 
     61   1. What budget is available for new hardware? 
     62   1. Consider firewall configuration - run components inside or outside firewall? 
     63     * !MyProxy ''must'' be inside 
     64     * Session Manager inside?  
     65       * NO -> an opening in the firewall is required for the Session Manager's port 
     66       * YES -> the connection between it and the Credential Repository must be secure 
     67     * Likewise Attribute Authority inside? 
     68       * YES -> connection to data providers user to roles interface must be seucre e.g. connection to data provider user database? 
     69       * NO -> an opening in the firewall is required for the Attribute Authority's port 
     70     * Firewall and any data provider web proxy settings must enable services of other data providers to be visible e.g. the Attribute Authority of a trusted host when brokering a user mapped Attribute Certificate 
     71 1. Purchase new Hardware purchase as required e.g. a dedicated server for !MyProxy? 
     72 1. Install NDG security components on target hardware 
     73 1. Install security WS WSDLs and NDG enabled login CGI on web server 
     74 1. Deploy NTP for synchronisation of certificate issue and expiry times between different NDG security enabled hosts. 
     75 1. Education and training - for data provider users and data administrators  
     76 1. Determine ongoing maintenance strategy - NDG security is a living system which requires monitoring and updates.