Uploaded image for project: 'Identity Provider'
  1. Identity Provider
  2. IDP-840

The addition of F-ticks support in the IdP

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 3.2.0
    • Component/s: Logging and Metrics
    • Labels:
      None
    • Environment:

      Linux variants, but could work on windows with some adjustment to syslog behaviour

      Description

      Based on Scott's guidance, I have implemented an F-TICKS log format that touches 3 files:

      • audit.xml for the format of the logging as well as the custom bean to perform the Subject masking
      • logback.xml for the revelation of the information in a local file for F-TICKS log data and also the syslog connection
      • idp.ini for the addition of 3 attribute that are used in the machinations of F-TICKS data processing, namely:
      • idp.fticks.federation - a short string that is used to indicate the federation of origin (e.g. 'CAF')
      • idp.fticks.salt - a string that is used as the salt input to the hash function
      • idp.fticks.loghost - the FQDN or IP of a syslog host which could be defaulted to 'localhost' regardless of a syslog receiver being present (to my knowledge)

      Attached to this issue is the text file of 2 diffs with an example set of the 3 attributes that are concatenated to the end of the idp.ini file for the feature.

      What I suggest as a minimal default for F-TICKS support is to simply log it it to the file.
      I would suggest that having a preferred behaviour to automatically have the syslog present in the logback.xml so that it may just go to localhost and at least end users post installation could simply just change the hostname and then is 'done' with the F-TICKS configuration.

      That said, I do lay this at the feet of the Shib team to decide what the default profile is (just log to file in the right syntax or go all the way and include the syslog setting). Maybe there's an alternative or better way to do it, I'm not sure but welcome the feedback.

      In our case the IdP-Installer work does the manipulation of audit.xml and logback.xml post installation and simply overlays the files on what exists exactly at post install. If this feature were to be pulled in by the project we of course would eliminate this on our end (our technique would 'freeze' a person at a certain style of audit.xml/logback.xml configuration so we will have to go lockstep with the Shibboleth versions on what we need to do in our toolset.

      The diff's provided in the attachment have some commentary in them for describing a little bit what is happening. Adjust as necessary.

      Thanks for the insight and hope this is a useful contribution to the core.

      Chris.

        Attachments

        1. fticks-contribution.txt
          4 kB
          Chris Phillips

          Issue Links

            Activity

              People

              • Assignee:
                cantor.2@osu.edu Scott Cantor
                Reporter:
                cphillips@canarie.ca Chris Phillips
              • Watchers:
                6 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Time Tracking

                  Estimated:
                  Original Estimate - Not Specified
                  Not Specified
                  Remaining:
                  Remaining Estimate - 0 minutes
                  0m
                  Logged:
                  Time Spent - 4 hours
                  4h