Shibboleth Developers

["Howard Gilbert" <>]

I am not sure about the details of the question because I don't know all the
acronyms. Let me fill in a few details that might provide answers:

First, the pipeline processing model relieves the application of the burden
of knowing the details of protocols and certificates. If it trusts the
preprocessing done by the earlier layers, then it can rely on a header
assertion that this request is cleared for sensitive material or is not.
This allows system programmers to write the hard stuff, and application
programmers to inherit its benefits.

There is no magic. If there is policy to enforce, then the policy has to be
written. A key point, however, is that in this system programs don't
transmit data themselves to any destination. Like the office mail system,
the data goes through shared "inbox" and "outbox" processing. If you were
willing to rely on programs tagging the data they sent, but were not willing
to rely on them applying policy properly, then an extra level of protection
would be for one pipeline stage in the processing of the reply to check the
security attribute of the data the application is trying to send against the
security profile implied by the headers of the processed original request
and to abort the transmission, and send an error message in its place, if
the destination profile doesn't match the requirements of the data.

Instead of the request/response model of RPC and conventional Web
applications, this type of application applies the event driven model of
User Interface programming to network distributed processes. When I send a
request, I do not necessarily expect that the response will be immediate.
There will probably be a short pro-forma response accepting the request. So
when the real reply is ready, it will probably be POST-ed to a URL target
contained in a header of the request.

A framework that allows the full implementation of this idea is the likely
content of Indigo, one of the three basic elements of Longhorn. However,
while the idea could be allowed to become arbitrarily complex, we don't have
to let it get that bad. If you keep things simple, it falls within the tools
currently available in Apache Axis or .NET.

> -----Original Message-----
> 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.