Shibboleth Enabling DAP Clients

From OPeNDAP Documentation
Revision as of 23:53, 20 April 2015 by Jimg (talk | contribs) (→‎Summary)
⧼opendap2-jumptonavigation⧽

Overview

Most DAP clients are capable of dealing with HTTP BASIC Authentication situations. However, Shibboleth presents a particular challenge because it does not adhere to regular HTTP behavior in that it doesn't challenge the clients with a returned 401 status when a requested resource requires authentication for access. Rather, Shibboleth initiates a series of 302 redirects that take the client to an authentication web form which is returned with a status of 200. And even if the client insists on presenting its credentials to Shibboleth using HTTP BAsic authentication this effort will be ignored.

The Fix

The way to enable a client to work with Shibboleth require that both the Shibboleth Service Provider (SP) and Identity Provider (IdP) have enabled the Enhanced Client or Proxy (ECP) profile. The ECP profile was intended to provide Shibboleth authentication access for non-browser clients.

Summary

Since the client may never know when it will encounter a Shibboleth protected resource it must indicate with every request that it is capable of engaging the server in the ECP profile exchange. This is done by including the mime type application/vnd.paos+xml in the Accept header and also a special header PAOS whose value is set to: ver="urn:liberty:paos:2003-08";"urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp". So for a client that is requesting a netcdf-3 response for a DAP resource the request headers would include:

Accept:application/x-netcdf; application/vnd.paos+xml
PAOS:ver="urn:liberty:paos:2003-08";"urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp"

When the requested resource is protected by Shibboleth this will cause the server to initiate the ECP profile flow by returning a document with the Content-Type header set to application/vnd.paos+xml which indicates to the client that it needs to process the response as a Shibboleth ECP profile exchange and proceed with getting authenticated.

Details

The details of the exchange are documented on the Shibboleth wikie here: https://wiki.shibboleth.net/confluence/display/SHIB2/ECP and in the specification of the ECP profile exchange here: http://docs.oasis-open.org/security/saml/Post2.0/saml-ecp/v2.0/cs01/

A sample bash shell program that utilizes curl to perform the access and authentication exchange can be found here: https://wiki.shibboleth.net/confluence/download/attachments/4358416/ecp.sh?api=v2

If possible we recommend using a library that implements the details of this when enabling a client application.