Shibboleth Developers

["Howard Gilbert" <>]

> I would have assumed that the filter interface would have the session
> ID and the request path as parameters and that the internal
> FilterSupport piece would determine the application ID based on the
> request map.  I guess it doesn't matter where this is handled, but it
> should be automatic, yes?

There is a call to map the resource URL into an applicationId. To get the
Session, you then pass the sessionId and the applicationID as arguments. The
RM may save the applicationID after obtaining it, but that's up to the RM.

The key idea here is that the RM doesn't have direct access to the SP
configuration files, so any information it gets not just about the Session
but also about other configuration items like the RequestMap have to come
through the FilterSupport interface.

When I first introduced it, I noted that it was called "FilterSupport" for
now. The only RM is the Filter. "ResourceManagerServices" may be a more
accurate name for it in the long run, but I am not sure I have determined
all the service calls needed, so the interface isn't fully scoped yet.