Shibboleth Developers

[Peter Williams <>]

Part of the reason I'm focusing on Shibboleth SP is its core's support for ECP. Not all our work is OpenID2 outreach to the data syndication networks. Much of it is hardcore data processing - ultimately requiring application of the full SAML2 state machine in a loosely-coupled hub-spoke data sharing network conformed of many players and many implementation cultures. As our commercial SAML2 vendor's server does not support PAOS properly, Shib2's more complete support for ECP may yet address realty needs.

 

Let me summarize use cases and design work, as (non-academic use case) shareback:-

 

US realty is a data-intensive operating environment, heavily invested in both server-side database-driven web-applications and high-throughput http-data services. SAML2 is being used here in two scenarios today:-

 

1. designed adhoc, quickly and merely so something works in production, a backroom http connection from a data consumer thread makes an http web service call to collect state property tax and GIS information from a data provider's repository, using a custom interface. The data sets are subsequently aggregated, and geo-tagged for use in interactive mapping applications. Initially the requests/responses were bound to SOAP1.1. However, we moved the request binding to a URI and specified a classical XML Response. This arrangement allows the request arguments to be transferred as the TargetResource value indicated during an IDP-initiated WebSSO interaction between data consumer and data provider. A consumer-provided (SAMl2-encrypted) attribute provides for the indication of a nonce, that the provider uses to authenticate "nonce-signed" data responses back to the data consumer.

 

2. more properly designed in standards committee process (known as RETS standardization), a RETS URI-based data server (whose sessions' transactions exploit the digest auth standard for data-origin authentication) can now offer a PAOS endpoint in addition to its existing full-lifecycle URL services (loginURL...searchURL, updateURL... logoutURL). The idea is that a RETS User Agent is an ECP client, bridging the SOAP request received from the (loginURL-less) RETS data server to a SOAP-endpoint on an IDP. The party playing the IDP role offers SOAP endpoints attached to another centralized RETS server - with only a loginURL native endpoint. In the return flow, the SAML assertion translates the IDP RETS servers's RETS_session into a RETS_session on the data server. As an SP, receipt of an digest-auth authenticated logout request by the RETS server acting in the data provider role induces SP-initiated SLO, in a backroom SAML2 flow.

 

1 exists, and data flows in the wild. Its a klutz. Its all I could do with a willing SP partner, who however had a budget of "2 days programmer time".

 

2 exists on paper, and data only flows in the lab. The community's desire is to make it standard realty practice, cross-vendor. Adoption probably depends on (i) the continuing commoditization of SAML2 technology, (iii) simpler implementations of SAML2 in the likes of PHP, (iii) wider acceptance of ECP

 

These uses of SAML2 are of course trivial compared to projects that are massively invested in SAML (e.g. backroom telco, and backroom travel). Understand however, that realty budgets expended on exploiting websso are a tiny fraction of what others spend on their infrastructure projects. In general, realty folks are using open source implementations with no formal support budgets, or host the SAML endpoints for the spoke's web applications remotely.

 

PS The RETS standard has also specified its remote operations using formal SOAP bindings in addition to URI bindings. WS-Trust shall be used to obtain SAML tokens, and ws-security is used to embed tokens in the WS-* envelopes. No known RETS-integration implementation actually exists, though several parties have used Microsoft .NET 3.5 stack code to prove the concept of obtaining/signaling SAML tokens using WS-Trust/WS-Security.

 

---

From: Chad La Joie
Sent: Wed 4/16/2008 3:07 AM
To:
Subject: Re: Web services

I also gave a talk on this subject at McShib on Friday.  Ian recorded 
the audio so I believe Andy is planning on putting up the slides and 
audio on the McShib site.

Also, a claim I've made before is that most of the people/frameworks 
that claim they are ready to do SAML and web services are, in fact, not 
ready.  So one of the things I've committed to do is document, and write 
up some very basic code, to get SAML from the IdP and into the hands of 
the developers.  The idea being that this will allow people to move on 
to the hard, nothing-to-with-shib, part of the problem; getting their 
frameworks/apps to actually work with SAML.

Josh Howlett wrote:
> I was curious what support exists and/or is planned (if anything) for
> web services? The Infocard and WS-Fed work implies some existing
> framework for WS* that might be extended to support web services more
> generally.
> 
> (I'm aware that Chad blogged about this recently
> (http://blog.expatchad.info/articles/2007/12); I recommend that anyone
> else interested in this has a read of it)
> 
> Many thanks, josh.
> 
> 
> JANET(UK) is a trading name of The JNT Association, a company limited
> by guarantee which is registered in England under No. 2881024 
> and whose Registered Office is at Lumen House, Library Avenue,
> Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG
> 

-- 
SWITCH
Serving Swiss Universities
--------------------------
Chad La Joie, Software Engineer, Security
Werdstrasse 2, P.O. Box, 8021 Zürich, Switzerland
phone +41 44 268 15 75, fax +41 44 268 15 68
, http://www.switch.ch