Shibboleth Developers

[Keith Hazelton <>]

Howard:

Wondering if the following is a use case that could benefit from just 
the sort of SOAP forwarding you describe below:

Let's say I have a shib target that for some operations requires a 
higher level of assurance on the AuthN step.  Imagine, for example, a 
health info app that, before revealing some sensitive information, 
wants an assurance that only a medium LOA certificate per USHER or 
better would meet.  This is something I think we here would find useful 
before very long.

Would an approach like that below be a foundation on which to build 
into the app the ability to know the level of assurance of the current 
session and, at will, ask for a higher level.  Seems like you'd need a 
round trip all the way back to the WebISO login step with information 
flowing and being processed both directions.

          --Keith
______________________
On Wednesday, Dec 3, 2003, at 18:00 America/Chicago, Howard Gilbert 
wrote:

> > 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.
________________________________________________________
Keith Hazelton                  Senior IT Architect, UW-Madison
(608) 262-0771                  Division of Info. Technology
(608) 877-0977 (home)           1210 W. Dayton St., rm. 2164
http://arch.doit.wisc.edu/keith      Madison, WI  53706