wiki:T12_Security/ESG/SecuringOPeNDAP

Version 10 (modified by pjkersha, 9 years ago) (diff)

--

NDG Security

Home | Research | Architecture | Documentation | Downloads | Discussion | OMII-UK | ESG and IPCC AR5 | DEWS | Admin Quick Start


Security Layer for OPeNDAP Service

The Sequence Diagram below shows the series of steps for a HTTP client to access a secured OPeNDAP service. The User Agent could be a web browser, wget program or other HTTP client. A scenario is envisaged with a BADC Data Node hosting an OPeNDAP service. The Data Node has security middleware components which front the OPeNDAP application and intercept requests. The component architecture is assumed to be Python  WSGI based. Components in the web application middleware stack communicate with one another using WSGI.

The User Agent makes a request to the OPeNDAP service. This is intercepted by the Session Handler. This checks with the authorisation handler to see if the requested URI is a secured one. This is the case, so the Session Handler then checks to see if the user has a valid session cookie. The user does not so they are returned a redirect request to redirect them to the Authentication Handler.

The Authentication Handling filters are hosted as a separate BADC service running over SSL but in the same domain. (This consists of an OpenID Relying Party interface fronted with a filter to perform SSL client authentication if a client certificate is submitted). The handler receives the request over HTTPS and checks for a client certificate in the SSL handshake. If none is provided, the handler returns a HTTP 401 Unauthorised response but this also contains OpenID Relying Party interface. If the User Agent is a browser, the user can intervene and enter their OpenID URL and proceed with OpenID based sign in. In this case though, on receipt of the HTTP 401 Unauthorised response, the agent re-invokes the URL but this time passing a client certificate. For ESG, to enable compatibility between OpenID and certificate based authentication, the certificate contains the users OpenID URL embedded in a certificate extension. This extension is a SAML assertion.

The Authentication Handler, checks for a client certificate passed, and if present, authenticates based on this certificate. The certificate is accepted and the agent is returned a redirect response containing a session cookie. The agent invokes this redirect back to the original OPeNDAP URI it requested. This time, the Session Handler receives the request and finds a session cookie confirming the user has previously authenticated. It then passes the request to the Authorisation Handler.

The Authorisation Handler checks the security policy for the OPeNDAP service to find out which attributes constrain access and which Attribute Service to query to pull user attribute information. The Attribute Service, in this example is one hosted at PCMDI since the data is secured with an AR5 archive attribute. The service is queried passing the users OpenID URL. It returns a response asserting that this user has the AR5 archive attribute. The Authorisation Handler makes an authorisation decision authorising the user to access the requested OPeNDAP URI. It allows the user request through to the OPeNDAP application. This returns a response to the user.

source:TI12-security/trunk/NDGSecurity/documentation/esgInteroperabilityForIPCCar5/OPeNDAPAccessControlWithSSLClientAuthentication.png