Shibboleth Developers

["Scott Cantor" <>]

> In our discussion on the 17th, it came up that the nsdl was the first 
> group so far to talk about using shibb attributes for things 
> other than authorization.

Not entirely accurate; I definitely plan to, I just haven't been that
vocal about it. I think the real distinction with nsdl is that you're
talking about information that isn't obviously the responsibility of the
origin site to maintain (unlike, say, email address or something like
that).

> It would be nice if we could either hook into this 
> channel or the eventual cache that the RM uses.  What do you 
> think about the possibility of the SHAR stuffing the attributes in a
> database and simply redirecting to the RM?  The database effectively 
> becomes the RM's cache, but is also available to other programs.  I am
> sure that this cache would be relatively small, so the database could
be
> lightweight and in-memory.

Maybe I'm not understanding the question, but let me try and summarize
my position (this addresses some issues we talked about on today's call
too).

When you talk about a web resource manager, you basically have three
different scenarios to look at, or perhaps a combination of them.

1. The RM is part of the web server process (eg. .htaccess/mod_auth)

2. The RM is part of the entity servicing the HTTP request (eg. inside
the web application itself, may be inside or outside the web server
process)

3. The RM is a stand-alone component that receives queries and returns
authorization decisions (eg. SAML authz decision authority)

None of these is really consistent with any notion of "redirecting" to
an RM, though that terminology was used in Shibboleth early on. I did my
best to try and replace it with more accurate text. The web server never
gives up control of the processing sequence until it passes control to
the resource and says "send back what you will" (assuming it even gets
that far). If the resource acts as an RM or a proxy, or whatever, that's
not relevant to the web server by that point, which is just waiting for
the signal to close out the HTTP response.

It is the intent of the Shibboleth architecture to define a standard
format for dealing with #2 (ie. HTTP request headers that will contain
attribute data). We haven't done this yet, but we're about ready to get
it done.

It is also the intent of the initial Shibboleth implementation to build
at least a prototype RM inside the web server request chain to evaluate
simple policies, but that's not a "standard" part of the architecture.

Lugging the SAML machinery around will eventually help should somebody
decide they want to do #3, but we haven't discussed it.

Now, what if the attributes/data are not being used to decide access but
for some application-specific purpose? Obviously scenarios 1 and 3
aren't relevant, and we're talking specifically about how to get the
data into the application itself.

While it's theoretically possible for the web server to share data
directly with the servicing entity (in the in-process case especially),
this isn't done very often anymore. It's basically the old proprietary
server plugin model that is used to implement things like Shibboleth,
and application servers like ASP, Cold Fusion, and PHP, but not to
implement applications directly.

Mostly, there just isn't any good reason to do it. There's an
established way for a web server to share data with the applications it
hosts, or for a proxy to pass information downstream, and we'd be much
better off sticking to it. Your applications should be much easier to
build that way as well.

-- Scott

------------------------------------------------------mace-shib-design-+
For list utilities, archives, subscribe, unsubscribe, etc. please visit the
ListProc web interface at 

    http://archives.internet2.edu/

------------------------------------------------------mace-shib-design--