Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: fix typo

...

  • In idp.properties, uncomment and set:
    • idp.fticks.federation to Tuakiri for PROD deployments and Tuakiri-TEST for DEV/TEST IdPs
    • idp.fticks.algorithm - just uncomment it, leaving it set to the SHA-256 hashing algorithm
    • idp.fticks.salt - set it to a value generated with:

      Code Block
      openssl rand -base64 24


    • idp.fticks.loghost: set it to either logs.tuakiri.ac.nz or logs.test.tuakiri.ac.nz as per above (note that prior to 3.3.0, this setting did not exist in idp.properties and had to be added - from 3.3.0 onwards, it is present exists in commented out form)
    • The resulting configuration may look like:

      Code Block
      languagenone
      idp.fticks.federation=Tuakiri
      idp.fticks.algorithm=SHA-256
      idp.fticks.salt=piKN3aBHKMmyWEDn4zYxA71rZxouQibq
      idp.fticks.loghost=logs.tuakiri.ac.nz


      Note

      Earlier versions of this document were instructing to set idp.fticks.loghost in $IDP_HOME/conf/logback.xml - it is easier and simpler to have all logging configuration in idp.properties.


  • Optionally, if your IdP has non-Tuakiri traffic (such as bilateral arrangements with individual service providers) that should not be sent to the centralized log collection servers (if it is, it would still get discarded in subsequent processing), please follow these instructions: 

    Expand
    titleClick here to expand the instructions to filter usage logging messages...
    • Define an ActivationCondition bean called TuakiriFTicksCondition in $IDP_HOME/conf/global.xml  (in Tuakiri-TEST, replace the tuakiri.ac.nz  labels with test.tuakiri.ac.nz ): 

      Code Block
      languagexml
          <bean id="TuakiriFTicksCondition" parent="shibboleth.Conditions.AND">
              <constructor-arg>
                  <list>
                      <!-- based on https://wiki.shibboleth.net/confluence/display/IDP30/ActivationConditions#ActivationConditions-RelyingPartiesByGroup -->
                      <bean <bean id="TuakiriFTicksCondition" parent="shibboleth.Conditions.EntityDescriptor">
                          <constructor-arg name="pred">
                              <bean class="org.opensaml.saml.common.profile.logic.EntityGroupNamePredicate">
                                  <constructor-arg>
                                      <list>
                                          <value>tuakiri.ac.nz</value>
                                          <value>tuakiri.ac.nz/edugain-verified</value>
                                      </list>
                                  </constructor-arg>
                              </bean>
              </constructor-arg>
                  </constructor-arg>
                      </bean>
                      <!-- preserve original condition
                          p:activationCondition="#{'%{idp.fticks.federation:null}' != 'null'}"
                        -->
                      <bean parent="shibboleth.Conditions.Expression"
                          c:expression="#{'%{idp.fticks.federation:null}' != 'null'}" />
                  </list>
              </constructor-arg>
          </bean></bean>


    • In $IDP_HOME/conf/idp.properties , set the idp.fticks.condition property to use this bean: 

      Code Block
      languagetext
      idp.fticks.condition = TuakiriFTicksCondition


      Warning

      This property was only introduced in IdP 4.1.0.  If your IdP is running on an earlier version (4.0.x), you can still activate this setting by directly modifying the activationCondition of the WriteFTICKSLog bean in $IDP_HOME/system/flows/saml/saml-abstract-beans.xml , but changes to files under system/ should be avoided - and will be overwritten on IdP upgrades. 

      However, if this change gets lost in an upgrade, the IdP will not break, just the behavior would return to default - send all FTICKS messages. 

      Preserving these instructions for historical reference (and for sites still on 4.0.x).

      Expand
      titleClick here to expand the instructions for filtering usage logs on IdP 4.0.x
      • Edit the definition of WriteFTICKSLog  bean in $IDP_HOME/system/flows/saml/saml-abstract-beans.xml and instead of the default in-line activation condition, pass a reference to the bean defined above:

        Code Block
        languagediff
        --- system/flows/saml/saml-abstract-beans.xml.dist	2020-07-14 18:02:32.742299470 +1200
        +++ system/flows/saml/saml-abstract-beans.xml	2020-07-21 17:06:41.030977466 +1200
        @@ -337,7 +337,7 @@
                 p:httpServletRequest-ref="shibboleth.HttpServletRequest" />
        
             <bean id="WriteFTICKSLog" class="net.shibboleth.idp.saml.audit.impl.WriteFTICKSLog" scope="prototype"
        -        p:activationCondition="#{'%{idp.fticks.federation:null}' != 'null'}"
        +        p:activationCondition-ref="TuakiriFTicksCondition"
                 p:federationId="#{'%{idp.fticks.federation:Undefined}'.trim()}"
                 p:digestAlgorithm="#{'%{idp.fticks.algorithm:SHA-256}'.trim()}" p:salt="%{idp.fticks.salt:}" />
        
        
      Warning
      With the configuration options available in Shibboleth IdP, the only way to get activationCondition configured was to make this minimal-but-non-zero change to files under /opt/shibboleth-idp/system .  Changes to these files will get lost on IdP upgrades and will have to be reapplied.
      (However, if the changes get lost in an upgrade, the IdP would not break, just the behavior would return to default - send all FTICKS messages).
      We are working with upstream on making this properly user-configurable (without touching files under /opt/shibboleth-idp/system/ ), but this won't be available until 4.1.0: https://issues.shibboleth.net/jira/browse/IDP-1643




  • And restart the IdP - by restarting Tomcat, service tomcat restart

...