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.

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 relies on uniqueness of authenticated users principal name in subject context. If your configuration is not able to guarantee the uniqueness a bean to resolve safely the username must be implemented and set to property userProfile.UsernameLookupStrategy. This approach can be used also in such proxy deployments that require you to store and present data by a locally resolved attribute that links the user to your local identity.

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 nonse:'{}' at {}", event.value, event.time);
            result;
            ]]>
        </value>
    </constructor-arg>
</bean>