Shibboleth Developers

[Walter Hoehn <>]

Moving this bugzilla-generated discussion about the transaction logging 
onto the list.  All please feel free to join in...

On Dec 10, 2004, at 9:11 AM, Thomas Lenggenhager wrote:
> > My
> > concern, and the reason that I left it so terse, is that an attribute
> > query response can include an arbitrary number of attributes, with
> > arbitrarily complex values.  So, while listing the attributes released
> > might work for some cases, it creates an extremely verbose log in 
> > other
> > cases.
>
> I can understand your reason very well.
> Some configurable amount of audit info for attribute queries would be
> appreciated though. One level could be just the attribute names but not
> the values. An alternative could be a set of attributes (e.g. 
> dynamically
> generated ones like targetedID) you want to see the values in the audit
> log as well.
>
> To keep the audit log as brief as possible, instead of attribute names
> one could think of (configurable) unique shortnames instead of the
> full attribute URNs.

The transaction log really isn't configurable in the same way that the 
error log is, because it is produced from a custom log4j LEVEL that 
just gets directed to a location separate from the rest.  I guess 
adding the attribute names wouldn't add too much verbosity.  I'm 
concerned that having a filter for values that get logged adds too much 
complexity.  Do you have a specific use case that might require this?

> Wouldn't it be necessary to have also the Name Identifier presented to
> the AA in the attribute release in order to know to which 
> authentication
> request that attribute request belongs to?

This doesn't really tie things to a specific request except in the case 
where Shibboleth handles are being used.

> To be able to know which part of the ARP was used and to which resource
> you sent the attributes, not just the providerID, but also the
> applicationID or Resource URL would be required in the audit log.

Starting with Shibboleth 1.2, we no longer have this dual identifier 
concept (shar and resource) at SP.  The providerId is the one and only 
way to identifier the requester.

> BTW: In the IdP logs we miss (we still use IdP 1.1) the possibility
>      to get the details of the attribute request message received
>      by the AA. In debug mode we would like to see the whole
>      SAML message.
>      Or is this already part of IdP 1.2.1?

We don't dump the SAML request in DEBUG mode, only the response.  I'd 
be glad to add this for you, though.  Could you put this in as a 
separate bugzilla please?

-Walter

Attachment: smime.p7s
Description: S/MIME cryptographic signature