Shibboleth Enabling DAP Clients: Difference between revisions

From OPeNDAP Documentation
⧼opendap2-jumptonavigation⧽
Line 6: Line 6:
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 [https://wiki.shibboleth.net/confluence/display/SHIB2/ECP Enhanced Client or Proxy (ECP) profile]. The ECP profile was intended to provide Shibboleth authentication access for non-browser clients.
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 [https://wiki.shibboleth.net/confluence/display/SHIB2/ECP Enhanced Client or Proxy (ECP) profile]. The ECP profile was intended to provide Shibboleth authentication access for non-browser clients.


=== Summary ===
=== Basic modifications to OpenDAP clients ===
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 <tt>''application/vnd.paos+xml''</tt> in the <tt>''Accept''</tt> header and by including the <tt>''PAOS''</tt> header. For a client that is requesting a netcdf-3 response for a DAP resource the request headers would include:
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 <tt>''application/vnd.paos+xml''</tt> in the <tt>''Accept''</tt> header and by including the <tt>''PAOS''</tt> header. For a client that is requesting a netcdf-3 response for a DAP resource the request headers would include:


Line 15: Line 15:


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 <tt>''Content-Type''</tt> header set to <tt>''application/vnd.paos+xml''</tt> which indicates to the client that it needs to process the response as a Shibboleth ECP profile exchange.
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 <tt>''Content-Type''</tt> header set to <tt>''application/vnd.paos+xml''</tt> which indicates to the client that it needs to process the response as a Shibboleth ECP profile exchange.
In summary, to support Shibboleth, an OpenDAP client should include the two headers shown above in every out-bound request and be prepared to process an 'ECP profile' exchange as the result of every response - similar to the way OpenDAP clients must detect error responses that may come back from any request.


=== Details ===
=== Details ===

Revision as of 19:03, 1 May 2015

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.

Basic modifications to OpenDAP clients

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 by including the PAOS header. 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.

In summary, to support Shibboleth, an OpenDAP client should include the two headers shown above in every out-bound request and be prepared to process an 'ECP profile' exchange as the result of every response - similar to the way OpenDAP clients must detect error responses that may come back from any request.

Details

The details of the exchange are documented on the Shibboleth wiki here: https://wiki.shibboleth.net/confluence/display/CONCEPT/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.