Shibboleth Developers

["Howard Gilbert" <>]

[Original exchange appended at end]

Let me propose an alternative based on the fundamentals.

In any case where there is no Session (that is, this particular piece of
code is not operating in the context of a Session object containing at least
the AuthenticationAssertion from the POST data), then any application ID is
provisional. We are saying that we want application configuration
information and here is a string that may or may not represent a specific
applicationId from an <Application> element. In this case, if the string
doesn't match any of the special cases, then the "default" id for the
<Applications> element should be used to return the default application
configuration.

The only time things change (at least in my code as I followed the logic
around) is when ShibPOSTProfile processes an AuthenticationAssertion POST
and, if everything checks out, creates a Session object. At that point, the
Session object contains, among other things, an applicationId that
corresponded to the <Application> that was matched to this request by the
POST handling logic in the Servlet. That is, the Servlet will have taken
what it regards as the best guess for an applicationId, done a lookup, and
got back either a real matching <Application> or the "default" object.

This is the only point where something of importance is persistently
associated (bound by "applicationId" value) to the object constructed from
<Application(s)>. 

So I propose a rule that says:

* If a Session is bound to a particular applicationId and a subsequent
lookup fails to return an object with that id, then we can assume (because
it is the only way this can happen) that the configuration file
(shibboleth.xml) was changed and the new version was dynamically loaded and
the <Application> under which the Session was created was deleted by the
update. This probably should be logged.
* Once a Session is created, all references to applicationId and its
associated object must use the Session to get it.
* Any other environment is asking for abstract configuration information and
not a specific object. To all of these requests, it is permissible to map an
unknown id to "default" without comment.

This still leaves the question of recovery. Based on the observation that
deleting an <Application> would cause all subsequent Sessions to that
application to map to "default", I do not think it would be a mistake to
continue processing by re-associating the existing Session to the new
"default" Application object. Some Session properties would have already
been set from the old object, and they need not change. There would be a
change in pluggable providers (Metadata, Trust, AAP) that might or might not
have an effect. If the Attributes have not yet been fetched, then when they
are they will operate under the new pluggable providers. If they have
already been fetched, then I do not propose to fetch them again or reprocess
them against the new providers. Thus an existing Session might end up with
saved Attributes with signatures approved by Trust and values approved by an
AAP that was in place at the time they were fetched but are no longer
associated with the default Application to which this Session was
reassigned. This is not, however, much different from behavior if the Trust,
Metadata, or AAP configuration files were changed individually and reloaded
after the Attributes had been processed.

Does this sound reasonable, or am I missing some important other case?


> > When exactly should a
> > request for an unknown applicationId return an error instead
> > of "default"?

> I think the way to answer this is that it
> depends
> which config API is involved. When you interact with the IRequestMap API,
> you MUST always get back an applicationId, and if one isn't specified for
> a
> request, the mapper returns "default" as a reserved value in the
> PropertySet
> that it sends back for the request.
> 
> Whereas when you use the IConfig interface (the root interface I supplied
> to
> bootstrap things) and call getApplication (which takes an applicationId),
> you're always passing in *something*. Either a specific value or
> "default".
> In that case, you may get back NULL if the id/key you pass in doesn't
> exist,
> and that's an error.
> 
> So the former returns *something* ("default" being the last resort) while
> the latter just matches what you give it to the set it knows about, and
> the
> <Applications> element that is the root of the config tree is registered
> in
> the hash table as "default". This was sort of a hack too, since the
> RequestMap and the Application "map" have to be a little "in cahoots".