Shibboleth Developers

["Howard Gilbert" <>]

> 4) suggested by Howard Gilbert from yale  -- leveraging SOAP
> forwarding capabilities 
> 
> Pro's: ?? (Howard -- please help here!)

This is a message oriented rather than a session oriented approach, although
it can be used as a front end to obtain some session credentials to
subsequently establish a session.

SOAP is designed as a message wrapping and forwarding protocol. You start
with some core XML object wrapped in a SOAP envelop. The message goes out
through a pipeline that may be implemented by filter layers in the
application or by processing services in an institution. They examine,
remove, and add headers to the base message. The final SOAP message is
transmitted across the network where it (generally speaking) goes through a
sequence of processing stations and layers that match the sending sequence
but operate in reverse order.

In an imaginary business model, my application creates a request to purchase
some items. I forward it to Yale's Purchasing computer, which verifies I am
using the lowest cost vendor. It forwards it to Yale's accounting system
which verifies that my account has money. At this point an internal account
code and billing address might be replaced with a global accounting code and
address. This is then sent to a machine that digitally signs the PO as an
official document of Yale and sends it to the vendor. At the vendor a
computer verifies the signature based on Yale's public certificate, and
forwards the request to credit approval. Credit approval verifies Yale's
credit. It is then sent to Order Entry to be entered into the system.

Now apply this to cross-system authentication. I have an application that
may be authenticated at Yale in any of several different ways (X 509
certificate, Kerberos service account, whatever). This credential has no
global meaning but can be used at Yale. In any of the other models, I have
to use this local credential to obtain some global credential that I can
apply to my message or session so that someone else will believe it. But the
other model is for me to use my credential on some unspecified protocol to
transmit my Yale-authenticated SOAP message to the (hypothetical) Yale
ShibSigner component. This component uses local authentication to verify and
identify me, then removes this local header and replaces it with a header
containing some SAML assertion. Whether this is the Handle Assertion, or
includes some Attribute Assertion we have to think about. The assertion is
signed by Yale. The SOAP packet, Yale assertion and my original object, is
then sent to the ShibConsumer at the Target. It unwraps the Shib header,
processes its contents, and forwards the original contents over a
target-local protocol.

I trust my ShibSigner and I can prove my identity to it. You don't need to
know how I prove it. That's a Yale thing.
Your ShibConsumer trusts Yale's public certificate and therefore anything
signed by the ShibSigner, but only to believe that the content of the
ShibSOAPHeader is an official document of Yale. If the header says I am a
member of the staff, that is an official assertion of Yale. The content of
the envelop (the original object) is granted only as much trust as you give
to any other Yale staff member. The ShibConsumer alters the header and may
sign it before forwarding it to the application. The application knows that
the ShibConsumer asserts that the attributes have been verified by Yale. The
application trusts its own ShibConsumer, but does not necessarily trust me
or need to know Yale's certificates or keys. While the ShibConsumer might
sign the message it sends to the application, it could prove its identity
with an SSL session or any other target-local convention. I don't need to
know that part.

If you plan to create a session, then you need to gather global credentials
in advance and present them with the session. If you only generate a
message, however, then you can use SOAP forwarding technology so the message
acquires credentials on the way up and verfies those credentials on the way
down. That's a more accurate reflection of the structural nature of the
trust and authority in and between the institutions.

Having said this, I agree that SOAP and Web Services, although the subject
of unprecedented hype throughout the industry, have taken a long time and
not reached wide use. This proposal is somewhat forward looking and my not
reflect the highest priority now. I think we can outline the specs, make
sure that nothing else we do precludes it, and then put it on the back
burner unless requirements or support make it higher priority. If we don't
have a strategy for this use case, however, we are missing some important
sizzle. People may care that we have a plan long before they care if we have
the code.