Hi all,

New subscriber & user. I'm trying to configure logback as it's used in the Shibboleth application (http://shibboleth.internet2.edu/, http://wiki.shibboleth.net/). I'm working with version 2.3.6 of their SAML Identity Provider (IdP), which uses version 1.0.0 of logback.

Question: How do I configure SyslogAppender to omit stack traces?

I'm attempting to configure the system to send certain messages to syslog for a security audit trail (things like authentication success/failure). I've located the correct logger, and I've successfully configured a SyslogAppender to send the events to syslog, but I'm getting an odd bit of  a stack trace in the syslog, even though I think I shouldn't.

I think my problem is similar/related to Ingebrigt Berg's issue http://mailman.qos.ch/pipermail/logback-user/2012-March/003054.html

When the line gets logged to syslog, I see the first line correctly, but that line is followed by a stack trace, except that the beginning of the stack trace is replaced with the string "#011". What I want is no stack trace at all, which I ought to be able to get with %nopex, except that doesn't seem to work. When I dig into the code a bit, I see that the SyslogAppender already defines a prefixPattern which has %nopex in it, so I may be missing something here.

Relevant bits of my logging.xml:
    <appender name="IDP_SYSLOG" class="ch.qos.logback.classic.net.SyslogAppender">
        <SyslogHost>localhost</SyslogHost>
        <Port>514</Port>
        <Facility>AUTH</Facility>
        <SuffixPattern> [%logger:%level]  %msg %mdc{idpSessionId} from %mdc{clientIP}%nopex</SuffixPattern>
    </appender>
    <logger name="edu.internet2.middleware.shibboleth.idp.authn" level="DEBUG">
        <appender-ref ref="IDP_SYSLOG"/>
    </logger>


The syslog output looks like:
Apr 19 10:58:24 idp1 [edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine: DEBUG]  Processing incoming request  from 192.168.56.1
Apr 19 10:58:24 idp1 [edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine: DEBUG]  Beginning user authentication process.  from 192.168.56.1
Apr 19 10:58:24 idp1 [edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine: DEBUG]  Filtering configured LoginHandlers: {urn:oasis:names:tc:SAML:2.0:ac:classes:PreviousSession=edu.internet2.middleware.shibboleth.idp.authn.provider.PreviousSessionLoginHandler@7b8be7, urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport=edu.internet2.middleware.shibboleth.idp.authn.provider.UsernamePasswordLoginHandler@11e1813}  from 192.168.56.1
Apr 19 10:58:24 idp1 [edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine: DEBUG]  Filtering out previous session login handler because there is no existing IdP session  from 192.168.56.1
Apr 19 10:58:24 idp1 [edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine: DEBUG]  Selecting appropriate login handler from filtered set {urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport=edu.internet2.middleware.shibboleth.idp.authn.provider.UsernamePasswordLoginHandler@11e1813} from 192.168.56.1
Apr 19 10:58:24 idp1 [edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine: DEBUG]  Authenticating user with login handler of type edu.internet2.middleware.shibboleth.idp.authn.provider.UsernamePasswordLoginHandler from 192.168.56.1
Apr 19 10:58:24 idp1 [edu.internet2.middleware.shibboleth.idp.authn.provider.UsernamePasswordLoginHandler: DEBUG]  Redirecting to https://idp1:443/idp/Authn/UserPassword  from 192.168.56.1
Apr 19 10:58:24 idp1 [edu.internet2.middleware.shibboleth.idp.authn.provider.UsernamePasswordLoginServlet: DEBUG]  Redirecting to login page /login.jsp  from 192.168.56.1
Apr 19 10:58:53 idp1 [edu.internet2.middleware.shibboleth.idp.authn.provider.UsernamePasswordLoginServlet: DEBUG]  Attempting to authenticate user donf  from 192.168.56.1
Apr 19 10:58:55 idp1 [edu.internet2.middleware.shibboleth.idp.authn.provider.UsernamePasswordLoginServlet: DEBUG]  User authentication for donf failed  from 192.168.56.1
Apr 19 10:58:55 idp1 #011at edu.vt.middleware.ldap.jaas.LdapLoginModule.login(LdapLoginModule.java:138)
Apr 19 10:58:55 idp1 #011at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
Apr 19 10:58:55 idp1 #011at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
Apr 19 10:58:55 idp1 #011at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
Apr 19 10:58:55 idp1 #011at java.lang.reflect.Method.invoke(Method.java:616)
Apr 19 10:58:55 idp1 #011at javax.security.auth.login.LoginContext.invoke(LoginContext.java:784)
Apr 19 10:58:55 idp1 #011at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203)
[...]

The lines through "user authentication for donf failed" are expected. The rest are not. I can do the same thing with a RollingFileAppender and it works correctly. Am I missing something?


-- 
me Don Faulkner, CISSP | IT Security at the University of Arkansas
contact>> donf@uark.edu | +1 (479) 575-2905
connect>> uarkITS on Facebook | @uaits | @dfaulkner