Date: Thu, 28 Mar 2024 10:39:33 +0000 (UTC) Message-ID: <611277035.191.1711622373453@1b9593ae1a12> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_190_6890421.1711622373452" ------=_Part_190_6890421.1711622373452 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
The two "halves" of the SP software write to separate diagnostic log fil=
es by default, as configured by the shibd.logger and
Most of the interesting and relevant information will usually be found i= n the shibd.log, particularly SAML-related problems, Metadata issues, and most security issues. It's somewhat ra= re to actually need the native.log (which is one reason th= e permission issue noted above has never been seriously addressed). Under r= outine use, very little ends up in that log (or at least not only there), b= ut one common problem that may depend on using it is the pass-through issue.
The primary control point for logging is to set the logging level of the= "root" logging category, which is the first non-comment line in the logger= configuration files. To pick up a change, you will usually need to restart= the process involved.
The typical logging levels can be described thusly:
DEBUG |
Low-level tracing, usually unneeded except when isolating crashes or dev= eloping. |
INFO |
Routine indications of activity, usually the default logging level. <= /td> |
WARN |
Indicates something that's potentially a problem for the system, but |
ERROR |
Something's wrong. Users are likely to be affected any time one appears.= |
CRIT |
Something's so wrong that attention is required or widespread problems w= ill result. |
FATAL |
Usually indicates a failure to start or continue with operations. |
In most cases, it's unnecessary to raise the logging level to diagnose r= outine problems. Under normal operation, logging at INFO should be relative= ly minimal and is suitable for production use. If you see WARN messages, yo= u should review them and at least know if they're significant. If you see E= RROR/CRIT/FATAL messages, you should almost certainly be doing something ab= out them.
A third log is configured from within the shibd.logger = setup file, and typically available in transaction.log.
Each session that's created or removed is logged here along with a varie= ty of general information, including the set of attributes obtained (but no= t their values). Apart from auditing or tracking down users, the main value= of this information is to identify whether the SP received particular attr= ibutes or not. If you don't see something here, and there are no ERROR or W= ARN messages in shibd.log regarding query failures or filt= ering, then the attribute in question simply wasn't given to the SP.
Since V2.5, the transaction log supports an extensible event model that =
applies a formatting string to each event (via the tranLogFormat setting in the
<OutOfProcess>=
code>
element). A list of supported event types and fields follows.
Each event type is routed to its own logging category named Shibbo=
leth-TRANSACTION.Type
Login
Logout
Request
or Response
is used to signify a standardized logout protocol message.AuthnRequest
Each event field is represented by a formatting token of "%tok=
"
Token |
Field |
Login |
Logout |
AuthnRequest |
---|---|---|---|---|
E |
exception type |
x |
x |
x |
e |
exception message |
x |
x |
x |
S |
protocol status code |
x |
x |
|
SS |
protocol sub-status code |
x |
x |
|
SM |
protocol status message |
x |
x |
|
URL |
request URL |
x |
x |
x |
URI |
request URI |
x |
x |
x |
s |
session ID |
x |
x |
x |
a |
client address |
x |
x |
x |
UA |
client User-Agent |
x |
x |
x |
app |
SP application ID |
x |
x |
x |
SP |
SP entityID |
x |
x |
x |
IDP |
IdP entityID |
x |
x |
x |
p |
identity protocol |
x |
x |
x |
b |
identity protocol binding |
x |
x |
x |
n |
subject identifier of user |
x |
x |
|
u |
REMOTE_USER |
x |
x |
|
i |
assertion ID |
x |
|
|
I |
protocol message ID |
x |
x |
x |
II |
protocol request ID associated with event |
x |
x |
|
d |
assertion timestamp |
x |
|
|
D |
protocol message timestamp |
x |
x |
x |
t |
authentication timestamp |
x |
|
|
x |
SAML session index |
x |
x |
|
ac |
SAML authentication context |
x |
|
|
attr |
list of attributes received |
x |
|
|
L |
logout result |
|
x |
|