Shibboleth Developers

["Allen,Eva" <>]

Before OCLC puts shibboleth into production, it needs to be able to show an
audit trail for any particular FirstSearch session so that when the
inevitable billing questions arise they can be answered with reasonable
assurance.  In an attempt to find such a trail, I logged into FirstSearch
via shibboleth at a time when I was the only person using shibboleth.
Since, presumably, debug level printing will not be used in production, I
set configuration to log only INFO and above level statements.  I found that
it is very nearly impossible to track a session from component to component
and finally to the application.  The total login sequence occurred between
15:55:36 and 15:55:58.  There were several instance of messages that were
repeated by the same process.

For example, the shire.log file reports (these message have been simplified
for readability):
15:55:36 new shire handle created: 0x815b0b8       and
15:55:57 new shire handle created: 0x815b0b8       and
15:55:57 new shire handle created: 0x815b0b8

Or the shar.log file, which reports:
15:55:57 checking validity
15:55:58 creating resource x (for simplicity's sake)
15:55:58 checking validity
15:55:58 creating resource x (the same one as above)
15:55:58 checking validity
15:55:58 creating resource y
15:55:58 checking validity
15:55:58 creating resource y

There was nothing that I could see to tie all the information together.

For example, the IP address from which a request comes is noted in the
Apache access_log and error_log, but is only printed in shire.log when the
session is either created or validated.  Any other statements concerning
that same session do not contain either the IP address or the session handle
so that the statements may be attached to a particular login sequence.

Since our typical login rates this week have ranged from one every 4 seconds
to about 4 per second, you can see the problem.  What I'm looking for is
either 1) a way to establish an audit trail for a particular login among the
various target shibboleth components, or 2) enough information about how
things work that I can edit the source myself and put the information I need
in the relevant statements, or 3) I give the developers information about
what we need in order to establish an audit trail and the developers go off
and write that and put out a shibboleth 1.2 with the audit information in it
(I'm not really expecting that one :-).

I think it was Scott that said earlier in one of the conference calls that
it was difficult for the developers to know what debug level some of the
information should be at and/or what information should be included in the
statements.  I can definitely appreciate that and I'm presuming that's why
the log files are like they are: too much information in some cases (do I
really need to know that a new RPC handle was created and what its number
is?) and too much in others (yeah, I know you're trying to request
attributes for
dxny4qZHLaLlAhZi7dz3P+7iAjY5p6cX+fRoEpAjUPrAIsi341N1wW4BOsoFhYR7XY5ZVWkgbdLp
30FEBanvlR0LjV1EireFr4oF9peCn4NwwmeWu3RstKma81fN9sewB13PJS2LK7XZm22xsKPXmx+s
+t5dqYy8dQHmheT5Bfs7FeIQa5AYEo1KMNsQ94tZlFU3Knf/zi+C2EpeR0EFr/4JKPHV9+/TDLdW
XwKlQWHoWMtkRTV4BZc7C3qhRzXzYHP0VltHKKaVB3EiFT+W/ps2wHD7KgZsjyXzQFduraIwW8i6
i9YJI8gUc1aUQLyLQklJi4asBedtYV3FdnbAc/erk95R1gVFh3xuy0NCRY9d2HgOoTnrluRnMHS1
JiEXUC6G28nR5A0=@urn:mace:inqueue:example.edu
 ->
http://s-pilot.dev.oclc.org:1441/FirstSearch/  but which session is that
for????)

Help!

-- 
Eva Allen
Consulting Software Engineer, OCLC, Inc.
6565 Frantz Rd., Dublin, OH 43017
614.764.6009 | 

Views contained herein are my own; they do not necessarily reflect those of
my employer.