Shibboleth Developers

[Chad La Joie <>]

There really isn't meant to be any connection between the logs, per-say.
 They are meant for very different things.

The access log is like the web-server access log and so it doesn't even
know anything about SAML (or whatever protocol might be coming in).
It's simply meant to see very coarse grain load information (req/sec)
and could be used, for example, to monitor for DoS attacks.
Specifically the request path is just the path portion of the URL used
to access the IdP.  So, for example, if your IdP SAML 2 SSO endpoint is
at http://example.edu/idp/saml2/sso then /idp/saml2/sso would be the
request path.  If you want stats about how users interact with a
particular service you'll need to get those from the service itself.

The audit log is really meant to show auditable events, defined as any
completed request/response pair (even if the response was "this didn't
work"), or to put it another way, anytime the IdP sends something to
some one else.  These would also be useful, for example, in creating
usage stats (X authn/sec, Y% of SPs making attribute queries, Z% of SPs
using artifact).

The normal IdP logs are narrative in nature (and thus not easy machine
parsed like the preceding two logs).  These logs are meant to be where
you go to see errors within the IdP, gain information to help you debug
problems, etc.

Simon McLeish wrote:
> Hi Chad,
> 
> I'm not sure from the list of fields in the three logs how easy it will
> be to map entries in one log to one in one or both of the others. Could
> you possibly explain how this would be done?
> 
> Could you expand on what information will be in the request path field?
> I'd quite like to be able to find out which URL was accessed to prompt a
> request, for example to pick out whether users tend to follow links from
> our library system to the top level of a resource or to journal level or
> article level links.
> 
> Cheers,
> Simon
> 
> Chad La Joie wrote:
>> Okay, last chance for comments.
>>
>> The Shibboleth 2.0 IdP will have three logs: access, audit, and normal
>> log4j log(s).
>>
>> Access: contains information about incoming requests, whether they
>> complete or error out.  Contains the following fields: request time,
>> remote host IP, server host IP, server port, request path
>>
>> Audit: contains the following information about completed transactions,
>> note not all fields may appear for every request/response pair: response
>> time, asserting party ID, relying party ID, incoming request binding,
>> outgoing response binding, message profile, SAML request ID, SAML
>> response ID, user principal name, per-sp, per-principal authentication
>> method, ID of released attributes
>>
>> log4j log(s): logging messages from the IdP as it executes, could be
>> split into separate logs based on severity (i.e. error log for error and
>> fatal messages, another for everything else).
>>
>> Anything additional people need in either the access or audit logs?
>> Note that both logs will be written in some parsable format ( | (pipe)
>> delimited by default).
>>   
> 
> Please access the attached hyperlink for an important electronic 
> communications disclaimer: 
> http://www.lse.ac.uk/collections/secretariat/legal/disclaimer.htm

-- 
Chad La Joie             2052-C Harris Bldg
OIS-Middleware           202.687.0124