Changes between Initial Version and Version 1 of MashMyData

05/07/10 10:46:40 (11 years ago)



  • MashMyData

    v1 v1  
     1= !MashMyData = 
     3These pages are concerned with the security model for MashMyData. 
     5== Requirements == 
     6Users can access a Portal which enables them to upload their own data and combine it with other datasets pulled from data services at other sites.  !MashMyData will make use of the software infrastructure deployed at CEDA which has been developed for Earth System Grid / CMIP5 (Coupled Model Intercompariosn Project, Phase 5).  This has it's own security model which uses OpenID and PKI based authentication and single sign on, and OpenID AX and SAML for attribute management and SAML for authorisation interfaces.   
     8User authentication to the Portal is expected to OpenID based.  The Portal's ability to access datasets from other sites on the user's behalf implies delegation: the portal and others services are delegated the authority from the user to act on their behalf. 
     10== Use Cases == 
     11User logs into Portal and requests CEDA's OGC WPS (Web Processing Service), perform some operation on multiple datasets.  The WPS itself will access another CEDA OPeNDAP service and perhaps other OPeNDAP services in the federation. 
     13== Solutions for Access Control == 
     14 1. Static PKI based: No delegation, services authenticate with other services based on their static PKI based credentials. 
     15   * Pros: simple, will work with the current ESG security infrastructure 
     16   * Cons: no concept of delegation, a given service A accessed by another B has no idea who the user is who service A is acting on behalf of.  It only knows the identity of A.  Consequently authorisation policy can only be coarse grained. 
     17 1. [ Proxy certificates]: There are different ways of implementing this: 
     18   i. With !MyProxy: use !MyProxy as a credential store.  The portal uploads a user credential to (a) !MyProxy server(s) which services can access on the users behalf and use to obtain delegated user credentials in order to access other secured services.  - Service A, is trusted by the !MyProxy server C.  Before accessing service B, it requests a delegated user credential from C.  It uses the user credential to access service B. 
     19   i. Without !MyProxy: the principle of services obtaining delegated credentials remains the same but there is no !MyProxy server to acts as a broker of user credentials 
     20   * Pros: Well tried and tested solution in the Grid community, enables integration with other Grids.  ESG Security already supports PKI based authentication, but, 
     21   * Cons: Currently no ESG Java implementation to support authentication using proxy certificates.  A filter would need to be implemented.  CEDA's Python implementation ''does'' already support proxy certificates. 
     22 1. OAuth: