...
By convention, the resolution of the appropriate RPC to use for a request is represented by attaching a net.shibboleth.idp.profile.context.RelyingPartyContext child context to the ProfileRequestContext. Both the RPC and the specific profile configuration in effect are captured by that context, along with information about the identity of the relying party and whether that identity was verified or not.
...
To enable an interceptor, the flow ID suffix (the name after the "intercept/" prefix) must be added into the appropriate list property on the relevant ProfileConfiguration object in conf/relying-party.xml. The properties contain an ordered list of flow IDs representing the flows to execute in a sequence until one fails (results in a non-"proceed" event) or all have run.
...
There is no specific input contract, since profiles vary in their function, but as a general rule, inbound interceptors can assume that the ProfileRequestContext's inbound MessageContext tree is fully populated, and when possible a RelyingPartyContext child context will have been created, along with any contexts needed to drive functions like transport or message authentication.
...
The specific content of the MessageContext tree will depend on the profile involved (documentation on which is very limited at present). Inbound interceptors are generally configured by the system and serve to implement various security policy checks against the inbound message context. Often, they are made up of one or more MessageHandler objects, which are similar to ProfileActions but are more constrained in purpose.
...