Collecting Data

Connected Services and Activity Page require collecting and storing data of the authentication sequences.

Collecting Data

Plugin installation introduces a new interceptor flow user-profile. The user-profile flow is responsible of executing all collecting and storing actions and it has to be set as interceptor for each profile configuration data is collected from.

<!-- Collecting User Profile data only for SAML2 and OIDC clients -->
<bean id="shibboleth.DefaultRelyingParty" parent="RelyingParty">
  <property name="profileConfigurations">
    <list>
      <bean parent="SAML2.SSO" p:outboundInterceptorFlows="#{{'user-profile'}}" p:checkAddress="false" p:signAssertions="true"/>
      <bean parent="OIDC.SSO" p:outboundInterceptorFlows="#{{'user-profile'}}"/>
      <bean parent="OAUTH2.Token" p:outboundInterceptorFlows="#{{'user-profile'}}"/>
      <bean parent="OIDC.UserInfo"/>
    </list>
  </property>
</bean>

Having the interceptor is only a prerequisite for actual data collection. See Connected Services and Activity Page on how to activate specific data collection.

Data Storage

Data storage options are in userprofile.properties - file.

Property Name	Default	Description
userProfile.StorageService	shibboleth.StorageService	Storage service for User Profile
userProfile.recordexExpiration	P180D	Expiration duration for dormant user record
userProfile.UsernameLookupStrategy	userProfile.UsernameLookupStrategy	Bean of type String<ProfileRequestContext> to look up username per the collected data is stored and read by. Default bean uses principal name of Subject context.
userProfile.RelyingPartyIdLookupStrategy	userProfile.RelyingPartyIdLookupStrategy	Bean of type String<ProfileRequestContext> to look up relying part id used in collected data. Default bean uses actual relying party identifier.

The default in-memory storage service can be used only for initial testing. A more permanent server-side storage implementation should be used in the long run.

By default the data collected and again presented is 'keyed' by users principal name in subject context. If that is not acceptable in your configuration you may implement your own 'key' resolving by defining a bean for it and referencing that in property userProfile.UsernameLookupStrategy. This can be used for instance to solve cases of users having multiple upstream identities that are linked in your 'proxy' to single local account and you want to collect all data from all upstream identities to single record.

Collecting custom data

By defining a bean userProfile.setEventsFunction deployer may read and store custom events.

<!-- Deployer defined function for setting user profile events. -->
<bean id="userProfile.setEventsFunction" parent="shibboleth.ContextFunctions.Scripted" factory-method="inlineScript"
    p:customObject-ref="userProfile.Cache">
    <constructor-arg>
        <value>
            <![CDATA[
            result = "proceed";
            logger = Java.type("org.slf4j.LoggerFactory").getLogger("userProfile.setEventsFunction");
            var subjectContext = input.getSubcontext("net.shibboleth.idp.authn.context.SubjectContext");
            //1. Setting nonsense event
            custom.setSingleEvent(subjectContext.getPrincipalName(), "MY_NONSENSE_TAG", "Nonsense");
            //2. Read the event
            var event = custom.getSingleEvent(subjectContext.getPrincipalName(), "MY_NONSENSE_TAG");
            logger.info("Oh my what nonsense:'{}' at {}", event.value, event.time);
            result;
            ]]>
        </value>
    </constructor-arg>
</bean>